Multi-Agent Topologies: Choosing Between Supervisor, Pipeline, and Broadcast

Most engineers building multi-agent systems reach for "just add another agent" before they've thought about what topology they're building. That's usually how you end up with a system that works once, fails mysteriously the next time, and takes a day to debug because nobody can trace where the decision went wrong.

Topology is not an implementation detail. It's a structural decision that shapes how state flows, how errors surface, and whether the system is testable at all. You should draw it before you write code, not discover it after the fact.

There are three patterns that cover the vast majority of real production systems. None of them is exotic. But confusing them -- or blending them without intention -- is where multi-agent projects go sideways.

The Supervisor Pattern

One agent coordinates, the rest execute. The supervisor receives the user's goal, breaks it down, routes subtasks to specialist agents, and assembles the results. No specialist talks directly to another. All communication goes through the supervisor.

This is the most common pattern in production right now, and the reason is straightforward: it's traceable. When something goes wrong, there's one place to look. The supervisor's reasoning is a log of every routing decision in the system. You can replay it, inspect it, and understand why agent B got asked to do X instead of Y.

The thing that kills supervisor systems is when the supervisor starts doing real work. I've reviewed codebases where the orchestrating agent was simultaneously writing code, running searches, and evaluating outputs while also deciding what to delegate. At that point there's no supervisor, just a confused monolith with extra latency and a routing layer stapled on. The supervisor's only job is deciding what happens next. The moment it starts doing the work itself, you've lost the traceability that made the pattern worth using.

A well-built supervisor also handles failure explicitly. Each specialist call can fail, timeout, or return garbage. The supervisor decides what to do with that: retry, reroute, escalate to the user, or abandon the task. Specialists shouldn't know about each other. They shouldn't need to.

The Pipeline Pattern

Each agent in the chain does something narrow, then passes its output to the next agent. Research → Draft → Edit → Format is a pipeline. So is Ingest → Classify → Summarise → Publish. Each step transforms the artifact; each boundary is a clean interface.

Pipelines are well-suited to content and document workflows because the transformations are directional and composable. You can test each stage independently. You can replace stage three without touching stages one, two, or four. That modularity is real.

The failure mode is context loss at each handoff. Agent B only knows what Agent A included in its output. If there was a critical constraint established at the start -- "keep it under 500 words", "don't mention competitor names", "this is for a European audience" -- and it didn't make it into Agent A's output packet, Agent B won't know about it. The downstream article gets written, the email gets drafted, the summary gets published, all without that constraint. Silently. Nothing errors.

The fix is deliberate handoff contracts. Every agent's output should include both its work product and the context the next step will need. That means thinking upfront about what each stage requires. It's more design work than wiring agents together with raw text, but it's the only way to make pipelines reliable.

The Broadcast Pattern

One input goes out to multiple agents running in parallel. Their results come back and get merged. You use this when you want multiple perspectives on the same thing, or when you need to process a large set of items concurrently.

Parallel evaluation is a good use case: send the same research question to five agents with different framings, then merge their outputs into a richer answer. High-throughput processing is another: fan out across a thousand documents, each one processed independently, results collected at the end.

Broadcast gets designed badly at the aggregation step. Getting five agents to return results is the easy part. Reconciling five contradictory assessments into a coherent output is hard, and it's where I see teams reach for an LLM as a merge function with no real strategy behind it. Before you build the fan-out, have a concrete answer to: what happens when two agents disagree? What if three agree and two don't? Is there a confidence weighting? Is there a veto? The merge logic is not a detail to figure out later.

Patterns Compound

Real systems mix these. A supervisor delegates to sub-supervisors, each of which runs a pipeline. A pipeline stage fans out to a broadcast and then consolidates. The topology is rarely flat. That's fine, but each additional level of nesting multiplies the places where context can drop and failures can go undetected.

One constraint that helps more than any pattern taxonomy: every agent in a multi-agent system should have a single, nameable responsibility. If you can't write that name on a sticky note in three words, the agent is doing too much. "Research agent". "Draft agent". "Routing agent". When you can't write the name, that's usually a signal that the agent boundary was drawn for convenience, not because there's a real conceptual split.

The State Problem

The patterns above describe message flow. They say nothing about shared state, which is where multi-agent systems get complicated fast.

Agents frequently need to read from common context: the user's original request, constraints established upfront, the output of earlier steps. In a simple pipeline this is just passing data forward. In supervisor and broadcast systems you need something more structured.

The tempting solution is passing the full conversation history to every agent. It works at small scale. It doesn't work when you have twenty parallel agents and each one needs context that accumulated across previous turns. Token costs compound quickly. Contexts get polluted with irrelevant detail.

What I've seen work better is an explicit state object: a structured document that represents the current task state, versioned, with each agent getting only the fields it needs. The supervisor owns and updates the authoritative copy. Each agent call specifies what it needs from state and what it's allowed to write back. More engineering upfront, but dramatically easier to reason about and to debug when something goes wrong.

This also makes the system's memory legible. You can look at the state object at any point and know exactly where the task stands. With raw conversation history, you often can't.

Make It Explicit Before You Build

Topology decisions are hard to reverse. Converting a broadcast system into a supervisor pattern after the fact means rebuilding coordination logic from scratch. The shape of the system determines what's easy and what's painful to change later.

Draw the topology first. Put agent names in boxes, draw arrows showing who communicates with whom, label each arrow with what gets passed. Ask whether each agent has a genuinely different job or whether you've split one thing in three to feel like you're doing good architecture. The second outcome is more common than people admit, and the coordination cost is never worth it.

The engineers who build maintainable multi-agent systems are not the ones who know the most agents. They're the ones who use the fewest agents that can actually do the job, with boundaries sharp enough that any one of them can fail without bringing down the rest.

If you found this useful, I write about system design and senior engineering decisions every week in Monday BY Gazar. Subscribe to get it in your inbox.

You can also find me on LinkedIn where I share shorter takes on architecture and the engineering career.