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

The event marks a departure from treating AI agents as long-running microservices. Kubernetes Pods were designed for continuous workloads, but AI agents often run intermittently, spawn subagents, or pause for human approval. This mismatch leads to underutilized resources when each agent gets its own Pod. The shift to shared worker Pods addresses this inefficiency by decoupling the logical agent from its execution environment. However, it introduces complexity in tracking agent state, identity, and resource usage across a dynamic pool of workers.

Adopting this model requires engineers to integrate a new control plane like Agent Substrate. The control plane manages agent placement, lifecycle, and identity, while Kubernetes handles the underlying Pods, networking, and compute. This separation allows a fixed number of Pods to serve many more agents, but it also means engineers must learn new abstractions, such as WorkerPools and ActorTemplates, and adapt their tooling for observability, access control, and policy enforcement. The cost is not just operational overhead but also the need to rethink how agents are monitored, secured, and billed.

The change complicates identity and policy management. In a one-Pod-per-agent model, identity is tied to the Pod or ServiceAccount, and policies apply directly to the workload. With shared workers, identity must be abstracted to the ActorTemplate or tenant level, and policies must account for dynamic agent placement. Observability tools must also adapt, as logs, traces, and metrics must follow the logical agent rather than the Pod it runs on. This adds friction for teams already invested in Kubernetes-native tooling but may be necessary for scaling AI agent deployments efficiently.

The approach stops working when agents require strict isolation or long-running state. Shared worker Pods are ideal for stateless, bursty agents but may not suit agents that maintain persistent connections, handle sensitive data, or require dedicated hardware. Engineers must also consider the operational maturity of the control plane, Agent Substrate and similar projects are still evolving, and their abstractions may not yet cover all edge cases. For now, the trade-off favors efficiency over simplicity, but the long-term viability depends on how well these control planes integrate with existing Kubernetes ecosystems.