Managed agents · Self-hosted · Your cluster
Managed AI agents
on Kubernetes.
Autonomous agents in sandboxed pods, every step traced, every request routed by rules — on infrastructure you control. Serve frontier-class open models under them, or use any remote API.
Two ways in
One platform, two planes
Come for the agents; add serving when you want to own the models. Both run on the same Kubernetes control plane.
Managed agents
Autonomous workers with sessions, tools, skills, memory and shared wikis — each running in its own sandboxed pod, every step on the record. Point them at your models, or start here and treat the model as a detail.
Explore managed agents →Serve your own models
An add-on, not a prerequisite: start agents on any remote API, then deploy open models like microservices — curated catalog, one-click provisioning, autoscaling, scale-to-zero — when you're ready to own the model too.
Explore model serving →Use case 01 — Managed agents
Not a chatbot —
an autonomous worker
A managed agent is a model given a goal, a set of tools, and the freedom to take many steps to finish the job — it plans, runs code, checks its own work, and repeats until it's done. Feed it any files — spreadsheets, log files, diagnostics, screenshots, images — and package your procedures as skills that guide how the work gets done.
A real session, recorded live: the agent loads its triage skill, works an inbox export plus a diagnostics log, consults the team wiki, delegates a knowledge-base update — and the finished result opens as rendered markdown. Click any screenshot to expand.
Isolated, secure session containers
Every session runs in its own container with its own filesystem — no internet unless the environment allows specific hosts, secrets injected from credential vaults, never visible to the model or other tenants.
Delegation
Agents hand work to other agents as full child sessions — a triage agent delegates to a librarian, and the transcript links parent and child.
Full skill support
Anthropic-style skill packages with progressive disclosure: agents see an index and load only the files they need — versioned, shared per workspace.
Full MCP support
Connect any MCP server to an agent. Credentials come from the vault, egress opens automatically for the server's hosts, and a bundled registry covers common servers.
Wikis & memory
Shared LLM wikis — many readers, exactly one writer agent — plus per-agent memory stores that persist across sessions.
Idle-to-zero economics
Turns run as Kubernetes Jobs that cost nothing between messages. Sessions checkpoint and resume — even after failures.
The same session starts by loading its skill and the attached evidence files.
Agents are versioned configs: routing, tools, skills, environment, subagents.
An LLM wiki the agents maintain themselves — one writer, many readers.
Environments define the sandbox: egress allowlist, resources, persistent disk.
Every session with tokens and cost — including delegated child sessions.
Every step, on the record
When security asks
what it did — this is the answer
Every session is a step-level trace: each message, thought and tool call, with live token counts and the resolved model. Costs land in two ledgers — what the infrastructure really costs, and what you bill — attributed per key, per agent, per workspace.
The full transcript of a finished session — auditable after the fact, live while it runs.
The gateway side: every request, the rule it matched, the model it landed on.
Metered like a product: real vs billed, per key, per agent, per workspace.
One endpoint
Rules pick the model
Clients call a routing like a model. A rule table decides per request — by context length, spend, token budgets, time of day, or a classifier — and can downgrade to a cheaper model past a budget, or reject over-budget traffic with a clean error. Local pods and external endpoints (OpenAI, Anthropic, OpenRouter, custom) sit behind the same gateway, keys stored server-side — change the mix without touching a single client.
The rule editor: first match wins, budgets act automatically.
Clients call a routing like a model; rules decide where it lands.
Or from code
Script everything
Anything the console can do, the REST API and the typed Python client can do too — create agents from CI, kick off sessions from a webhook or a cron job, and wire the results into your own product. A dozen lines end to end.
Add-on — serve your own models
When you're ready,
own the model too
Your agents don't care where the model runs — serving is an add-on, not a prerequisite. A curated catalog shows hardware requirements and estimated cost for every model before you run it. One click provisions a pool and routes an endpoint — or bring your own weights from Hugging Face, an internal registry, or a plain URL.
162 curated open models — parameters, context, GPU RAM, throughput — plus your own.
Elastic by default
Deployments autoscale on live queue depth and sleep to zero replicas when idle — requests during wake-up are held, not dropped.
One gateway, two dialects
Every deployment speaks the OpenAI and Anthropic APIs. Your existing tools switch by changing one line — the base URL.
No lock-in
Open weights, standard Kubernetes, and APIs your tools already speak — moving in (or out) is a base-URL change, not a rewrite.
Local pods and external endpoints, served side by side.
Drop-in compatible
Point your stack at your own models
No rewrite, no new SDK, no vendor account — change the base URL.
Claude Code & Codex
Run your dev agents against models on your own cluster — same CLI, your endpoint.
OpenAI API
Anything built on the OpenAI SDK just works — flip the base URL and go.
LangChain & co.
LangChain, LlamaIndex, the Vercel AI SDK — unchanged, now pointed inward.
Why own it
AI stopped being a feature and became foundation — and open-weight models (GLM, Llama, Qwen, DeepSeek) now rival the closed frontier under permissive licenses. Owning the serving layer means your access · cost · uptime · scale are decided by you, not by someone else's pricing page. That's the whole argument; the rest of this page is the how.
How it works
A Kubernetes-native control plane
Six components, one chart. Runs anywhere Kubernetes does — the same manifests from a docker-desktop laptop to a thousand-node cluster.
Pick a model
Curated + custom, with hardware and cost up front.
Provision
CRDs become serving pods, autoscaled on live load.
Serve
OpenAI + Anthropic APIs, auth, metering — one endpoint.
Run
Sessions as Jobs: idle to zero, checkpoint, resume.
The console — your whole AI platform in one pane of glass, scoped per workspace.
Console
The web UI above: dashboards, live session transcripts, catalog, deployments, usage and billing — everything scoped per workspace.
Control plane
The platform API and session orchestrator. Workspaces, agents, sessions, files, wikis, keys — Postgres-backed, event-driven.
Operator
A Go operator that turns ModelPool and ModelDeployment
resources into serving pods, and scales them on live queue depth.
Gateway
One endpoint for every model, local or external: API-key auth, usage metering, routing rules, and wake-on-request for sleeping models.
Session runner
The per-session pod: an in-house agent loop with built-in tools (bash, files, web, MCP), checkpoints, and delegation — no vendor CLI inside.
Model catalog
A curated YAML catalog of open models with hardware profiles and context windows; add custom entries from any source.
Source
Get the code
Everything is in one repository — operator, control plane, console, session runner, charts. Install it from there, audit what runs next to your data, patch it yourself. Source-available under the Elastic License 2.0 (self-host freely, including commercially); the Python client is Apache-2.0.