When does a decentralized handoff swarm beat a central orchestrator for a workload?
answer
- governance, not performance
- no arbitration turn per hop
- no single point of truth about routing
- decide per edge, not per system
- first ask if one agent suffices
basics
~20 sSwarms win where one user-facing conversation moves through specialist domains in sequence and each specialist can judge the next owner locally. They lose where routing must be auditable, policy is centrally governed, or the flow needs results combined rather than control passed on.
solid answer
~50 sThe honest framing is that this is a governance choice, not a performance one. A handoff swarm folds the routing decision into a turn an agent was already taking, so it is cheaper and lower-latency than asking a router model each turn, and adding a specialist means adding one agent plus a transfer description rather than editing a central prompt everyone depends on. What you give up is a single place that knows the route. Routing policy is scattered across every peer's transfer descriptions, cycles become possible, and "why did this claim end up with the fraud desk?" has no one component to answer it. In a regulated flow — an insurance claims desk, say — that traceability may be worth the router's cost and bottleneck outright. And the null option is real: current practice keeps writes single-threaded and repeatedly finds single-agent designs matching multi-agent ones at equal token budget, so the first question is whether any topology beats one well-equipped agent.
go deeper
Know that a swarm lets agents transfer directly to each other while a central orchestrator decides each step, and that the swarm avoids the extra decision-making turn.
Explain the concrete trade-off: no arbitration call per hop and easy addition of peers, against scattered routing policy, cycle risk and no single log of routing decisions.
Argue from operational evidence — ping-pong rates, hop distributions, first-hop accuracy, the instrumentation a swarm requires before it is safe — and describe the hybrid where only the sensitive edges are centralized.
Own it as governance and economics: who can change routing policy, who must explain a routing decision later, what the token premium buys, and whether a single agent at equal budget already matches the multi-agent design you are proposing.
## Frame it as a governance choice Both topologies get the same conversation to the same specialist. The difference is who decides and who can later explain the decision. A central orchestrator concentrates the routing decision in one component: one prompt to change, one log to audit, one bottleneck, one model call per turn. A swarm distributes it: the holder of the conversation decides once, locally, at the moment it recognizes the request is not its own. That reframing is what separates a principal answer from a middle one. Latency and token numbers are real but small; the durable consequences are auditability, change management and blast radius. ## Where the swarm genuinely wins **One conversation, sequential specialists.** The shape the topology was designed for: a single user-facing thread that passes through domains in order. Support, intake, sales-to-fulfilment. The user experiences continuity; the system experiences a baton pass. **Local knowledge beats central knowledge.** A billing agent, having examined three invoices, knows better than any router whether this is now a retention matter. A central router would have to be told everything billing just learned in order to make the same call — which means either a fat routing prompt or a lossy summary. **Latency and cost pressure on a hot path.** No arbitration turn means no extra model call per hop. In an interactive conversation where the user is watching a cursor blink, that is worth something. **Independent team ownership.** Teams that own their agent can add a peer and a transfer description without a change to a shared router prompt that everyone else depends on. This is the organizational argument, and at scale it is often the deciding one. ## Where it loses **Auditability requirements.** If someone will ask "on what basis was this claim routed to fraud review, and can you show the policy that was in force?", a distributed set of tool descriptions is a poor answer. Centralized routing gives you one artifact to version, review and test. **Centrally governed policy.** When routing rules change frequently, or must change everywhere at once, N prompts is N places to get it wrong. Some teams keep the swarm but generate all transfer descriptions from a single routing spec — a reasonable middle, and worth naming. **The work is not a handoff at all.** If several specialists must contribute to *one* answer, control transfer is the wrong primitive: nothing returns, so nothing can be combined. That is a different topology's job. **Cycle risk on ambiguous domains.** Where scope boundaries genuinely overlap, peers will trade the conversation and you will spend design effort on hop budgets and loop detection that a router would have made unnecessary. **Thin observability budget.** A swarm demands structured transfer events, per-conversation hop accounting and route dashboards before it is safe. A team that will not build that instrumentation is better served by the topology with one chokepoint to log. ## The economics and the null option Orchestrated multi-agent work carries a large token premium over plain chat — the research-style pattern runs on the order of fifteen times chat's token usage — and 2026 results repeatedly show single-agent systems matching or beating multi-agent ones at equal token budget. The convergent rule in current practice is that the acting, writing path stays single-threaded and extra agents contribute intelligence rather than concurrent actions. A swarm respects that rule by construction, since exactly one agent holds the conversation, which is part of why it survived while parallel-writer designs did not. So the first move in any topology question is to ask whether one agent with all the tools would do. If tool-selection accuracy is holding up and the prompt has not become unmanageable, it usually will, and it will be cheaper and far easier to debug. ## A worked judgment An insurance claims desk. Intake, coverage verification, fraud review, payout. Sequential, conversational, specialist-heavy — the swarm shape fits. But fraud routing is a regulated decision that must be explainable years later, and coverage rules change monthly under central compliance control. A defensible design is hybrid, and saying so is stronger than picking a side. Swarm handoffs on the low-stakes path (intake to coverage to payout), where locality and latency pay. A centralized, versioned rule for the fraud-review edge, so that decision has one owner, one artifact and one audit trail. A hop budget with human escalation for anything that cycles. That answers the question the interviewer is really asking: can you decide per-edge rather than per-system? ## What a weak answer sounds like "Swarms are more scalable and avoid the single point of failure." Both claims are shallow here — the router is rarely the throughput limit, and a swarm has no single point of failure but also no single point of truth. The strong answer names auditability, change management, cycle risk and the null option, and it ends with a measurement that would change your mind.
- Can you mix the two topologies, and what does the seam look like?Yes, and hybrids are common. Keep peer handoffs on the cheap, ambiguous-but-low-stakes edges, and put a centralized, versioned decision on the edges that must be auditable or that change under central policy. A supervisor can also be invoked as a one-off tiebreaker only when the hop budget trips, so you pay for arbitration in the rare case rather than every turn.
- What measurement would make you migrate a swarm edge to centralized routing?A sustained ping-pong rate between the same pair, or hop counts whose tail keeps growing, both of which say the peers cannot judge ownership locally. A compliance request you cannot answer from transfer logs is the other trigger, and it is decisive on its own regardless of what the operational numbers say.
- How do you argue against building any multi-agent topology here?Point at the economics: orchestrated multi-agent runs cost multiples of a single agent's tokens, and equal-budget comparisons often show a single well-equipped agent matching them. Propose one agent with the full tool set first, measure tool-selection accuracy and instruction adherence as the tool count and prompt grow, and split only when a measured ceiling appears rather than on aesthetics.
- Does a swarm remove the orchestrator's single point of failure in any meaningful sense?Not in a way that usually matters. The router is rarely the throughput or availability constraint, since the same model provider backs every agent anyway. What a swarm actually removes is the single point of *truth* about routing, which is a cost, not a benefit. Reliability arguments for swarms are generally weaker than the locality and organizational-ownership ones.
A relay race versus a dispatcher. Runners hand the baton directly and lose no time to a middleman, but nobody can tell you afterwards why the baton went to that runner; the dispatcher costs a radio call each leg and can account for every decision.
saying these in an interview costs you the question
- Argues swarms are better because they remove a single point of failure
- Ignores that routing policy becomes scattered across every agent's prompt
- Never considers whether one well-equipped agent would suffice
- Treats the choice as a performance question rather than a governance one
- Picks one topology for the whole system instead of deciding per edge