Orchestrator vs Swarm: Two Ways to Split Agent Work
Hub-and-spoke and peer-to-peer aren't rivals fighting for the same job — they solve different shapes of problem. Here's how to tell which one you have.
Ask five AI engineers to draw a multi-agent system and you'll get two shapes. The first is a tree: a lead agent at the top, subagents branching off it, arrows pointing down and results flowing back up. The second is a mesh: a cluster of nodes, roughly equal in size, lines connecting most of them to most of the others. Call the first one an orchestrator and the second a swarm.
The industry conversation in 2026 has mostly settled into treating the orchestrator pattern as the winner and the swarm as a cautionary tale — and for good reason, since the lead-agent pattern is now the default shape for production deployments. But "the orchestrator generally wins" and "the orchestrator is the only correct topology" are different claims, and conflating them leads teams to force orchestration onto problems that don't have a natural hierarchy, which produces its own kind of mess. The more useful exercise is figuring out which topology matches the actual shape of your task graph.
What an orchestrator topology assumes
A supervisor architecture assumes your task decomposes cleanly into subtasks that don't need to talk to each other mid-flight. The lead agent breaks "research this market" into "pull competitor pricing," "summarize recent news," and "check regulatory filings" — three subagents, each running multiple tools in parallel, each returning a self-contained result the lead agent can synthesize. This is the pattern that cuts research time by up to 90% on complex queries, and it works precisely because the subtasks are independent. Nothing about the pricing research depends on what the news summary finds mid-task.
That independence is the load-bearing assumption. When it holds, orchestration is close to strictly better than a swarm: you get a clear owner, a clean audit trail, and parallelism without coordination overhead.
Where that assumption breaks
It breaks whenever the subtasks are entangled — when agent B's next move genuinely depends on what agent A is doing right now, not what it concluded five minutes ago. Real-time negotiation between a pricing agent and an inventory agent, where each is adjusting to the other's live state, doesn't decompose into "spawn both, wait, synthesize." Neither does a debugging session where multiple specialist agents need to converge on a shared hypothesis as evidence comes in, revising each other's working assumptions rather than reporting finished conclusions upward.
For that class of problem, a more peer-oriented, or at least a much more stateful, architecture earns its complexity. This is the territory where frameworks like LangGraph are cited as the leading approach specifically because they support stateful graphs, durable execution, and human-in-the-loop checkpoints — infrastructure a simple hub-and-spoke orchestrator doesn't need and a genuinely interdependent multi-agent system can't function without. LangGraph's model isn't "lead agent delegates to workers"; it's a graph of nodes with shared, persistent state that can pause, checkpoint, and resume — which is a better fit when the coordination problem is ongoing rather than a one-time task split.
The tell: does the arrow point up, or across?
There's a fast diagnostic. Draw the information flow your task actually requires. If every arrow eventually points back up to one decision-maker — subagent results converging on a single synthesis step — you have an orchestrator problem, even if it involves ten subagents and five tools each. If arrows point across, between agents that need each other's live state to proceed, you have a coordination problem, and bolting a lead agent on top will just add latency without solving the actual dependency.
Most tasks that look like they need a swarm actually need better task decomposition, not a flatter topology — the entanglement is often accidental, a result of not having broken the problem down cleanly, rather than something inherent to the domain. That's worth sitting with before reaching for graph-based coordination, because a true peer-to-peer or stateful-graph system costs real engineering complexity: checkpointing, conflict resolution, and a much larger space of possible execution orders to test and debug.
Cost asymmetry favors trying orchestration first
There's also a practical argument for defaulting to orchestration and only reaching for something more coordinated when it demonstrably fails: the failure mode of a bad orchestrator decomposition is usually visible fast. The lead agent synthesizes contradictory or incomplete subagent results, and you notice, because there's one place to look. The failure mode of a bad swarm or stateful-graph design is often invisible for much longer — the system produces a plausible-looking answer that's subtly wrong because two agents disagreed and nobody adjudicated it, an entire category we cover in Debugging a Multi-Agent System When Something Goes Wrong.
Reach for a stateful, coordinated architecture when your problem has genuine mid-task interdependence — not because a swarm sounds more sophisticated than a boss agent with workers.
A worked example: two topologies, same starting brief
Take "handle this customer's return request" as a task and watch it fork into two different systems depending on which topology you reach for. As an orchestrator problem, it decomposes cleanly: a lead agent spawns a subagent to check the order history, a subagent to check the return policy for that item category, and a subagent to check current inventory for a possible exchange — three independent lookups, none of which need to know what the others found until the lead agent synthesizes a decision. That's a clean three-to-five-subagent fan-out, done in well under the time a human agent would take, at the token cost the pattern is known for.
Now take a superficially similar task — "negotiate a partial refund with a customer who's pushing back on the standard policy" — and the orchestrator shape quietly breaks. The policy-check agent's relevant answer depends on what the customer just said in the live chat, which depends on what the pricing-flexibility agent is willing to offer, which depends on the policy check. There's no clean moment to fan out three independent lookups and synthesize once, because the "right" policy interpretation is itself a function of an ongoing exchange. Teams that try to force this into an orchestrator pattern end up with a lead agent re-spawning the same subagents repeatedly every conversational turn, which technically works but is really just a badly-implemented stateful graph wearing an orchestrator's clothing — worse in both directions, since it inherits the token overhead of fan-out without the state-tracking discipline that would make the repeated re-spawning coherent.
Signals you're in the wrong topology, before it costs you
A few concrete tells, short of drawing the full task graph, that a system has been forced into the wrong shape. If your "orchestrator" is calling the same subagents more than once per top-level task with only minor variation in the prompt, that's usually a sign the task actually has ongoing state that belongs in a graph, not repeated fan-out calls papering over the lack of one. If your "swarm" spends more of its token budget on agents messaging each other to agree on who does what than on agents doing the actual work, that's usually a sign the task was decomposable all along and the coordination overhead is pure waste that an orchestrator would have eliminated for free. Both symptoms are catchable early, in a first week of testing, if you're watching for them — which is considerably cheaper than discovering the topology mismatch after the system's already carrying production traffic.
Hybrid systems are the honest answer for most real products
In practice, the systems that hold up in production aren't purely one or the other. A lead agent orchestrates the top-level task, and one of its subagents might itself be a small stateful graph handling a genuinely interdependent sub-problem — say, a multi-turn negotiation between a pricing checker and an availability checker before reporting a single clean result back up to the orchestrator. The orchestrator/swarm framing is useful for choosing a default, not for describing the ceiling of what these systems should look like. Pick hierarchy first. Add coordination complexity only where the task graph proves you need it, and be able to point to the specific arrow that goes sideways instead of up.
Part of the "The Subagent Economy" series on aiskill.market.