kagent vs Orchestrator Zero
oz0 records agent jobs running on your infrastructure. kagent makes agents Kubernetes resources. oz0 also runs on standalone machines, with outbound-only nodes, a model gateway and a verifiable audit trail. Recovery depends on the agent type.
What kagent is
kagent is an open-source, Kubernetes-native agent platform created at Solo.io and now a CNCF sandbox project. Agents are Kubernetes resources, and conversations run on Agent Substrate in isolated sandboxes. This comparison covers the 1.0 alpha line, including alpha17 released on 21 October 2026; the stable 0.x line differs. Solo.io also sells an Enterprise edition.
kagent.dev- Runs
- Self-hosted
- Checked
- 27 October 2026
Side by side.
kagent's ratings come from its own pages. A column's name opens its definition and how Orchestrator Zero does it. How we rated
Where it runs
Any machine you own
Yes
DocsConditional: Kubernetes only
Agents run only in Kubernetes; a local CLI is for development.
Linux, macOS and Windows
No: Kubernetes only
Agents run as Actors on Agent Substrate Workers inside a Kubernetes cluster, isolated by gVisor; there is no native agent runtime for macOS or Windows machines.
Fleet operations
Yes
DocsConditional: Kubernetes pools
Kubernetes worker pools run the agents; there is no registry of machines.
Durability
Durable runs
Conditional: Active turn lost on node death
Suspended sessions resume from stored snapshots on an available worker. An active turn is lost if its worker dies; the docs require a new session rather than replay from the last completed tool call.
Governance
Tool policy outside the model
Conditional: Tool lists, approval flag
MCP bindings select tools and can require approval, with harness-specific limits. Built-in tool settings also vary by harness; the kagent harness can disable Bash. Solo Enterprise adds centrally enforced AccessPolicies.
Approvals in chat
Conditional: UI and A2A API, no chat app
A call on a requireApproval binding waits at INPUT_REQUIRED with its process snapshotted, and is answered from the kagent UI or any A2A or MCP client; the kagent CLI cannot answer it and no Slack or Teams integration ships with 1.x.
Tool snapshots
Yes
DocsNot documented
Searched the 1.x docs and the repository for tool definition changes, rug pull, tool poisoning and tool pinning; skills and plugins load from immutable Git commits, OCI artifacts or S3 versions, but nothing records or checks MCP tool descriptions.
Tenants built in
Yes
DocsConditional: Namespaces; user isolation gaps
Kubernetes RBAC governs cluster resources. Session APIs default to insecure caller identity; trusted-proxy mode requires an upstream validator. Creator scoping is not a strong tenant boundary because the default user authorizer permits all checks.
Cost
Budgets that stop a run
Conditional: Tokens traced, no budget
Token usage shows on traces; nothing enforces a budget.
Security
Provider keys off the workers
Yes
DocsYes
The Agent Substrate egress gateway fetches the provider key from a Kubernetes Secret and writes it into the outgoing request header, and the runtime only sees a placeholder.
Sandbox with an egress allowlist
Yes: gVisor, default-deny egress
Agent Substrate isolates sessions with gVisor and enforces default-deny network policy. Allowed destinations come from the agent template and selected EgressPolicy resources; policy changes can take about ten seconds to affect new requests.
Audit and compliance
Tamper-evident audit trail
Conditional: Traces without tamper evidence
Prompts, replies and tool calls can be captured in OpenTelemetry traces, which the docs call best effort and not tamper-proof; Solo Enterprise adds tracing views, and no hash chain or signing is documented.
Erasure by key
Conditional: Delete a user's memories
Long-term memories for one agent and user can be deleted together, and sessions can be deleted one by one, but there are no per-person keys.
Retention with legal hold
No: No retention for run history
Idle sessions are deleted after controller.sessionIdleTTL (seven days by default), but their A2A tasks and event history stay in PostgreSQL with no setting to bound them, and no legal hold is documented.
Openness
Model provider choice
Yes
DocsYes
ModelConfigs cover OpenAI, Anthropic, Gemini, Bedrock, Azure and local Ollama; in 1.0 the Vertex AI providers and SAP AI Core do not compile, and the codex and claude runtimes take only their own vendors.
MCP and A2A
Yes
DocsYes
Agents bind MCP servers as tools and are reachable over A2A, which kagent also uses for its own traffic; the controller also serves agents as MCP tools.
Where kagent is stronger.
CNCF project from Solo.io
kagent is a Cloud Native Computing Foundation sandbox project created at Solo.io, with its source public under Apache 2.0.
kagent.devAgents managed like cluster workloads
Agents are Kubernetes custom resources that teams version and roll out with kubectl and GitOps, next to everything else in the cluster.
kagent.devBundled tools for cluster operations
An install registers 124 tools for Kubernetes, Helm, Istio and Argo Rollouts.
kagent.devCommercial edition across clusters
Solo Enterprise for kagent adds management, observability and federation across Kubernetes clusters, sold by Solo.io.
kagent.dev
Full in kagent, partial in oz0: Sandbox with an egress allowlist.
Differences to examine.
Compare the scope, conditions and editions in the source notes.
- Any machine you own
- Linux, macOS and Windows
- No inbound ports
- Fleet operations
- Tenants built in
- Budgets that stop a run
- Tamper-evident audit trail
- Erasure by key
Using both
kagent can bind any MCP server through a RemoteMCPServer, and Orchestrator Zero serves its agents over MCP and A2A, so a kagent agent could call an Orchestrator Zero agent.
Based on documentation; this pairing has not been tested.
Find your first task.
Explore an example or read the public Docs preview. Software access is coming soon.