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

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, a sandboxed compute layer that fundamentally changes what running an agent means.

Every conversation gets its own 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 — 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 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 and community writeups on running agents in production are worth reading alongside the release notes if you are evaluating this stack.