Kubernetes Pods May Not Be the Right Deployment Unit for AI Agents

The Pod deployment problem for AI agents

As organizations deploy AI agents at scale, a fundamental question has emerged: should Kubernetes Pods remain both the execution environment and the deployment unit for these workloads? According to work detailed by Lin Sun in a CNCF blog post, the answer may be no.

The kagent project initially adopted a straightforward approach—giving each agent its own Pod, Service, and ServiceAccount. This provided process isolation, identity management through ServiceAccount, network policy enforcement, and per-agent observability. The project later added stronger isolation through the Kubernetes Agent Sandbox.

But agents behave differently than the microservices Kubernetes was designed to orchestrate. Unlike continuously available services, agents often wake only when assigned tasks, run briefly, then sit idle. They spawn subagents for parallel work, act on behalf of users, and pause indefinitely awaiting human approval. A dedicated Pod for each potential agent becomes wasteful when most remain dormant.

Agent Substrate introduces a control plane layer

Google's Agent Substrate, introduced alongside Agent Sandbox, takes a different architectural approach. Rather than treating each agent as a Kubernetes workload, it adds a control plane above Kubernetes that manages logical agents separately from their execution environment.

Under this model, Kubernetes continues managing Pods, networking, storage, and compute resources. The Agent Substrate layer handles lifecycle and placement of AI actors onto execution workers. The abstractions mirror familiar Kubernetes concepts: WorkerPools correspond to NodePools, Workers to Nodes, and ActorTemplates to Pod specifications.

Kubernetes sees only WorkerPools and ActorTemplates. Workers and Actors exist in Agent Substrate's own API. Each Worker maps to a single Pod, but an Actor—the logical unit representing an AI agent—is scheduled onto a Worker when work arrives and suspended, resumed, or removed as needed. A fixed pool of long-lived Pods can support far more logical agents than one-Pod-per-agent deployments.

Identity and policy implications

This separation creates new questions for platform engineers. If an Actor can run on any Worker, identity may need to attach to the ActorTemplate, namespace, tenant, and version rather than to a specific Pod or Service. Access control, network policy, and runtime permissions may require expression at the template level with per-Actor overrides.

Ownership, quotas, and billing become more complex when execution no longer maps one-to-one with Pods. Observability must track the logical agent, associating logs, traces, and audit records with the Actor regardless of where it was scheduled.

Why it matters

This architectural shift addresses real operational challenges as AI agent deployments scale. Organizations running hundreds or thousands of agents face resource waste and management complexity with traditional Pod-per-agent models. Agent Substrate's approach maintains Kubernetes as the infrastructure layer while introducing abstractions better suited to agent workload patterns. The work signals that AI workloads may require new primitives even as they run on established container platforms.

The kagent project supports Agent Substrate integration, and the approach was featured in the Kubernetes Podcast from Google. Details were first reported by Lin Sun in the CNCF blog post.