The Pod, Kubernetes' core execution unit, may no longer be the right abstraction for deploying, managing, and tracking AI agents at scale, according to a CNCF blog post by Lin Sun drawing on work from the kagent project. As agent counts grow, familiar platform questions emerge: how to isolate agents from one another, assign each its own identity, enforce access and network policies, observe individual agent activity, and manage multi-tenancy ownership. Sun argues these are agent platform questions rather than Kubernetes questions, even though Kubernetes is where the answers must be expressed.
One straightforward method is to make each agent a first-class Kubernetes workload with its own Pod, Service, and ServiceAccount—the approach kagent adopted after initially running many agents inside a single runtime. This provides process and container isolation, a ServiceAccount identity that integrates with 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 later added support for stronger isolation through the Kubernetes Agent Sandbox project. The difficulty is that agents don't 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.
According to the post, Pods are excellent execution environments, but that doesn't 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—the path Agent Substrate takes. Google introduced Agent Substrate alongside Agent Sandbox, and kagent now supports it. 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. 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, allowing 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.
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—what Agent Substrate is exploring through kagent. Organizations betting on agent-based architectures will need to choose whether to treat scaling and identity as Kubernetes primitives or as concerns for a higher control plane. The shift could reshape how infrastructure teams budget, monitor, and secure workloads that don't fit the always-on service model that dominated the last decade.