The kagent project proposes a new approach to deploying AI agents on Kubernetes, suggesting that instead of giving each agent its own Pod, agents should be scheduled as logical Actors onto long-lived worker Pods. This addresses the inefficiency of one Pod per agent, given that agents are bursty, short-lived, can spawn subagents, and may wait for human approval.
SynthePulse Insight · AI deep reading
Version 1 · 1 source
As the number of AI agents grows, is the Kubernetes Pod still the right unit for deployment, identity, and lifecycle? The kagent project and Google's Agent Substrate propose a new model: Pods as execution workers, with logical agents orchestrated by an upper control plane.
As the number of AI agents grows, a series of issues emerge: how to isolate different agents, how to provide each agent with a distinct identity, how to enforce access and network policies, how to observe individual agent behavior, and how to attribute agents in multi-tenant environments. These are agent platform problems, not Kubernetes problems, even though the answers need to be expressed on Kubernetes.
One direct approach is to treat each agent as a first-class Kubernetes workload, with its own Pod, Service, and ServiceAccount. kagent initially ran multiple agents in a single runtime, but later adopted this approach to gain process and container isolation, ServiceAccount identity, network and admission policies, per-agent attribution of logs, metrics, and traces, as well as Kubernetes-native scheduling and resource management. kagent subsequently added stronger isolation support through the Kubernetes Agent Sandbox project.
However, agent behavior differs from the microservices these abstractions were designed for. Agents may only wake up when a task arrives, run for seconds or minutes, and then idle, so reserving a dedicated Pod for every potential agent is wasteful. Agents may also spawn sub-agents to execute subtasks in parallel, act on behalf of users, and pause indefinitely while waiting for human approval. Pods are excellent execution environments, but not necessarily the right lifecycle abstraction for short, bursty work.
Another approach is to introduce a control plane on top of Kubernetes. Google's Agent Substrate, introduced in the Agent Sandbox and Agent Substrate announcements, takes this approach, and kagent supports it as well. Agent Sandbox provides isolated execution environments, while Agent Substrate manages how logical agents are placed onto workers and moved between them. Kubernetes continues to manage Pods, Services, networking, storage, and compute, while the upper layer manages the lifecycle and placement of AI roles. Its abstractions correspond to concepts familiar to platform engineers: WorkerPool is similar to NodePool, Worker is similar to Node, and ActorTemplate is similar to a declarative Pod specification.
In the Agent Substrate model, Kubernetes only sees WorkerPools and ActorTemplates; Workers and Actors exist in Agent Substrate's own CLI and API, with each Worker mapping to a Pod. Actors are logical units that 'play' the role of an AI agent, scheduled onto Workers when work arrives, and suspended, resumed, or removed based on lifecycle needs. This allows a fixed pool of long-running Pods to support far more logical agents than a model with one continuously running Pod per agent. Pods become execution workers, not the deployment model for agents.
The implications of this change go beyond scheduling efficiency. Sun argues that if Actors can run on any Worker, identity may belong to the ActorTemplate, namespace, tenant, and version, rather than to the Pod or Service. Access control, network policies, and runtime permissions may also need to be expressed at the template level, with per-Actor overrides. Once execution is no longer one-to-one with Pods, ownership, quotas, and billing become harder to reason about, and observability must follow the logical agent, correlating logs, traces, and audit records with the Actor regardless of where it is scheduled.
None of this replaces Kubernetes; it remains the industry-standard platform for large-scale microservices and inference workloads. The open question is narrower: Pods have proven themselves as execution environments, but should they continue to serve as the deployment, identity, and lifecycle unit for AI agents? This is exactly the question Agent Substrate explores through kagent. Google's Kubernetes Podcast subsequently featured Sun's article in its weekly news roundup.
This article is based on InfoQ's coverage of a CNCF blog post and Google announcements, and is a secondary analysis. All specific claims are drawn from that coverage and have not been independently verified.
The bursty and short-lived nature of AI agents may make the one-agent-per-Pod model on Kubernetes less suitable. Agent Substrate's 'Pod as Worker' model, which manages the lifecycle of logical actors via an upper control plane, may offer a more efficient deployment approach, but identity, policy, and observability need to be adjusted accordingly.
Primary report
Primary source