kagent: AI Agents for Kubernetes Operations

AI agents are moving from desktop demos into operational platforms. That shift matters because SRE teams need agents to run with clear identity, scoped tools, repeatable configuration, and observable behavior. kagent takes that path by treating agents as Kubernetes resources instead of side scripts.

What Is kagent?

kagent is an open-source framework for building and running AI agents in Kubernetes. It defines agents, model configuration, and tool servers as Kubernetes custom resources, then runs the agent engine inside the cluster.

The project is aimed at cloud native operations. Its built-in MCP tools cover areas such as Kubernetes, Istio, Helm, Argo, Prometheus, Grafana, and Cilium. That makes it relevant for platform teams that want AI assistance close to the systems being inspected, but still controlled through normal cluster workflows.

Key Features

• Declarative agents: Define an agent with a system prompt, tools, other agents, and model configuration.
• Multiple model providers: Use OpenAI, Azure OpenAI, Anthropic, Google Vertex AI, Ollama, or custom providers through AI gateways.
• MCP tool servers: Share Kubernetes-native tool definitions across agents instead of hardcoding integrations.
• Operational UI and CLI: Manage agents through a dashboard or the kagent command.
• Tracing support: Export OpenTelemetry traces so agent runs can be inspected in tools such as Jaeger.

Installation

The official docs recommend the CLI for a quick demo profile:

export OPENAI_API_KEY="your-api-key-here"

brew install kagent
kagent install --profile demo
kagent dashboard

For production-style installs, Helm gives teams more control over values, providers, and resource settings:

helm install kagent-crds oci://ghcr.io/kagent-dev/kagent/helm/kagent-crds \
  --namespace kagent \
  --create-namespace

helm install kagent oci://ghcr.io/kagent-dev/kagent/helm/kagent \
  --namespace kagent \
  --set providers.default=openAI \
  --set providers.openAI.apiKey=$OPENAI_API_KEY

Usage

After installation, list the available agents and invoke one from the CLI:

kagent get agent
kagent invoke -t "What Helm charts are in my cluster?" --agent helm-agent

That workflow is deliberately simple, but the important part is the execution boundary. The agent talks to cluster tools through configured resources. Operators can review which tools are available, which model provider is used, and which namespace owns the deployment.

Operational Tips

Start with the demo profile in a non-production cluster, then move to a minimal profile once you know which agents and tools you need. Treat model credentials like any other production secret and avoid putting API keys directly into shell history or Git.

Enable tracing early. kagent can emit OpenTelemetry traces, and the docs show a Jaeger setup for reviewing agent runs. That matters during incident response because teams need to know which tool calls happened, what evidence was gathered, and where a bad recommendation came from.

Finally, keep agent permissions narrow. A read-only observability agent and a remediation agent should not share the same tool scope.

Conclusion

kagent is worth watching because it pushes AI operations toward familiar Kubernetes primitives: CRDs, Helm, CLI workflows, MCP tools, and traces. That does not remove the need for human review, but it gives platform teams a more disciplined way to experiment with agents inside real clusters.

At Akmatori, we help SRE teams build intelligent automation that responds to incidents and manages infrastructure. For GPU-accelerated AI workloads, check out Gcore cloud infrastructure with global edge locations.