Handoffs, Supervisors, and Swarms, Topologies That Survive Users
Pull-quote: “Users do not follow your workflow diagram. They interrupt, change their minds, and ask the billing question in the middle of the refund. The topology that survives is the one that expected that.”
The demo lies about the user
Every orchestration topology looks clean in a demo, because a demo asks the question the diagram was drawn for. Real users interrupt mid-task, revise the goal after step three, and bundle two departments into one sentence. The choice between handoffs, supervisors, and swarms is really a choice about where coordination state lives when that happens, and how much of the transcript survives contact with a human who did not read the script.
Three topologies, three failure signatures
HANDOFF CHAIN SUPERVISOR STAR SWARM / MESH
───────────── ─────────────── ────────────
A ──► B ──► C S A ◄──► B
baton, one owner ┌─┼─┐ ▲ \ / ▲
at a time ▼ ▼ ▼ │ \/ │
A B C ▼ /\ ▼
breaks: context workers report up C ◄──► D
dropped at the breaks: bottleneck, breaks: no owner,
seam between supervisor context circular waits,
two agents bloat emergent loops| Topology | Coordination state lives | Typical break | Debuggability |
|---|---|---|---|
| Handoff chain | The baton: what A passes B | Context dropped at the seam | High: one owner at a time |
| Supervisor star | The supervisor’s plan | Supervisor bloat, worker retry storms | Medium: one place to look, one place to flood |
| Swarm / mesh | Everywhere and nowhere | Circular waits, emergent loops | Low: causality reconstructed from traces |
Handoffs fail at the seams. The receiving agent gets a summary of a summary, and the constraint the user stated in turn two is gone by the third baton pass. Supervisors fail at the center: the coordinator accumulates every worker’s partial output until its own reasoning degrades, which is how you get a fleet run by the most confused participant in it. Swarms fail structurally. When no one owns the outcome, two agents can each politely wait for the other, or amplify each other’s errors in a loop that no single trace explains.
Rules that hold across all three
- Hand off state, not transcripts. A handoff is a typed contract: goal, constraints, evidence so far, and what done means. If the baton is a chat log, the seam is already leaking.
- Keep the supervisor thin. It routes, budgets, and aggregates. The moment it starts doing the workers’ jobs, you have one overloaded agent with extra steps.
- Every task has exactly one owner at any moment. Ownership can transfer; it cannot be shared or vacant. Most swarm pathologies are ownership pathologies.
- The user talks to one voice. Internal topology is not the user’s problem. Interruptions land at a single front, which decides what they mean for the work in flight.
- Emit the topology into the trace. Who delegated to whom, with what budget, and what came back. An orchestration you cannot replay is one you cannot fix.
Where this lands in production
Screening workloads suit the supervisor star: a thin coordinator fans records out to parallel screening agents and aggregates their independent judgments deterministically. The supervisor never screens anything itself, which is precisely why it stays reliable at the center. A customer-facing assistant sits at the other extreme: a single front that owns every conversation and hands work back only through typed, narrow tools. Between those poles we have yet to meet a production problem that demanded a true swarm more than it demanded an owner.
Closing
Pick the topology by asking where coordination state should live and who owns the outcome when a user interrupts. Chains for pipelines with clean seams, stars for parallel work that needs an accountable center, and swarms almost never, because the mesh that looks resilient on the whiteboard is usually just a diagram of unowned failure.