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

Running AI agents on Kubernetes forces a basic scheduling question: should each agent own its own Pod. In an InfoQ piece by Mark Silvester, the kagent project answers no. Agents are bursty and short-lived, they can spawn subagents, and they may sit idle waiting for human approval. Treating every agent as a full Pod therefore burns capacity on work that does not need a permanent container footprint.

The proposed alternative is agent-substrate. Instead of one Pod per agent, a control plane schedules logical Actors onto long-lived worker Pods. The Pod becomes a durable execution substrate; the agent becomes a schedulable unit on that substrate. That splits the Kubernetes deployment unit from the agent lifecycle so spawn, wait, and subagent fan-out do not each require a new Pod create/delete cycle.

For engineers building agent systems on Kubernetes, the cost model is the point. A one-Pod-per-agent design multiplies API churn, node pressure, and idle reservation for work that is often minutes of compute and minutes of waiting. Mapping many Actors onto fewer worker Pods keeps the cluster’s unit of isolation and resource accounting at the worker layer while the control plane owns agent identity, placement, and lifecycle. That is closer to how batch and job systems already think about workers versus tasks.

The market context is the rapid move of multi-agent and tool-using systems into production clusters. Kubernetes is the default runtime for many of those systems, so default Pod-per-process habits get copied onto agents without much thought. kagent’s stance is a counter-pattern: reuse the orchestrator’s strengths for long-lived workers, and invent a thinner abstraction for agent-shaped work. Agent-substrate is that abstraction—Actors scheduled by a control plane rather than agents as first-class Pods.

What to watch next is whether Actor-on-worker scheduling becomes the default pattern in agent runtimes that already sit on Kubernetes, and how teams handle isolation, quotas, and failure domains when many Agents share one worker Pod. If human-in-the-loop and subagent spawn stay common, the waste case for Pod-per-agent only gets worse—so the practical design choice is whether your control plane schedules Pods or schedules Actors onto Pods.