Kubernetes Pods are excellent execution units. They provide scheduling, resource controls, networking, workload identity integration, and a natural boundary for security and observability.
That does not automatically make a Pod the right representation of an AI agent.
Enterprise agent platforms need to distinguish two concepts that are easy to collapse during early implementations: the logical agent and the runtime worker executing its current task. Treating them as the same object can work for prototypes and continuously running agents. At scale, it creates idle infrastructure, slow burst handling, fragmented identity, and weak lifecycle semantics.
The durable pattern is to let Kubernetes manage execution workers while an agent control plane manages agent identity, state, policy, placement, and lifecycle. Pods remain essential. They become workers rather than the agent itself.
Why one Pod per agent is an attractive first design
The one-agent-per-Pod model solves several real problems quickly.
- A Pod provides a process and container isolation boundary.
- A ServiceAccount gives the workload a Kubernetes identity.
- NetworkPolicy and admission policy can constrain its environment.
- CPU and memory requests make resource consumption schedulable.
- Logs, metrics, and traces can be attributed to a workload instance.
- Existing GitOps, deployment, and incident-response practices remain usable.
For a small number of high-value agents, those benefits may outweigh the overhead. The model is understandable and conservative. It uses boundaries that platform and security teams already know how to operate.
The problem appears when the organization assumes that the execution container is also the durable identity and lifecycle of the agent.
Agents do not behave like ordinary services
A typical service is expected to remain available and handle a continuing stream of requests. An agent may wake up for a task, run for seconds or minutes, wait for a human decision, delegate work to subagents, and then remain idle for hours.
These characteristics create a different workload shape:
- Bursty demand: a single business event can fan out into many parallel agent tasks.
- Long idle periods: logical agents may exist without needing compute.
- External waiting: execution may pause for approval, data, or another system.
- Variable duration: tasks range from short tool calls to extended research or coding sessions.
- Delegated authority: an agent often acts on behalf of a user or workflow rather than only as itself.
- Stateful continuation: a later execution may need to resume the same logical conversation or plan on a different worker.
Keeping one Pod alive for every logical agent reserves capacity for identities that are not doing work. Creating a fresh Pod for every short task can introduce startup latency and control-plane churn. Encoding state inside the Pod makes rescheduling and recovery harder.
The architectural question is therefore not whether Kubernetes should run agents. It is which responsibilities belong to Kubernetes and which belong to an agent-specific control plane.
The runtime boundary: agents, actors, and workers
A recent CNCF article describing kagent’s agent-substrate architecture illustrates this separation. Kubernetes continues to manage Pods, networking, storage, and compute. A higher-level control plane manages logical actors and places them onto a pool of execution workers.
In that model:
- The logical agent has durable identity, ownership, policy, configuration, and state.
- An agent task or actor instance represents a unit of active execution.
- A worker is a sandboxed runtime capable of executing one or more assigned actors.
- A worker pool defines capacity, runtime profile, isolation class, and placement characteristics.
Agent-substrate is one implementation, not a universal enterprise standard. Its value for platform design is the principle it demonstrates: logical lifecycle can be decoupled from Pod lifecycle without removing Kubernetes from the architecture.
Six contracts the control plane must preserve
Decoupling an agent from a Pod improves efficiency only if the platform preserves the controls that dedicated Pods made easy.
1. Durable agent identity
An agent needs an identity that survives worker replacement. That identity should identify the agent definition, tenant, owner, environment, risk tier, and approved capabilities.
The worker also needs its own workload identity. The two must not be confused. A worker identity proves which runtime is communicating with the platform. The agent identity determines which business permissions and policies apply to the assigned execution.
When an agent acts for a person, the authorization decision should include delegated user context with explicit scope and expiry. Copying a user’s full credentials into a worker is not delegation.
2. Execution leases
Placement should create a time-bound execution lease binding an agent task to a specific worker. The lease should include the agent identity, policy revision, tool permissions, state reference, deadline, and expected resource profile.
Leases make reassignment and failure handling explicit. If a worker disappears, the control plane can determine whether the task is safe to retry, must resume from a checkpoint, or requires human review.
3. Isolation classes
Sharing workers does not mean sharing trust. The platform needs multiple runtime profiles based on risk.
- Low-risk, read-only tasks may use a warm multi-tenant worker pool.
- Tasks handling confidential data may require stronger sandboxing and tenant-dedicated workers.
- Agents with write access to production systems may require a dedicated Pod or ephemeral sandbox per execution.
- Untrusted code execution may require gVisor, microVMs, or another hardened isolation boundary.
The scheduling decision should derive from policy. Developers should request a workload class rather than select a weaker runtime to reduce latency.
4. Policy attribution
Kubernetes policy usually sees the Pod, namespace, and ServiceAccount. A shared worker introduces another logical principal inside that boundary. The platform must propagate agent, tenant, task, and delegated-user context to every policy enforcement point.
Tool gateways, model gateways, data APIs, and egress proxies should authorize the logical execution, not merely trust the worker’s network location. Audit events should record both worker identity and agent identity so investigators can reconstruct who did what and where it ran.
5. Externalized state and checkpoints
Agent state should not depend on the continued existence of a worker Pod. Conversation state, plans, artifacts, approval state, and checkpoints need durable storage with tenant-aware encryption and retention controls.
Externalizing state allows the platform to release compute while an agent is idle and rehydrate it when work resumes. It also creates a controlled recovery point instead of treating the worker filesystem as an accidental system of record.
6. End-to-end observability
Pod-level telemetry remains necessary but is no longer sufficient. Operators need to follow a logical agent across workers and over time.
Every execution should carry stable correlation fields such as:
- agent, tenant, task, session, and parent-task identifiers;
- worker and worker-pool identity;
- policy, prompt, model, and tool versions;
- delegated user and approval references where permitted;
- token, latency, tool-call, cost, and outcome signals;
- checkpoint, retry, reassignment, and termination reasons.
This creates observability for the business execution rather than only for the container currently hosting it.
A reference enterprise architecture
A practical runtime separates responsibilities across four layers.
Agent control plane
The control plane stores agent definitions, ownership, policy, lifecycle, state references, and desired runtime class. It accepts tasks, decides placement, issues leases, tracks execution, and coordinates retries or resumptions.
Worker pools
Kubernetes Deployments or other controllers maintain warm capacity for defined execution profiles. Pools may differ by tenant, geography, accelerator, sandbox technology, network access, or data classification.
Shared platform gateways
Model, tool, MCP, data, and egress gateways enforce logical identity and policy. They keep privileged credentials out of agent code and provide consistent rate limits, approval checks, observability, and revocation.
Durable state and evidence
State services store checkpoints and artifacts. An evidence plane records immutable links between the agent definition, execution lease, policy decision, worker, model interaction, tool call, and outcome.
Kubernetes remains the infrastructure substrate. The agent control plane provides semantics Kubernetes was not designed to infer.
Multi-tenancy must shape worker placement
Worker utilization can improve dramatically when idle logical agents do not retain Pods. That benefit should not override tenant boundaries.
Platform teams should define placement rules covering:
- whether tenants may share a worker process, Pod, node, or cluster;
- which data classifications require dedicated runtime capacity;
- how memory, filesystems, caches, and credentials are cleared between assignments;
- whether agent-generated code can execute and under which sandbox;
- which tools and destinations each pool can reach;
- how noisy-neighbor behavior is detected and constrained;
- where state and inference traffic may be processed geographically.
There is no single correct sharing boundary. The platform should offer a small set of reviewed isolation classes and make the selected class visible in cost, latency, and risk reporting.
When one Pod per agent is still the right answer
Decoupling should not become an objective by itself. A dedicated Pod remains a strong choice when:
- the agent is continuously active or exposes a stable service endpoint;
- startup latency is acceptable and the fleet is small;
- the workload needs strong tenant or process isolation;
- it runs untrusted code or privileged tools;
- its memory and resource profile do not fit a shared pool;
- existing Kubernetes controls provide sufficient lifecycle semantics;
- the added agent scheduler would cost more to operate than it saves.
The mature platform supports more than one runtime pattern. It chooses the boundary based on workload behavior and risk rather than forcing every agent into the same optimization.
Measure the runtime as a platform product
Worker density is useful, but cost efficiency alone is an incomplete success measure. Track flow, reliability, isolation, and control together.
- Task queue time and time to first execution
- Warm-start and cold-start latency
- Active versus idle worker utilization
- Logical agents per worker and per isolation class
- Checkpoint, resume, retry, and reassignment success rates
- Policy denials and unauthorized cross-tenant attempts
- State cleanup and credential revocation failures
- Cost per successful agent task
- Trace and audit coverage from task request to external side effect
A cheaper runtime that cannot explain an agent’s actions is not an enterprise improvement.
A staged adoption path
1. Separate identifiers before changing runtime
Introduce stable agent, task, tenant, and worker identifiers in the current platform. Propagate them through logs, traces, policy decisions, and tool calls. This exposes hidden coupling before a scheduler is introduced.
2. Externalize state
Move durable state and artifacts out of the Pod. Define checkpoint, retry, expiry, encryption, and deletion semantics. Test recovery from worker termination.
3. Add one low-risk worker pool
Select bursty, read-only tasks with clear resource limits. Compare queue time, utilization, cost, and operational effort with the dedicated-Pod baseline.
4. Add policy-aware placement
Introduce reviewed isolation classes and execution leases. Integrate logical identity with tool, model, data, and egress gateways. Exercise tenant separation and credential revocation.
5. Expand only with evidence
Move higher-risk agents after proving state hygiene, observability, rollback, and incident response. Keep dedicated Pods as an explicit option rather than treating them as a failed legacy design.
Pods should host work, not define the agent
The Pod remains one of the strongest execution boundaries available to cloud-native platforms. The mistake is asking it to carry semantics it does not own: durable agent identity, delegated authority, conversation lifecycle, human approval, and cross-execution state.
Enterprise agent platforms should model those concerns explicitly. Kubernetes can then do what it does best — schedule and isolate execution — while the agent control plane decides which logical work runs where, under whose authority, with which policy, and with what evidence.
That separation improves utilization, but its greater value is governance. It allows the platform to scale agents without losing the identity and accountability that production systems require.