Agents

Google and kagent Redefine Kubernetes Pods for AI Agents

The kagent project and Google are shifting AI agent deployments on Kubernetes away from dedicated Pods toward a layered architecture that treats Pods as reusable workers.

InfoQ AI6 days agoAgents
Image: InfoQ AI

The kagent open-source project and Google are championing a major shift in how developers deploy AI agents on Kubernetes, arguing that the traditional Pod is no longer the right deployment unit for these dynamic workloads. In a Cloud Native Computing Foundation blog post, researcher Lin Sun highlighted that while Pods excel as execution environments, treating each individual AI agent as a standalone Kubernetes workload leads to massive resource waste. Instead, the community is moving toward a model where Pods act as reusable workers rather than dedicated agents.

Unlike traditional microservices that run continuously, AI agents are highly bursty. An agent might wake up to perform a task for a few seconds, spawn parallel subagents, pause indefinitely for human approval, and then sit idle. To address this, Google introduced Agent Substrate alongside its Agent Sandbox project. Integrated into kagent, Agent Substrate adds a logical control plane above Kubernetes to manage the lifecycle and placement of AI actors onto a fixed pool of long-lived worker Pods.

This new architecture introduces concepts that mirror traditional Kubernetes infrastructure but operate at the agent level. A WorkerPool corresponds to a NodePool, Workers map to Nodes, and an ActorTemplate serves as the declarative specification for an agent, similar to a Pod spec. Under this system, Kubernetes only manages the underlying WorkerPools and ActorTemplates, while the Agent Substrate API schedules logical actors onto workers when tasks arrive. This allows a small pool of persistent Pods to support a much larger number of logical AI agents.

For platform engineers and developers, this shift changes how security, identity, and observability are managed. Because an AI actor can run on any worker Pod, identity and access controls must be defined at the ActorTemplate or namespace level rather than tied to a specific Pod or ServiceAccount. Similarly, observability tools must track the logical agent across different workers, associating logs, traces, and billing metrics with the actor itself.

This is our own summary of reporting by InfoQ AI

More in Agents