kagent - Kubernetes-Native AI Agent Framework
Build, deploy, and manage AI agents in Kubernetes with MCP-powered cloud-native tooling.
- Source repo
- kagent-dev/kagent
- Stars
- ★ 4k
- Last updated
- today
- License
- Apache-2.0
- Primary language
- Go
- FA score
- 43/100 · Major gaps
At a glance
- How it runs
- Works with
- Platform-specific
- Cost
- Free software; you pay for model usage
- Setup effort
- High · needs real infrastructure
- You'll need
- Typical use
- Platform engineers who want to declaratively deploy and manage AI agents in a Kubernetes cluster using kubectl workflows.
- Not a fit if
- Individual developers who don't want to run a Kubernetes cluster
- Teams needing stable, production-ready software rather than an early-stage project
- Source review
- 43/100 · Major gaps 1 safety controls not found
What does this agent do, and when should you use it?
kagent is a Cloud Native Computing Foundation (CNCF) project that provides a Kubernetes-native framework for building and running AI agents. It represents agents and tools as custom Kubernetes resources (e.g., Agent and ToolServer) and supports multiple LLM providers including OpenAI, Anthropic, Google Vertex AI, and more. The architecture consists of four core components: Controller, UI, Engine, and CLI. The Engine, built on Google's ADK (Agent Development Kit), executes agents; the UI provides a web interface for management; and the CLI enables command-line operations. kagent emphasizes declarative, extensible, observable, and testable design, with support for OpenTelemetry tracing.
kagent runs as a Kubernetes controller that watches custom resources (such as Agent, ModelConfig, ToolServer) and creates necessary Kubernetes resources (e.g., Pods) to run agents. Each Agent defines a system prompt, a set of tools, and an LLM configuration, with ModelConfig connecting to different LLM providers. Agents can invoke tools via MCP servers; the built-in MCP server includes tools for Kubernetes, Istio, Helm, Argo, Prometheus, Grafana, Cilium, and others. The UI provides a web interface to manage agents and tools, while the CLI offers kubectl-like commands. All operations go through the Kubernetes API, with OpenTelemetry tracing to monitor agent behavior.
- Platform engineers who want to declaratively deploy and manage AI agents in a Kubernetes cluster using kubectl workflows.
- Operations teams that need agents to automate Kubernetes cluster tasks like troubleshooting or resource optimization, integrating data from Prometheus and Grafana via MCP tools.
- Developers building custom AI agents that utilize existing cloud-native tools (e.g., Istio, Helm) as tool sets, defined via YAML.
- Teams that require observable AI agents, integrating OpenTelemetry tracing to monitor agent execution.
- Organizations seeking a CNCF project with community support and opportunities for contribution.
How do you install or deploy this agent?
Installation guide: https://kagent.dev/docs/kagent/introduction/installation. Typically requires a Kubernetes cluster and kubectl. You can use Helm or apply YAML manifests. Specific steps are not detailed in the README; please refer to the official docs.
How do you use this agent?
After installation, apply custom resource definitions (CRDs) via kubectl to create Agents and ToolServers. For example, define an Agent YAML specifying the system prompt, LLM configuration (referencing a ModelConfig), and tool set. Then use the CLI or UI to manage. Quick start guide: https://kagent.dev/docs/kagent/getting-started/quickstart.
What are this agent's strengths and limitations?
- Kubernetes-native, leveraging CRDs and kubectl, easy integration with existing cluster workflows.
- Multiple LLM provider support (OpenAI, Anthropic, Vertex AI, etc.) via ModelConfig for flexibility.
- Built-in MCP server providing out-of-the-box tools for Kubernetes, Istio, Helm, and other cloud-native tools.
- Declarative definition of agents and tools, enabling version control and GitOps.
- OpenTelemetry tracing support for observability.
- Requires a Kubernetes cluster as runtime, adding infrastructure overhead.
- Relatively new and in active development, may be unstable.
- Dependency on Google ADK as the execution engine introduces specific dependencies.
- Documentation primarily on external website; local README has limited info.
- Custom tool development requires understanding Kubernetes custom resources.
How does this agent compare with similar options?
The README does not explicitly compare other AI agent frameworks, but mentions 'AI agents' domain; may compete with other agent frameworks like Dapr Agents or LangChain, but not specifically mentioned.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| kagent - Kubernetes-Native AI Agent Framework This agent | 43 · Major gaps | FrameworkFree + model costs | ★ 4k | today | Go | — |
| HolmesGPT SRE Agent | 57 · Major gaps | CLIFree + model costs | ★ 3.6k | 1d ago | Python | OpenAI API |
| Kite - Modern Kubernetes Dashboard | 34 · Major gaps | Self-hosted serviceFree | ★ 3.2k | 8d ago | TypeScript | — |
| Cordum Agent Control Plane | 64 · Some gaps | Self-hosted serviceFree | ★ 511 | 1d ago | Go | Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence shows: RBAC configuration supports namespace scoping (rbac.namespaces in ci.yaml), indicating least privilege awareness; but no user confirmation mechanism, data flow transparency limited (only mentions OpenTelemetry tracing), sensitive data handling not explicit, dependency security has SECURITY.md and CI tests, external effects have e2e tests, rollback has upgrade tests, source attribution has contributor list. Deductions: user confirmation missing, data flow details insufficient, sensitive data not detailed.
Evidence shows: CI includes unit tests, e2e tests, upgrade tests, self-consistency good; dependency availability has go.sum and package-lock.json, but no guarantee; failure messages have CI logs, but no user-visible error messages. Deductions: dependency availability not explicit, failure messages insufficient.
Evidence shows: README clearly targets Kubernetes developers, scenarios include multiple LLM providers and MCP tools; capability boundaries have architecture description, but no explicit limits; trigger precision has CRD definitions, but not detailed; environment fit has Helm and Docker support. Deductions: capability boundaries and trigger precision not detailed enough.
Evidence shows: information architecture clear (README has TOC), install notes have links, naming stable (CRD naming), examples and FAQ have links, known limitations not explicit, license Apache-2.0, versioning has CI and upgrade tests, maintenance responsibility has contribution guide. Deductions: known limitations not listed, changelog not provided.
Evidence shows: output usability has UI and CLI, marginal value high (Kubernetes native), cost-benefit has CI tests but no performance data. Deductions: cost-benefit lacks data.
Evidence shows: claims have documentation links, but no independent verification; cross-source corroboration has CI and tests, but no external validation; fact-inference separation not explicit. Deductions: verifiability insufficient.
- Not found in source: confirmation before actingTurn on (or add) a confirmation step before it acts, and try it in a sandbox or test environment before real data.
- User confirmation mechanism missing, may affect security approval processes.
- Sensitive data handling details insufficient, need to review secret management.
- Known limitations not listed, may hide potential issues.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
Release notes excerpt
<!-- Release notes generated using configuration in .github/release.yml at 673d181ec26960f5ab0ddfe7a7c58f07433d1014 --> What's Changed Features * feat: default built-in Harness images from release charts by @EItanya in https://github.com/kagent-dev/kagent/pull/3151 * feat(harness): migrate runtime suspension to DATA snapshots by @supreme-gg-gg in https://github.com/kagent-dev/kagent/pull/3165 * feat(auth): tell UpstreamAuth which A2A method it is authorizing by @codyhartsook in https://github.com/kagent-dev/kagent/pull/3178 …View on GitHub ↗ -
Release notes excerpt
<!-- Release notes generated using configuration in .github/release.yml at a6175df0f628f91869d2d65a706e7bda8d9bbf7c --> What's Changed Features * feat(config): replace application env vars with explicit schemas by @EItanya in https://github.com/kagent-dev/kagent/pull/3153 * feat(adk): propagate GenAI baggage from ADK by @jcopi in https://github.com/kagent-dev/kagent/pull/3088 Bug Fixes * fix: stabilize e2e sends and Codex cancellation by @EItanya in https://github.com/kagent-dev/kagent/pull/3181 Other Changes …View on GitHub ↗ -
Release notes excerpt
<!-- Release notes generated using configuration in .github/release.yml at f2d7cc41d6749fb5bbdee36d26be7d8a04f079ea --> What's Changed Features * feat(helm): run Substrate workers under their own ServiceAccount by @danielle-mustillo in https://github.com/kagent-dev/kagent/pull/3067 * feat(sandbox): read_sandbox_file returns text pages and images by @thomasbarrett in https://github.com/kagent-dev/kagent/pull/3120 * feat(helm): allow setting allowedNamespaces on the built-in tool server by @davidkarlsen in https://github.com/kagent-dev/kagent/pull/3145 …View on GitHub ↗