As AI agents move from demos into production, the familiar Kubernetes Pod is being reconsidered—not as the thing that is the agent, but as the worker that executes it. In a CNCF blog post highlighted by InfoQ, Lin Sun argues that the Pod may still be the right execution unit for AI agents, while no longer being the best fit for deployment, identity, or lifecycle management.
Why AI agents strain the Pod model
The core problem appears when agent counts grow. Platform teams have to answer questions that sound a lot like Kubernetes concerns—how to isolate agents, assign identity, apply access and network policy, track what each agent is doing, and define ownership in multi-tenant environments. But Sun’s point is that these are really agent platform questions, even if Kubernetes remains the place where they must be implemented.
That mismatch matters because agents do not behave like traditional microservices. They are often not continuously available services with steady traffic. Instead, they may wake up for a task, run for seconds or minutes, then go idle, which makes dedicating a Pod to every potential agent inefficient.
Why a dedicated Pod per agent can waste resources
In addition to bursty runtime behavior, agents may spawn subagents, act on behalf of users, and pause indefinitely while waiting for human approval. That makes them more like intermittent actors than long-running services. Pods work well as execution environments, but Sun argues that does not automatically make them the right lifecycle abstraction for this kind of work.
- Agents may run briefly and then remain idle.
- Agents can launch subagents for parallel tasks.
- Agents may need to pause for human approval.
- One Pod per possible agent can become wasteful at scale.
kagent’s first answer: make agents first-class workloads
One obvious approach is to treat each agent as its own Kubernetes workload, with a Pod, Service, and ServiceAccount. Sun points to this as the route kagent took after initially running many agents inside a single runtime.
That model brings several benefits. Each agent gets process and container isolation, a ServiceAccount identity that works with existing authentication and authorization, and access to Kubernetes network and admission-policy mechanisms. It also allows per-agent attribution in logs, metrics, and traces, while preserving Kubernetes-native scheduling and resource management.
kagent later added support for stronger isolation through the Kubernetes Agent Sandbox project, extending the isolation story beyond the original setup.
Agent Substrate shifts the control plane above Kubernetes
Sun also describes a second model: stop treating each agent as a Kubernetes workload and instead add a control plane above Kubernetes. That is the approach taken by Agent Substrate, which Google introduced alongside Agent Sandbox in its Agent Sandbox and Agent Substrate announcement, and which kagent supports through its Agent Substrate integration guide.
In this design, Agent Sandbox provides the isolated execution environment, while Agent Substrate handles how logical agents are placed onto workers and moved between them. Kubernetes still manages Pods, Services, networking, storage, and compute, but a higher layer manages the lifecycle and placement of AI actors onto execution workers.
The terminology mirrors familiar infrastructure concepts. A WorkerPool is analogous to a NodePool, Workers map to Nodes, and an ActorTemplate is similar to a declarative Pod specification. Kubernetes only sees WorkerPools and ActorTemplates; Workers and Actors live in Agent Substrate’s own CLI and API.
Pods become workers, not deployment units
Under this model, each Worker maps to a single Pod, but the logical Actor—the entity that “acts as” an AI agent—can be scheduled onto a Worker when work arrives and suspended, resumed, or removed as needed. The result is a fixed pool of long-lived Pods supporting far more logical agents than would be practical if every agent had its own always-on Pod.
That is the crux of the article’s argument: Pods remain valuable, but as execution workers rather than the deployment model for agents.
What changes if identity follows the Actor
Sun argues that the consequences go beyond scheduling efficiency. If an Actor can run on any Worker, then identity may belong to the ActorTemplate, namespace, tenant, and version rather than to a Pod or Service. In that case, access control, network policy, and runtime permissions may need to be expressed at the template level, with per-Actor overrides where necessary.
Ownership, quotas, and billing also become more complicated once execution is no longer one-to-one with Pods. Observability has to follow the logical agent, tying logs, traces, and audit records to the Actor regardless of which Worker executed it.
- Identity may shift from Pod-level to ActorTemplate-level.
- Policy may need to be defined for tenants, namespaces, and versions.
- Billing and quota models become less straightforward.
- Logs and traces must follow the logical agent across Workers.
Kubernetes still matters, just in a different role
None of this removes Kubernetes from the stack. Sun’s argument is narrower: the Pod has proved itself as an execution environment, but it may not be the best deployment, identity, and lifecycle unit for AI agents.
Kubernetes remains the industry standard for microservices and inference workloads at scale. The question being explored through kagent and Agent Substrate is whether AI agents need an additional abstraction layer to better match their runtime behavior and operational needs.
The discussion has already surfaced in Google’s ecosystem as well. The Kubernetes Podcast from Google later featured Sun’s post in its weekly news roundup, suggesting the idea is resonating beyond a single project.
Why this debate matters for platform teams
For platform engineers, this is not just a naming exercise. The choice between “one Pod per agent” and “agents scheduled onto shared workers” affects cost, isolation, policy design, observability, and tenancy. It also shapes how teams think about scaling AI systems that are inherently intermittent and interactive rather than continuously serving requests.
Sun’s broader message is that AI agents may need infrastructure built around logical actors, not around the static assumptions of service workloads. Whether Agent Substrate becomes the dominant pattern is still an open question, but the underlying issue is clear: AI agents may need a deployment model that looks less like microservices and more like a managed pool of execution workers.
Explore more: Blog Our Services Contact Us
Source: Original report
Was this helpful?
Last Modified: August 10, 2026 at 4:48 pm
2 views
