kagent’s Agent-Substrate Shows Why AI Agents Need More Than a Kubernetes Pod

When engineers at Solo.io began building kagent, an open source project GitHub describes as “Cloud Native Agentic AI,” they started with the simplest possible design: a single shared runtime that hosted every agent at once. It worked fine for demos and proofs of concept. It did not survive contact with production. In a July 14 CNCF blog post, Lin Sun, a CNCF Ambassador affiliated with Solo.io, traced kagent’s path from that shared runtime through a one-Pod-per-agent architecture and into agent-substrate, a new control plane the project is now building on top of Kubernetes because even Pod-per-agent is starting to strain under how AI agents actually behave.

From One Shared Runtime to One Pod Per Agent

In kagent’s original design, agents ran inside the kagent runtime itself rather than as independent Kubernetes workloads: one runtime, many agents, no separation between them. That simplicity did not survive growth. As the number of agents increased, Sun writes, new questions emerged that the shared-runtime model had no answer for: how to isolate one agent from another, how to give each agent its own identity, how to enforce access and network policy per agent, how to tell what an individual agent was doing, and how to support multiple owners and tenants on the same platform. Sun’s framing is blunt: “These aren’t Kubernetes questions. They’re agent platform questions.”

kagent’s first fix was to give every agent its own Pod, Service, and ServiceAccount, and that single change solved most of the immediate problems. A Pod provided process and container isolation. A ServiceAccount gave each agent a real Kubernetes identity that plugged directly into existing authentication and authorization. Network policies, admission policies, and other security controls kept working without modification, and observability tooling could finally attribute logs, metrics, and traces to a specific agent instead of a shared pool of runtime activity. Scheduling and resource management became Kubernetes-native as a side effect. Later, kagent added agent-sandbox on top of that for even tighter isolation between agents running on the same cluster.

Why Agents Don’t Behave Like Microservices

For a while, one-Pod-per-agent felt like the right abstraction. Then the kagent team compared agents to the microservices Kubernetes was actually built around, and the comparison broke down. Most services run continuously for days at a stretch. An AI agent’s working life can be measured in seconds or minutes, its workload is bursty rather than steady, it can spawn subagents on demand, and it frequently acts on behalf of a specific user rather than running as a fixed, anonymous service. Sun poses the resulting question directly: are Kubernetes Pods really the right lifecycle abstraction for workloads that short-lived and unpredictable? Pods remain, in her words, “excellent execution environments.” The catch is that being a good execution environment does not automatically make something the right unit for deployment, identity, and lifecycle management too.

Enter Agent-Substrate: A Control Plane Above Kubernetes

kagent’s answer is agent-substrate, an additional control plane layered on top of Kubernetes rather than a replacement for it. Kubernetes keeps doing what it already does well: managing Pods, Services, networking, storage, and compute resources. Agent-substrate sits above that layer and takes over the lifecycle and placement of AI actors onto execution workers.

New Abstractions Modeled on Familiar Kubernetes Shapes

Rather than inventing an unfamiliar vocabulary, agent-substrate mirrors Kubernetes’ own object model. A WorkerPool plays the role a NodePool plays for regular nodes, defining a collection of execution Workers that can host Actors. An ActorTemplate defines how an Actor should execute, the same way a PodTemplate defines how a Pod gets created, and an Actor is agent-substrate’s stand-in for a Pod: the object that actually represents a running agent. In kagent’s own default WorkerPool configuration, the Workers run a specific ateomImage, currently pinned to ghcr.io/kagent-dev/substrate/ateom-gvisor:v0.0.6, and ActorTemplate resources include a runsc configuration that serves as the execution entrypoint.

Sandboxing Actors With gVisor

That ateom-gvisor image name points to gVisor, an open source, Linux-compatible sandbox originally built at Google. According to gVisor’s own project site, it works by intercepting the system calls a sandboxed application makes to the kernel, which shields the host from the application running inside the sandbox, and it layers additional isolation between the sandbox and the host on top of that. gVisor is built to plug into existing container tooling, including Docker, Kubernetes, and containerd, without requiring a full virtual machine. For agent-substrate, that matters because an Actor is executing code and tool calls that are far less predictable than a typical microservice request, and a stronger sandbox boundary around each Actor limits the blast radius if an agent misbehaves or gets manipulated into doing something it should not.

Four Questions Agent-Substrate Still Has to Answer

Sun is explicit that agent-substrate is an exploration in progress, not a finished specification. The CNCF post frames four areas the project is still working through.

Agent Identity

Today, an agent’s Kubernetes identity is tied to its Pod and Service. Agent-substrate raises the possibility that identity should instead belong to the ActorTemplate, namespace, tenant, and version, independent of whichever Worker happens to be executing the Actor at any given moment. Sun points to a separate blog post by Christian Posta for a deeper treatment of that specific question.

Security and Policy

Kubernetes policy today attaches to Pods, Services, or ServiceAccounts. Agent-substrate asks whether access control, network policy, and runtime permissions should instead be expressed at the ActorTemplate level and selectively overridden for individual Actors, and whether a project called agentgateway could mediate that traffic and enforce the resulting policies.

Ownership and Multi-Tenancy

Once agent execution is no longer tied one-to-one with a Pod, ownership gets harder to track. Agent-substrate still has to settle who owns a given Actor versus who owns the ActorTemplate it was created from, and how quotas, billing, and lifecycle management work across multiple teams and tenants sharing the same platform.

Observability That Follows the Agent, Not the Pod

An Actor can execute on different Workers at different points in its lifetime, which breaks the usual assumption that a Pod’s logs, metrics, and traces are the complete observability record. Sun argues that logs, traces, audit records, and execution history all need to stay attached to the logical Actor itself, regardless of which Worker happened to run it at any given time.

What This Means for Teams Running Agents on Kubernetes

Kubernetes is not going anywhere as the execution layer. Sun’s own conclusion is that it “remains an exceptional platform for running microservices and inference workloads at scale,” and agent-substrate does not dispute that. What it questions is whether the Pod should also double as the deployment, identity, and lifecycle unit for something as ephemeral, bursty, and self-spawning as an AI agent.

That distinction matters most for platform teams who, like kagent itself, started by giving every agent its own Pod and ServiceAccount because it was the fastest way to get isolation and identity for free. That pattern still works today, and nothing here suggests abandoning it on a deadline. But it is worth treating agent-substrate as a signal to watch rather than a drop-in fix: kagent frames the entire post as open questions the project is actively exploring, not a settled architecture, and the identity, policy enforcement, and observability plumbing described above are still being built out. Teams evaluating whether to follow kagent’s lead should wait for those pieces, particularly agent-substrate’s policy story around agentgateway and its answer to multi-tenant ownership, to mature before rearchitecting a production agent platform around them.

kagent is developed fully in the open. Its GitHub repository has drawn 652 forks and roughly 3,300 stars, and both kagent and the agent-substrate work described here are open to outside contributors through the project’s public community channels.

Sources

• CNCF Blog: Is a Pod the Right Deployment Unit for an AI Agent?
• GitHub: kagent-dev/kagent, Cloud Native Agentic AI
• gVisor: The Container Security Platform

Featured image: Autonomous robots move along a shared grid track inside an Ocado automated warehouse, a physical echo of the many independent AI agent Actors that agent-substrate is built to coordinate. Photo by Techwords, CC BY-SA 4.0 (CC BY-SA 4.0) via Wikimedia Commons; cropped, resized, and converted to WebP.