Pods as Workers, Not Agents: Rethinking the Deployment Unit for AI Agents on Kubernetes
Kubernetes Pod-per-agent model is broken. kagent and Agent-substrate are rethinking deployment units for bursty, hierarchical AI workloads.
Why it matters
As agents move from lab to production, infrastructure design matters: how you containerize and schedule them directly impacts cost, latency, and reliability. This is the emerging discipline of agent ops.
The key facts
10 to knowkagent project challenges 1:1 Pod-to-agent mapping
Agent-substrate proposes control plane scheduling logical Actors onto worker Pods
Key insight: agents are bursty and short-lived, unlike traditional microservices
Agents can spawn subagents and await human approval, creating hierarchical dependencies
Published Aug 2026 — active infrastructure engineering discussion
kagent project challenges the one-pod-per-agent model
Agent-substrate adds control plane for scheduling logical Actors onto long-lived worker Pods
Key agent characteristics: bursty, short-lived, can spawn subagents, may wait for human approval
Addresses container resource efficiency and orchestration for agent workloads
Kubernetes deployment patterns for agents are maturing beyond proof-of-concept
Go to the source
InfoQ AI/MLinfoq.com
Publisher excerpt: Running AI agents on Kubernetes raises a key question: should each agent get its own Pod? The kagent project argues no—agents are bursty, short-lived, can spawn subagents, and may wait for human approval, making one Pod per agent wasteful. Agent-substrate adds a control plane to schedule logical…