Kubernetes
Rethinking Kubernetes Pods for AI Agents: Execution vs. Deployment Units
As AI agent workloads grow, researchers argue Pods remain ideal for execution but may not suit deployment, identity, and lifecycle management—prompting a rethink of container abstraction layers.
InfoQ
Kubernetes Pods have become the go-to building block for containerized systems, but AI agents present a fundamentally different workload pattern that challenges traditional Pod-per-service models. A CNCF analysis by Lin Sun, drawing on insights from the kagent project, proposes a crucial distinction: Pods excel as execution environments for agents but may not be the right abstraction for deploying, identifying, and managing them.
The Mismatch Between Agents and Microservices#
The questions posed by agent-heavy platforms are well-known infrastructure concerns: agent isolation, unique identity assignment, access and network policy enforcement, observability across agents, and ownership in multi-tenant scenarios. Yet these are fundamentally agent-platform problems, not Kubernetes problems—even though the solutions must be implemented within Kubernetes itself.
The initial instinct was direct: assign each agent its own Pod, Service, and ServiceAccount. This approach leverages Kubernetes' mature tooling for container and process isolation, built-in identity management through ServiceAccounts that integrate with existing auth systems, and native mechanisms for network policies, scheduling, and resource management. Kagent initially pursued this path and added support for enhanced isolation via the Kubernetes Agent Sandbox project.
But agents do not behave like the traditional microservices Kubernetes was designed around. Services anticipate continuous availability; agents typically activate for brief periods—seconds to minutes—then sit idle. They may spawn child agents to handle parallel subtasks, act on behalf of individual users, and pause indefinitely awaiting human decisions. Dedicating a Pod to each potential agent becomes wasteful, especially when agents are numerous or lifecycle patterns are dynamic.
A Two-Layer Architecture#
To address these limitations, Google introduced Agent Substrate alongside Agent Sandbox—a control plane that sits above Kubernetes rather than replacing it. Kagent now supports this model, which introduces a cleaner separation of concerns.
Agent Sandbox handles isolated execution; Agent Substrate manages logical agent placement and movement across workers. Kubernetes continues to manage the infrastructure layer—Pods, Services, networking, storage, compute—while the higher abstraction governs agent lifecycle and scheduling.

