Kontext vs kagent
Two Kubernetes-native approaches to AI agents
Both projects use Kubernetes resources and controllers. The main difference is scope: Kontext treats agents as container workloads with explicit execution objects; kagent provides a broader agent platform with integrated runtimes, tools, and interaction surfaces.
At a glance
| Area | Kontext | kagent |
|---|---|---|
| Core model | Agent definitions and immutable AgentRun executions |
Agent platform built around Kubernetes CRDs |
| Runtime | Bring your own container image; structured results are optional | Integrated agent runtimes with framework and model-provider support |
| Execution | Each run is a Kubernetes object with a Pod, status, budget, and owner references | Controller and engine manage agent configuration, conversations, and tools |
| Interface | Kubernetes API, kubectl, logs, and status |
Kubernetes API plus CLI and dashboard |
| Project status | Alpha | CNCF Sandbox project created by Solo.io |
When Kontext fits
Choose Kontext when the agent runtime is already a container, execution
history should be represented by AgentRun resources, and the
Kubernetes API should remain the primary operating surface. Kontext keeps
the control-plane boundary narrow and does not require a specific agent
framework.
When kagent fits
Choose kagent when you want an integrated platform for defining and interacting with agents, model providers, MCP tools, memory, and agent-to-agent workflows, with a CLI and dashboard. Its larger built-in surface can reduce the assembly required for those use cases.
Start with the workload model
Read the Kontext
API specification
or install the current alpha. The
quickstart shows one
complete AgentRun without cloning the repository.