Kagent v1 treats agents as cluster resources
Kagent's v1 design turns an agent into a Kubernetes resource with a template, runtime definition, model configuration, and tool connections. You declare the behavior in YAML and let a controller reconcile it. Agents become infrastructure that a platform team can inspect and govern, rather than processes hidden inside individual applications.
A controller compiles agent definitions, PostgreSQL stores sessions and task history, and Substrate runs the processes. Clients use gRPC, A2A, or MCP, while the UI and CLI cover management and chat. The v1 architecture guide states which component owns each resource and where persistent state lives.
Five runtime choices share one agent definition
The v1 README names five runtime paths: kagent's Go ADK, Python ADK, Codex, Claude, and a custom runtime. AgentTemplate resources separate prompts, tools, subagents, and model choices from execution. A platform team can reuse one template across compatible runtimes instead of copying configuration into several deployments.
Kagent can suspend and resume an agent, create a checkpoint, and fork a conversation. Its MCP server includes tools for Kubernetes, Helm, Istio, Argo, Prometheus, Grafana, and Cilium. OpenTelemetry traces agent, model, and tool activity. Together, these features make kagent a platform decision rather than a library choice.
What happened when we ran it
Our run cloned commit a6ccbec on September 27, 2026 into an unprivileged Debian container with 3 CPUs, 8 GB of RAM, Go 1.24, and no secrets. The checkout contained 1,670 files, roughly 258,610 source lines, and occupied 15.6 MB. Our test method covered the Go project under ./go/; it did not deploy a cluster or call a model provider.
The install succeeded in 186 seconds and brought in 923 packages. The build also succeeded, taking 380 seconds. Those results show that the source could be prepared and compiled in the clean container. They say nothing about Helm deployment time, agent startup, or model cost because our sandbox did not measure those jobs.
The Go test command returned exit code 1 after 184 seconds. Of 129 tests, 119 passed and 10 failed. The log tail lists passing packages under the Codex adapter, runtime, logging, telemetry, tracing, and sandbox guest code, then ends with FAIL. It does not show the failing test names or error messages, so assigning a cause would be guesswork.
Our scan found 8 CI workflow files and a Dockerfile, but no tests directory. The measured command still found 129 tests beside the Go packages. The defensible result is narrow: commit a6ccbec installed and built in our container, yet its complete Go test step did not pass. A team with a green release gate has to reproduce and explain that result.
Local development needs Kind v0.27.0 or newer
The development guide for the tested commit asks for Kind v0.27.0+, kubectl v1.33.4+, Go v1.27.0+, Docker, Buildx v0.23.0+, Helm, and Make. Our Go 1.24 image completed the measured build, but it is not a documented configuration. Contributors should start with the stated versions.
The local route creates a Kind cluster, builds images, loads them, and installs the Helm charts. You need a model provider and its credential unless you use a local option such as Ollama. PostgreSQL comes with the chart. Its default image lacks pgvector, so long-term memory needs an external database or the documented pgvector image and setting. The UI requires a port-forward to local port 8001.
Open reports affect plugins and Claude approvals
Open issue 2604 reports that Git, OCI, and S3 Agent Plugin resources cannot be fetched while Substrate creates a golden Actor. The author reproduced it with public Git and digest-pinned OCI sources, without credentials. The template remains pending, and the stated workaround is to bake the content into a custom runtime image.
Open issue 3029 covers Claude Code 2.1.260. The report says a Claude runtime drops compiled skills on turns with an approval-gated MCP server because of driver settings. These are user reports, not failures from our sandbox. Both touch the runtime and plugin flexibility that gives kagent its appeal.
v0.10.3 shipped one day before the latest push
GitHub showed 3,930 stars and 177 combined open issues and pull requests on October 4, 2026. The latest push was October 3, one day after v0.10.3 shipped a runtime-image fix and kagent-tools update. Maintenance is active, though a review of one September commit can age quickly during the v1 work.
The architecture guide names several unfinished parts: multi-replica gateway coordination, policy-enforced public cross-Session delegation, checkpoint sharing, and Dedicated agent bindings. Those limits say more than the version number. Check the boundary that matters to your deployment, then pin the chart, images, and CRDs together.
Choose it for governed agents, not one embedded bot
A 923-package install, 380-second build, and 10 failed tests make kagent a poor shortcut for one application agent. LangGraph leaves orchestration in code, Dify gives application teams a visual workspace, and K8sGPT focuses on cluster diagnosis. Each removes a layer when a common Kubernetes resource model is unnecessary.
Kagent earns a trial when a platform team wants prompts, runtimes, tools, credentials, and sessions governed beside its other Kubernetes workloads. Keep that trial out of the production path until the same 129-test command is green in your environment and any open report matching your chosen runtime or plugin source is resolved or accepted.