The schedulable unit of agent work is the effect, not the pod

Kubernetes schedules pods; a pod is a unit of compute that runs until the process inside it exits. This works for containers because containers are long-running daemons or one-shot jobs whose lifecycle matches exactly the lifecycle of their work. For agents, the pod is a terrible approximation: an agent's internal state — context windows, checkpoints, memory reads — has nothing to do with the compute units you actually schedule and pay for.

The mismatch between pod and effect

An agent may consume 100 tokens on a single tool call and hold its session context alive for an hour (the pod is running, doing nothing). Or it may batch-process 10,000 tokens in 200ms then sit idle (still the same pod). The pod's lifecycle maps to wall-clock runtime; the agent's effect maps to outcome produced. They are different unit measures.

This mismatch drives three material costs:

1. Over-provisioning: You give each agent its own pod with its own memory limits and request allocation, wasting compute for agents that need seconds of attention but occupy a persistent identity.
2. Under-capacity on bursts: When many agents spike at the same time (queue depth increases beyond pod count), queue age grows unbounded because pods are not re-allocatable without preemption — and preemption is expensive when state must be flushed to disk.
3. Scheduling blind spots: Workload shape does not match pod count. Throughput measured in agent effects per hour varies independently from the resource utilization of each underlying compute container.

The effect-based scheduling hypothesis

If you treat each agent's output event — classification, extraction, decision — as a schedulable work item, then queue size represents real outstanding demand, and scheduling decisions can optimize for throughput of verified outcomes rather than wall-clock occupancy.

This does not replace container orchestration entirely. The agent still needs compute; its sessions need isolation. But the scheduler's top-level objective function — what it optimizes over — moves from running pods to producing outcomes. You pay for the effect you see, not the machinery that produced it. This changes your optimization vector: from capacity allocation to outcome yield.

The practical implication

Fleet management becomes simpler when you know which agents produce outcomes and which do not. If Agent A produces five verified effects per minute but occupies 0.5% of the cluster, and Agent B produces zero verified effects (idle sessions) while occupying 2%, the optimization is clear: reduce B's pod allocation or sunset it entirely.

The deeper point: an effect-based scheduler can measure the real cost — compute plus overhead — per outcome rather than the proxy metric (compute used, regardless of how much work each agent did). Outcomes are what clients bill; compute units are what you provision. Conflating the two produces bad capacity plans.