kagent 1.0: Run AI Agents on Kubernetes — Fix These 4 Now

Kagent 1.0 shipped on November 9, the opening day of KubeCon NA 2026 in Salt Lake City, introducing four breaking changes from 0.10.x: the AgentInstance custom resource is replaced by Session with no automatic migration, the Agent resource becomes an explicit triad referencing an AgentTemplate and a Harness, all environment variables gain a KAGENT_ prefix, and the bundled kmcp mcpservers.kagent.dev CRD and Grafana MCP server are removed from the Helm chart. The release runs every agent conversation on Agent Substrate, a sandboxed compute layer that gives each conversation its own gVisor sandbox with no ambient credentials and no network access unless an EgressPolicy allows it, and can suspend to object storage and resume on a different Worker. Memory configuration moves from the Agent to the Harness under spec.kagent.memory, and the new WorkerPool CRD controls how many pre-warmed Workers to keep running and whether they use gVisor or microVM isolation.

kagent 1.0 dropped on November 9 — opening day of KubeCon NA 2026 in Salt Lake City — and it is not an incremental update. The jump from 0.10.x is a deliberate clean break: renamed custom resources, dropped bundled tools, a new runtime model built on Agent Substrate , and four concrete changes you need to make if you have any kagent workloads running. The Kubernetes community is spending this week debating what it means to operate AI agents in production. kagent 1.0 is the clearest answer anyone has shipped so far. Four Breaking Changes If you are running kagent 0.10.x, here is what changed and what you need to do. 1. AgentInstance Is Now Session The CRD that tracked a conversation was AgentInstance . It is gone. The replacement is Session . There is no automatic migration — existing AgentInstance resources will not convert. You need to recreate them. One behavior change to note: a Session runs the agent revision it was created from for its entire lifetime. Editing an Agent resource affects only Sessions created afterward, not any currently running ones. 2. The Agent Resource Is Now a Triad The old model paired Harness and AgentTemplate through implicit label matching — subtle and error-prone. The new Agent CRD in the api.kagent.dev group makes the pairing explicit: apiVersion: api.kagent.dev/v1alpha1 kind: Agent metadata: name: my-ops-agent spec: template: name: ops-agent references an AgentTemplate harnessRef: name: default-harness references a Harness Memory also moved. In 0.x it lived on the Agent. In 1.0 it lives on the Harness under spec.kagent.memory . Memory configuration is now a runtime policy decision, not a per-agent one — the right model for teams managing many agents. 3. Environment Variables Got a Namespace All environment variables are now prefixed with KAGENT . If you have CI/CD pipelines, Helm values overrides, or init scripts that set agent environment variables, review them now. Anything that worked unprefixed in 0.x will silently fail in 1.0. 4. kmcp and Grafana MCP Are No Longer Bundled kagent 0.x installed the mcpservers.kagent.dev CRD from kmcp and a Grafana MCP server as part of the Helm chart. Both are gone from 1.0. If your agents relied on the bundled Grafana MCP integration, you need to install and configure both separately. The removal is intentional — the bundled observability agent that consumed the Grafana MCP was removed, so the chart stopped shipping something with no consumers in production. What You Get in Return: Agent Substrate The breaking changes buy you something real. kagent 1.0 runs every agent conversation on Agent Substrate https://kagent.dev/docs/kagent/1.x/about/architecture/agent-substrate/ , a sandboxed compute layer that fundamentally changes what running an agent means. Every conversation gets its own gVisor https://github.com/google/gvisor sandbox: no ambient credentials, no network access unless an EgressPolicy explicitly allows it, full process and filesystem isolation. You do not configure this per agent — it is the default. If you have been running agents with broad cluster permissions because there was no better option, 1.0 gives you a better option. The sandbox can also suspend to object storage and resume on a different Worker. An agent waiting for user input stops consuming compute. It is restored exactly where it left off when the next message arrives. This matters for cost, and it matters for reliability when Workers get evicted. WorkerPool is the CRD that controls the sandbox fleet — how many pre-warmed Workers to keep running and whether they use gVisor or microVM isolation. Harness: Separating Policy From Behavior The Harness resource handles everything about how an agent runs: which engine executes it, the WorkerPool it draws from, where snapshots go, and memory configuration. The AgentTemplate handles behavior — system prompt, tools, model. The explicit Agent resource pairs them. This separation matters when you operate at scale. A platform team provisions a Harness once per environment. Agent teams pick an AgentTemplate. Runtime security policy no longer lives scattered across 20 different agent definitions. The Harness also defines which engine runs the agent. Built-in options are kagent native engine , codex , claude , and byo . That last option is significant: any container implementing kagent’s A2A gRPC contract https://kagent.dev/docs/kagent/1.x/agents/bring-your-own-agent/ — a gRPC service and a readiness endpoint — becomes a first-class kagent citizen. Existing agents built on other frameworks gain Kubernetes lifecycle management, observability, and security without a rewrite. Installing kagent 1.0 helm upgrade --install kagent \ oci://ghcr.io/kagent-dev/kagent/helm/kagent \ --namespace kagent \ --timeout 12m The chart installs Agent Substrate alongside kagent. Post-install, you get 124 pre-built MCP tools covering Kubernetes, Helm, Istio, Argo Rollouts, Prometheus, and Cilium. The official 1.0 release notes https://kagent.dev/docs/kagent/1.x/reference/release-notes/1.0/ have the complete migration checklist. Bottom Line The conventional wisdom is that Kubernetes is too operational for AI agent work — that you should use a lighter framework and avoid the YAML tax. kagent 1.0 is a direct argument against that position. Agents that survive pod eviction, run with real network isolation, can be audited through standard Kubernetes tooling, and plug into an existing Helm-based deployment pipeline — that is not a Kubernetes-flavored prototype. That is a production runtime. The four breaking changes are real work. They are also the cost of moving from a prototype-grade agent runner to something you can actually operate. KubeCon NA runs through November 12. The conference coverage https://dev.to/saaro net/kubecon-na-2026-kubernetes-becomes-the-operating-platform-for-production-ai-and-agents-17k5 and community writeups https://www.signadot.com/blog/running-ai-agents-on-kubernetes/ on running agents in production are worth reading alongside the release notes if you are evaluating this stack.