Dora NodaSolo.io open-sourced kagent in March 2025. Within a week it had cleared the 300 GitHub stars the CNCF requires just to appear on the landscape. By its 100th day it had passed 1,000 stars and 100 contributors — more than 85 percent of them from outside Solo.io. Today the counter sits near 3,800 stars with active development still landing daily. For an infrastructure project, that is not hype velocity. That is "operators had this exact gap" velocity.
The gap is agent lifecycle. Every platform team building AI operators right now faces the same choice: run each agent as a bespoke long-lived process with its own deploy story, its own secret wiring, and its own observability bolt-on — or make the agent an ordinary Kubernetes object. Kagent, a CNCF Sandbox project since May 2025, picks the second option all the way down: an agent is a CRD you version in Git, roll out with Argo or Flux, inspect with kubectl get agents, and gate with RBAC, exactly like a Deployment. This post shows what that concretely buys a self-hosted, Cluster-API-based PaaS building its own deploy-from-chat operator — and draws the line where kagent replaces platform work versus where the platform still owns the problem.
Your next operator ships as YAML
Here is the whole pitch in one manifest (simplified from the documented shape at kagent.dev/v1alpha2):
apiVersion: kagent.dev/v1alpha2
kind: Agent
metadata:
name: deploy-helper
namespace: kagent
spec:
type: Declarative
declarative:
modelConfig: default-model-config
systemMessage: "You help developers deploy and debug apps on this platform."Apply it and the kagent controller reconciles the object into a running Deployment plus a Service exposing the agent over JSON-RPC. The ModelConfig it points at is a second CRD holding the LLM provider and model choice — OpenAI, Anthropic, Google, Azure, Bedrock, Ollama, or a gateway in front of them — so swapping models is a manifest edit, not a redeploy of agent code.
Compare that with the bespoke alternative most teams start from: a Python service wrapping an agent framework, deployed by its own pipeline, configured by environment variables nobody versions, talking to tools through hand-wired clients, with "which prompt is production running?" answerable only by reading container logs. Every property Kubernetes already gives workloads — declarative desired state, revision history, GitOps rollout, kubectl introspection, namespace isolation — the Agent CRD gives agents for free. That is the core buy, and it lands before any discussion of frameworks or protocols: agent lifecycle stops being a second platform the team maintains and becomes rows in etcd.
How the CRD model actually works
The controller supports two agent types, and the split is the most important design decision in the project:
| Declarative | BYO (custom) | |
|---|---|---|
| Defined by | YAML spec: system message, model, tools | Your container image |
| Controller does | Builds the Deployment, wires model and tools | Orchestrates it: networking, discovery, observability |
| Framework | kagent's own runtime (Go or Python ADK) | LangGraph, CrewAI, Google ADK, OpenAI Agents SDK, or your own |
Declarative agents are the fast path: describe the agent and the controller stands it up. BYO agents are the escape hatch that keeps the fast path honest — a team with an existing LangGraph pipeline does not rewrite it to adopt kagent; it containerizes what it has and lets the platform handle discovery, routing, and telemetry.
The runtime choice inside declarative agents mirrors the same pragmatism. The Python runtime (the default) carries the framework integrations — Google ADK-native features, CrewAI and LangGraph interop, Python custom tools. The Go runtime is a native implementation for teams that want a single static binary and lower overhead per agent. Either way, each agent gets an A2A (agent-to-agent) endpoint, and every prompt and tool call emits OpenTelemetry traces and Prometheus metrics. In one community deployment, operators report 90 to 200-plus spans per agent query depending on tool-call depth — exactly the granularity you need when an agent's "deploy my app" fans out across a dozen tool invocations.
The surrounding CRDs complete the picture. RemoteMCPServer (renamed from ToolServer — note the churn, more on that below) attaches external tool servers. Memory gives agents persistent state. And kmcp, the subproject that now ships inside the kagent Helm chart, contributes an MCPServer CRD that runs MCP servers on-cluster under controller management. Tool integrations become declarative objects with the same lifecycle story as the agents that consume them.
MCP for tools, A2A for teammates
Two protocols carry the whole architecture, and the community's shorthand is the clearest explanation ever written for them: MCP is how an agent gets tools; A2A is how an agent gets teammates.
On the tools side, kagent speaks MCP natively — Streamable HTTP and SSE transports — against both remote servers and kmcp-managed on-cluster ones, plus a built-in kagent-tools server covering the Kubernetes-native basics. A documented production pattern wires one agent to kubectl, GitHub, and CI-pipeline MCP servers simultaneously, so "investigate the failed deploy" resolves to real cluster and repo reads instead of confident guesses.
On the teammates side, every agent's A2A endpoint lets agents call each other as tools. The canonical topology is an orchestrator fronting specialist sub-agents — a security agent with Kubernetes tools, a cost agent with Prometheus tools, a network agent with Istio tools — composed purely by referencing endpoints, with no shared codebase between them. Because the mesh runs over standard Kubernetes networking (and Istio where mTLS and egress policy matter), agent-to-agent traffic inherits the same policy and observability controls as service-to-service traffic. There is no separate agent network to secure.
Above both sits agentgateway, Solo.io's L7 data plane for the agentic stack: A2A routing, MCP federation and multiplexing, auth, rate limiting, and prompt guards between the agentic pieces. The mental map is a trio — kagent runs agents, kmcp runs tool servers, agentgateway governs the traffic between everything — installable together from the cloud marketplaces (Solo.io now publishes the stack for AWS, Azure, and GCP) or piecemeal via Helm. Later additions orbit the same model: agentregistry, contributed to CNCF, for discovering and distributing agents and tools across an organization, and the Agent Substrate runtime for fast cold starts and per-agent isolation.
What this replaces on a PaaS roadmap
Here is the decision table a self-hosted PaaS team actually needs — each row scored for a typical small platform crew running its own Cluster API fleet, not a hyperscaler:
| Roadmap item | Hand-rolled cost | kagent provides | Verdict |
|---|---|---|---|
| Deploy-from-chat operator | Agent harness, prompt versioning, rollout story, tool clients — a second platform to maintain | Agent CRD + GitOps rollout + A2A endpoint; BYO keeps existing framework code | Adopt the runtime, keep the domain logic. The reconcile-and-deploy brain stays yours; the lifecycle stops being yours. |
| Troubleshooting / runbook agents | Per-agent services for k8s, Helm, Prometheus, logs — each with its own deploy pipeline | Declarative agents + built-in k8s/Helm/PromQL tooling + kmcp servers | Adopt. This is kagent's home turf: DevOps agents were the founding use case. |
| MCP/tool server lifecycle | Hand-wired server processes, manual credential injection, no discovery | MCPServer / RemoteMCPServer CRDs, controller-managed, gateway-federated | Adopt, and put the gateway in front so agents never hold real credentials. |
| Multi-agent orchestration | Custom router, retry/fan-out logic, cross-agent auth | A2A endpoints + agentgateway routing and policy | Adopt for platform agents; tenant-facing agent meshes need tenant isolation the platform still designs. |
| Tenant deploy semantics ("push repo, get HTTPS") | The platform's core: build, domains, TLS, quotas, billing hooks | Nothing — kagent orchestrates agents, not tenant workloads | Keep. This row is the boundary: kagent never sees a tenant app. |
Two notes on reading the table honestly. First, the "adopt" verdicts assume the team already operates Kubernetes well enough that "one more controller" is cheap — true for a Cluster-API PaaS by definition, since controllers are the platform. Second, the tenant boundary is load-bearing: kagent agents operate the platform; they are not the mechanism by which tenant code runs. Conflating the two is how a team ends up with an LLM in the hot path of git push.
The honest gaps before you depend on it
Sandbox is not Graduated, and the version numbers say so out loud. The API group sits at v1alpha2, and alpha APIs rename things: ToolServer became RemoteMCPServer, and the MCPServer CRD moved into a separate kmcp Helm subchart at v0.6.3. Anyone who adopted the early shapes has already done at least one migration, and more are plausible before any v1. The project itself is still 0.x. That is normal for a Sandbox project eighteen months old, but it sets the adoption terms:
- Pin everything. Chart version, CRD version, image tags. Do not float on a 0.x line whose CRDs rename between minors.
- Treat CRD upgrades as migrations, not patches. Budget the same review you would give any storage-version change on etcd-backed state.
- Isolate platform agents from tenant blast radius. Namespace them, RBAC them, and keep tenant credentials behind the gateway — the pattern KodeKloud's agent-protocol guide recommends has agents calling the gateway while the gateway attaches real credentials, so a compromised agent leaks nothing worth having.
- Track the ecosystem, not just the repo. kmcp, agentgateway, and agentregistry move on their own cadences; a Solo.io September 2026 announcement round (agentdesktop, Solo Enterprise for agentgateway) shows where commercial energy is going, which is useful signal for which seams stay open.
None of this is disqualifying — it is the standard posture for depending on a fast-moving Sandbox project, and the project's governance (neutral CNCF home, majority-external contributors) is exactly what makes the posture viable.
Agents become cattle, not pets
The throughline of kagent's first eighteen months is a familiar one for anyone who watched Kubernetes absorb the pets of the previous era: take the thing operators hand-tend — then a server, now an agent — and reduce it to a reconciled object with a revision history. The star curve (300 in a week, 1,000 in 100 days, near 3,800 today), the contributor mix, and the marketplace listings all say the same thing: platform teams would rather kubectl apply their agents than babysit them.
For a self-hosted PaaS, the practical conclusion is narrow and actionable. Keep owning tenant deploy semantics — that is the product. Stop owning agent lifecycle — that is now a CRD, a controller, and a gateway the community maintains. The team that internalizes that split gets its deploy-from-chat operator as a GitOps-managed object with traces, metrics, and RBAC on day one, and spends its agent engineering budget on the only part no upstream can write: what the agent knows about its own platform.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with AI agents as first-class operators. Star the repo on GitHub or deploy your first app today.
