I spent six months building a swarm for a task that was secretly a DAG.
Not six months of building and iterating. Six months of building, debugging, rewriting the coordination layer, adding tracing I never needed, and watching a system that should have been deterministic behave like weather. The task was document processing — extract, validate, enrich, summarize, format. Five stages. Genuinely sequential. And I built a peer-to-peer network of agents that negotiated their way through it because I'd just read a paper about emergent coordination and decided that was the future.
The rewrite took three weeks. The pipeline version was faster, cheaper, and — this is the part that still stings — more reliable than anything the swarm ever achieved. The swarm wasn't wrong as an architecture. It was wrong for the task.
That's the cost nobody warns you about. Not the framework. Not the model. The topology.
The Six-Month Tax
The research has now quantified what I learned the hard way, and the numbers are more brutal than my anecdote.
The controlled study from March 2026 tested four coordination architectures on identical software engineering tasks with a fixed $50 budget and the same LLM. A single agent succeeded on 28 of 28 tasks. Hierarchical coordination succeeded on 18 of 28. Self-organized swarm succeeded on 32%. And a gated pipeline — the topology closest to what my document task actually needed — never produced implementation code at all, consuming its entire budget on planning phases.
The hierarchy didn't fail because the model was weak. It failed because coordination complexity introduces information loss that compounds at every handoff. The study measured it precisely: the single agent retained 85.8% of the original specification entropy at verification. The hierarchy retained 25.8%. Three-quarters of the signal was gone before any work got verified.
The MAST taxonomy, built from 1,642 annotated execution traces across seven frameworks, found that inter-agent misalignment accounts for 36.9% of multi-agent failures — coordination breakdowns, state synchronization errors, conflicting objectives. The plurality of documented failures isn't reasoning. It's orchestration.
And the finding that should be on every architecture slide: a matched-budget study from April 2026 found that single agents matched or outperformed multi-agent systems when reasoning tokens were held constant. Multi-agent only becomes competitive when a single agent stops using its context window well, or when more compute is spent.
I had been choosing topologies based on what was interesting to build. The research says the topology is a task-matching problem, not a preference.
The Three Topologies, Honestly Described
The 2026 orchestration survey places multi-agent architectures on a 3×2 grid: topology (centralized, decentralized, hierarchical) crossed with adaptivity (static versus dynamic-adaptive). For the purposes of matching to task, three shapes matter most.
Pipeline. A linear chain. Each stage consumes the previous stage's output. Deterministic, debuggable, cheap. Microsoft's sequential orchestration guidance describes it exactly this way — a predefined linear order where each agent processes the previous agent's output, creating a pipeline of specialized transformations. The latency cost is the sum of all stages. The benefit is that you can reason about it with a whiteboard.
Graph. A directed acyclic structure with branches, conditional edges, and explicit merge points. The control flow is known at design time, but it isn't linear. LangGraph's StateGraph is the canonical implementation: nodes are agents, edges define transitions, conditional edges are pure functions rather than LLM calls deciding where to go next. You get determinism in the control flow and flexibility in the shape.
Swarm. Peer-to-peer handoffs with no central controller. Each agent decides for itself whether to answer or delegate. OpenAI's Swarm library, LangGraph's swarm library, and AWS Bedrock AgentCore all implement some version. The topology emerges at runtime rather than being declared. The benefit is resilience and adaptability. The cost is debuggability — the bug lives in the space between agents, and no single agent's logs will show it.
There's a fourth axis that cuts across all three: hierarchy. Supervisor-over-workers, or supervisor-over-supervisors. It's not a topology so much as a layering strategy — you can run a pipeline inside each leaf of a hierarchy, or a swarm inside each department. The question of how many layers is separate from what shape each layer is.
The Decision Framework
Here's the framework I use now. It's five questions, asked in order. The first one that resolves determines the topology, and the rest are constraints on the implementation.
Question 1: Is the dependency graph known at design time?
If yes — you know which stage feeds which, and the structure doesn't change per task — you're choosing between pipeline and graph. If no — the topology of the work emerges from what the agents discover — you're looking at swarm.
This is the question I got wrong. My document task had a fully known dependency graph. I built a swarm anyway.
Question 2: Are there genuine serial dependencies, or just data handoffs?
This is the question that separates pipeline from graph, and it's the one that pays for itself immediately.
A serial dependency means stage B genuinely cannot begin until stage A completes. A data handoff means stage B needs one field from stage A's output, and could otherwise start immediately. I spent weeks treating the second as the first.
In my rebuilt pipeline, three of five stages had no genuine serial dependency. Extraction and enrichment could run concurrently on different document sections. Validation and summarization could run in parallel once extraction completed. Only formatting genuinely needed everything upstream.
The tell: if you can't articulate why B waits for A beyond "it needs the output," it's a data handoff, and it's parallelizable. Real dependencies are rarer than code order suggests.
Question 3: Do agents need to negotiate, or do they report?
Reporting is a pipeline or graph. Negotiation is a swarm.
Negotiation means the receiving agent has its own goals, its own authority, and the ability to refuse, ask clarifying questions, or propose a different approach. Reporting means the receiving agent executes what it was given.
I had been building negotiation where reporting was needed. My extraction agent didn't need to discuss the document with the validation agent. It needed to hand over a structured artifact and let validation check it. The negotiation overhead was pure cost.
The one exception: if the task genuinely requires surfacing multiple perspectives before a decision — policy review, risk assessment, design critique — negotiation earns its keep. But that's a specific task profile, not a default.
Question 4: How many agents, and how much do you need to debug?
The survey literature is consistent here. Centralized topologies offer high debugging ease at the cost of limited scalability — typically 3 to 7 agents. Decentralized topologies offer high scalability and fault tolerance at the cost of low debugging ease.
This is a real trade, not a hypothetical. I've spent four days chasing a race condition in a decentralized system that would have been a two-line fix in a pipeline. I've also watched a centralized orchestrator take down a forty-minute run when it restarted. Both costs are real. The question is which one your team can absorb.
Question 5: Is latency the binding constraint?
If latency matters and your stages are independent, you need concurrency — which means graph with parallel edges or fan-out, not pipeline. If latency doesn't matter and cost does, pipeline is cheaper because it doesn't carry branch state or merge overhead.
The arithmetic from a production rebuild: a sequential pipeline at 45 seconds, restructured as fan-out with a synthesis merge, came in at 14 seconds — a 3.2× reduction. The stages were never dependent. The chain was a habit.
The Research on Task-Adaptive Topology
The AdaptOrch paper from February 2026 makes the case I wish I'd read eighteen months ago: as models converge toward comparable benchmark performance, orchestration topology — the structural composition of how agents are coordinated — now dominates system-level performance over individual model capability.
Their framework dynamically selects among four canonical topologies — parallel, sequential, hierarchical, and hybrid — based on task dependency graphs and empirically derived domain characteristics. The result: 12–23% improvement over static single-topology baselines, even when using identical underlying models.
The same model, the same prompts, the same tools. The only thing that changed was whether the topology matched the task.
This is the finding that should end the "which pattern is best" debate. There is no best pattern. There is only the pattern that fits, and the cost of using one that doesn't.
What Production Teams Are Running
Microsoft's Azure SRE Agent started with 100+ specialized tools and 50+ agents, and it failed in production — coordination failures, infinite loops, poor generalization. They pivoted to five wide tools, a handful of generalist agents, and aggressive context management. The topology changed from a sprawling swarm toward something closer to a graph with a small number of nodes. Reliability improved dramatically.
iFood's Rosie support agent uses parallel workflows where the tasks are genuinely independent and sequential routing where they aren't, reducing average resolution time from 38 minutes to 10. The topology isn't uniform. It's matched per workflow.
SAP's evaluation across 208 production scenarios at Persona, Department, and Enterprise scale found that scale, not task complexity, dominates orchestration performance. Both sequential and reactive architectures degraded at enterprise scale as agent discovery noise became the primary bottleneck. Their Task Manager reduced high-priority queue latency by 14–75%.
ClockChain's deterministic behavioral ledger takes the opposite approach from swarm — it makes coordination explicit and auditable, designed for regulated domains where the topology must be provable rather than emergent.
The pattern across all of these: the teams shipping successfully aren't picking a topology and defending it. They're matching topology to task and accepting that different workflows in the same system may need different shapes.
What I'd Tell My Past Self
The six months I spent on the wrong topology weren't wasted in the sense that I learned what didn't work. But they were expensive in a way I could have avoided by asking five questions before writing a line of code.
Start with the dependency graph, not the architecture. Draw the actual graph of what depends on what. Not the pipeline you imagined — the real dependency structure. Most of the sequence will disappear.
Ask whether agents report or negotiate. If they report, you don't need peer-to-peer. If they negotiate, you need something that can handle state, refusal, and clarification. Those are different systems.
Match the topology to the task, not to the paper you just read. Emergent coordination is fascinating. It's also the wrong choice for a five-stage document pipeline with a known order.
Accept that the topology may change as the task does. The pipeline that works for your current workload may need to become a graph when you add parallel branches, or a hierarchy when you add a second team. Design for evolution, not for a permanent answer.
And the one I keep coming back to: the coordination tax is real, and it's paid in tokens, latency, and debugging time. Every topology that adds a handoff adds a place for signal to die. The cheapest coordination is the one you don't need.
The Trade-Off You're Accepting
Every topology is a trade, and the honest ones are worth naming.
Pipeline buys you determinism and cheap debugging. It costs you latency and the ability to handle tasks whose structure isn't linear.
Graph buys you parallel execution with deterministic control flow. It costs you more upfront design — you're writing the topology instead of hoping the model figures it out.
Swarm buys you resilience and adaptability to unknown task structure. It costs you observability, and it costs you the ability to answer "why did the workflow go that way?" without reconstructing intent from six agents' worth of logs that were never designed to be read together.
None of these are wrong. All of them are wrong for some task.
So here's my question: If you drew the actual dependency graph for your current agent system — not the one you designed, the one the code actually implements — how much of your topology would survive?
I'd love to hear where you've landed. A pipeline you defended, a swarm you migrated away from, a graph you wish you'd built first — and what finally made you look at the shape instead of the agents?
Top comments (1)
The specification entropy drop you cited, falling from 85.8% down to 25.8% across hierarchical handoffs, captures the thermodynamic reality of multi-agent negotiation. In a typed DAG, each step either satisfies a schema constraint or emits an explicit exit code, keeping the blast radius of a failure isolated to a single edge.
Once you replace hard edges with conversational negotiation, the cost structure shifts from execution to protocol synchronization. Every peer in a swarm must ingest the preceding dialogue tokens of every other participant just to establish consensus, meaning token burn and latency scale quadratically with the number of agents. By the time a peer-to-peer network agrees on who should parse an incoming payload, you have spent the bulk of your inference budget on conversational overhead before a single transformation runs. The cheapest orchestration layer is still an explicit type signature.