Pods as Workers, Not Agents: Rethinking the Deployment Unit for AI Agents on Kubernetes

In a CNCF blog post, Lin Sun draws on work in the kagent project to argue that the Pod may be the right execution unit for an agent while no longer being the right deployment, identity, or lifecycle unit.

The questions that surface once agent counts grow are familiar: how to isolate one agent from another, how each gets its own identity, how to enforce access and network policies, how to see what an individual agent is doing, and who owns an agent for multi-tenancy. These are agent platform questions rather than Kubernetes questions, even though Kubernetes is where the answers have to be expressed.

One straightforward approach is to make each agent a first-class Kubernetes workload with its own Pod, Service, and ServiceAccount. This is the approach kagent adopted after initially running many agents inside a single runtime. It provides process and container isolation, a ServiceAccount identity that plugs into existing authentication and authorization, the ability to apply Kubernetes network and admission-policy mechanisms, per-agent attribution of logs, metrics, and traces, and Kubernetes-native scheduling and resource management. kagent subsequently added support for stronger isolation through the Kubernetes Agent Sandbox project.

The difficulty is that agents do not behave like the microservices these abstractions were designed around. Unlike services expected to be continuously available, an agent may wake only when assigned a task, run for seconds or minutes, and then sit idle, making a dedicated Pod per potential agent wasteful. Agents may also spawn subagents to run subtasks in parallel, act on a user's behalf, and pause indefinitely while waiting for human approval. Pods are excellent execution environments, but that does not make them the right lifecycle abstraction for short-lived, bursty work of this shape.

Another approach is to stop treating each agent as a Kubernetes workload and instead introduce a control plane above Kubernetes. Agent Substrate, which Google introduced alongside Agent Sandbox in its Agent Sandbox and Agent Substrate announcement, takes this approach. kagent supports it, as described in kagent's Agent Substrate integration guide.

Agent Sandbox provides an isolated execution environment, while Agent Substrate manages how logical agents are placed onto and moved between workers. Kubernetes continues to manage Pods, Services, networking, storage, and compute, while the layer above manages the lifecycle and placement of AI actors onto execution workers. Its abstractions mirror concepts platform engineers already know: a WorkerPool is analogous to a NodePool, Workers to Nodes, and an ActorTemplate to the declarative specification of a Pod.

Kubernetes is aware only of WorkerPools and ActorTemplates; Workers and Actors live in Agent Substrate's own CLI and API, with each Worker mapped to a single Pod. An Actor, the entity that "acts as" an AI agent, is a logical unit scheduled onto a Worker when work arrives and suspended, resumed, or removed as its lifecycle requires. This allows a fixed pool of long-lived Pods to support far more logical agents than would be practical with a dedicated, continuously running Pod for each one. Pods become the execution workers, not the deployment model for agents.

The consequences reach beyond scheduling efficiency. Sun argues that if an Actor can run on any Worker, identity may belong to the ActorTemplate, namespace, tenant, and version rather than to a Pod or Service. Access control, network policy, and runtime permissions may likewise need to be expressed at the template level with per-Actor overrides. Ownership, quotas, and billing become harder to reason about once execution is no longer one-to-one with Pods, and observability must follow the logical agent, associating logs, traces, and audit records with the Actor wherever it was scheduled.

None of this displaces Kubernetes, which remains the industry standard platform for microservices and inference workloads at scale. The open question is narrower: whether the Pod, having proved itself as an execution environment, should also remain the unit of deployment, identity, and lifecycle for AI agents. That is what Agent Substrate is exploring through kagent. The Kubernetes Podcast from Google subsequently featured Sun's post in its weekly news roundup.