Four components turn agents into Kubernetes resources
Kagent represents an agent through a Kubernetes custom resource containing its prompt, model configuration, and references to tools or other agents. A controller reconciles those resources, an engine runs agents through Google's Agent Development Kit, a web interface exposes chats and configuration, and a CLI provides terminal access. ModelConfig resources describe providers, while ToolServer resources connect MCP services that several agents can share.
This fits a platform team already reviewing YAML through GitOps. Agent definitions can move through the same pull requests and namespaces as other workloads. The README documents OpenAI, Anthropic, Azure OpenAI, Vertex AI, Ollama, and gateway-routed models. Its bundled MCP tools cover Kubernetes, Helm, Istio, Argo, Prometheus, Grafana, and Cilium, giving the sample agents direct operational jobs.
For one assistant, this is too much machinery. Kagent becomes interesting when several teams otherwise build separate conventions for deployment, secrets, tool discovery, tracing, and lifecycle management.
What happened when we ran it
Our sandbox installed 837 Go packages in 123 seconds and completed the build in 257 seconds. The test step failed after 162 seconds: go test reported 66 passed and 7 failed out of 73. The final log lines showed several packages passing, including controller and translator packages, then ended with FAIL. That tail does not identify the reason for the 7 failures, so assigning one would be guesswork.
The run used commit cb869a0 and the project under go/ in an unprivileged Debian container with 3 CPUs, 8 GB of RAM, Go 1.24, and no secrets. The 17.7 MB checkout contained 1,659 files and about 220,634 source lines. Our scan found 11 CI workflow files, a Dockerfile, and no tests directory. Go tests commonly sit beside source, so the last signal does not mean tests were absent.
A quick start is still a cluster deployment
The official tutorial begins with kind, Helm, kubectl, a model credential, and the Kagent CLI. kagent install --profile demo loads sample agents and tools, while kagent dashboard creates a local port forward. A minimal profile skips samples. This is approachable for a Kubernetes operator, but it is not equivalent to installing an agent library in an existing service.
Production uses separate CRD and application charts. Operators choose resources, store model secrets, expose the UI, configure OpenTelemetry, and provide an external PostgreSQL database. Agent Harness adds substrate charts, a worker pool, controller endpoints, another namespace, and timeout decisions. Each piece has a purpose, but the operating cost arrives before an agent answers its first useful question.
Issue 2268 says the project has no official matrix mapping Kagent releases to tested Kubernetes minor versions. Pin the CLI and both chart families, inspect the CI versions, and rehearse upgrades. A successful chart installation cannot substitute for a published support boundary.
No-op user authorization blocks multi-tenant use
Issue 1270 states that Kagent lacks authorization for its UI and API, and that all users can access resources across namespaces through a NoopAuthorizer. The proposal asks for API-enforced roles, OIDC group mapping, and secret masking. Agents may hold model credentials or invoke MCP tools with operational access, so this is a product boundary rather than an administrative nicety.
Kubernetes service accounts can limit what a workload does. They do not decide which person may discover, invoke, change, or delete agents through Kagent's own surfaces. A shared deployment needs isolation outside the current user model: separate clusters or tightly controlled access, a private dashboard, narrow tool permissions, and human approval for consequential actions.
Issue 2283 adds a staging constraint. Two Kagent installations can collide on cluster-scoped metrics RBAC names, leaving metrics enabled for only one instance unless operators accept a workaround. Teams that require blue-green control-plane upgrades inside one cluster should test this path before choosing Kagent.
Webhooks and some gateways need external workarounds
Kagent's resource model does not yet make it an event receiver. Issue 2185 asks for webhook or Kubernetes-event triggers, using a pull-request review bot as the example. Event-driven teams need an external service that receives the event and invokes the agent.
Model portability also has a specific edge. Issue 2440 reports that both Go and Python OpenAI-compatible embedding paths always request 768 dimensions. Gateways backed by models that support 1,024, 512, or 256 dimensions can reject every memory call even though Kagent's later processing can truncate larger vectors. The report suggests using a native provider path or a model that accepts 768 until the request becomes configurable.
Those limitations do not erase provider choice. They define where the advertised flexibility stops, which is exactly what a platform evaluation should test with its chosen gateway and automation source.
Release candidates are active, not settled infrastructure
GitHub showed 3,595 stars, 148 combined issues and pull requests, and a last push on August 26, 2026. The latest release is v0.10.0-rc3 from August 18. Its notes include file upload in chat, configurable tool-server refresh timing, database cleanup, S3-backed skills, and a security fix. The Apache 2.0 project is part of CNCF and accepts contributions.
Current work and 11 CI workflows are positive signals, while the 7 failing tests in our stated environment prevent an unqualified maturity claim. Kagent deserves a trial when Kubernetes is already the control plane and shared MCP operations are the goal. It should remain isolated until authorization, cluster compatibility, staging, and the exact model gateway all pass an operator-owned acceptance suite.