Welcome to the NZRT Wiki Podcast. Today we’re looking at Kagent Overview.

So, what exactly is Kagent? At its core, Kagent is a Kubernetes-native AI agent framework. It was contributed to the Cloud Native Computing Foundation — the CNCF — by Solo.io, and it made its debut at KubeCon EU in 2025. The idea is straightforward but powerful: you define AI agents in YAML, deploy them as Kubernetes workloads, and those agents use a large language model — like Claude or one of several other options — to automate cluster operations, troubleshoot issues, and handle DevOps workflows directly inside your cluster.

What makes this interesting is that your agents aren’t some external service bolted onto your cluster. They run as standard Kubernetes Pods. That means they’re fully observable, they can be restarted, they can be scaled, and they fit right into your existing operational patterns. You get multi-LLM provider support out of the box — Anthropic, OpenAI, Azure OpenAI, Google Vertex AI, and even Ollama for local models. You also get a built-in tool ecosystem using the MCP protocol for Kubernetes operations, plus a web UI, a command-line tool called kagent, and of course the YAML-based interface you’d expect in any Kubernetes-native project.

Now let’s talk about how the architecture hangs together. Picture your Kubernetes cluster with four main moving parts working in concert.

First, you have the Controller. This is a Go deployment that sits and watches for changes to the custom resource definitions — the CRDs — that Kagent introduces. When you create or update an agent definition, the Controller is what responds and creates the underlying Pods and Services.

Second, there’s the ModelConfig. This is a CRD that defines your LLM provider — so, say, Anthropic — along with the specific model name you want to use and a reference to a Kubernetes Secret that holds your API key. This keeps your credentials managed the Kubernetes way, which is exactly what you’d want.

Third, you have the MCPServer CRD. This is what exposes the tools your agent can actually call. Think of things like kubectl operations, Helm chart management, Argo workflows, and so on. These tools follow the MCP protocol, and they’re what give your agent its ability to actually do things in the cluster rather than just talk about them.

And fourth, bringing it all together, you have the Agent CRD itself. This combines your ModelConfig, your MCPServer tool definitions, and a system prompt into a single running Pod. That’s your agent — live, running, ready to take requests.

So how does it actually work when you send a message? The flow goes like this. You send a message to the agent — through the web UI, the CLI, or the API. The agent takes your message along with its configured system prompt and sends it to Claude, or whichever LLM you’ve set up. Claude then looks at the available tools from the MCPServer and picks the right ones to use. Those tools execute against the Kubernetes API — so actions like getting pod status, reading logs, applying a manifest, or checking service connectivity happen in your actual cluster. Claude then takes those results, synthesises them, and sends back a coherent response. And throughout all of this, every action is traced via OpenTelemetry, so you have full observability into what your agent did and why.

Now, thinking about how NZRT would actually use this — there are four key patterns worth knowing about.

The first is an SRE troubleshooter agent. This is a read-only diagnostics setup, using tools to get resources, read pod logs, pull events, and describe resources. Safe, observational, great for first-line investigation.

The second is a deployment helper. This one steps it up a notch — it can generate manifests and apply them, patch resources, and check service connectivity. Your agent becomes an active participant in your deployment process.

The third is a Helm operator. Using the Helm MCP server, your agent can manage charts — installing, upgrading, rolling back — all driven by natural language instructions.

And the fourth is a monitoring analyst. Hook your agent up to the Prometheus MCP server and it can run metrics queries, surface anomalies, and give you plain-language summaries of what your cluster is doing.

If you want to go deeper from here, there are a few related wiki pages to check out. Kagent Setup covers the step-by-step install and configuration for NZRT specifically. Kagent RBAC and Security goes into service accounts, roles, and how to restrict what tools an agent is allowed to use — important for any production setup. And Kagent Agents and Tools gives you the full MCP tool reference along with example agent CRD definitions you can adapt.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.