Four multi-agent orchestration patterns we see in production

Single-agent systems hit a ceiling fast: one model, one context window, one set of tools trying to do everything well. Multi-agent systems split responsibility across specialized agents instead — but "multi-agent" isn't one pattern, it's a family of them, and picking the wrong one for a given workload is a common way teams end up with orchestration that's more complex than the problem it's solving. Here are the four patterns we see teams actually ship in production, and when each one is the right call.

1. Supervisor-worker

A router (or "supervisor") agent looks at an incoming request, decides which specialist agent — research, coding, billing support, whatever the domain calls for — is best suited to handle it, delegates the work, and synthesizes the specialist's output into a final response.

Use it when: requests naturally fall into a small number of distinct categories that benefit from different system prompts, tools, or even different underlying models. A general support inbox that needs to route between "billing question," "technical issue," and "general inquiry" is a textbook case — each category benefits from a narrower, more focused agent than one generalist trying to be good at all three.

Watch out for: routing accuracy. If the supervisor misclassifies a request, the wrong specialist handles it with the wrong context — so the supervisor's own reasoning quality (and the clarity of the categories it's choosing between) matters as much as the specialists' individual quality.

2. Sequential pipeline

Agents run in a fixed order, each one transforming the output of the one before it. There's no branching decision at runtime — the graph shape is the workflow.

Use it when: a task naturally decomposes into ordered stages — extract structured data from a document, then validate it against business rules, then generate a summary from the validated data. Document processing and multi-stage extraction pipelines are the common case: each stage has a single, well-defined job, and debugging a bad output means checking which stage introduced the problem, not untangling a single monolithic prompt trying to do everything at once.

Watch out for: error propagation. If an early stage produces a bad result, every later stage inherits that mistake — so validation between stages (or a condition_node gate that halts the pipeline on an unexpected result) matters more here than in patterns where a single agent handles a task end-to-end.

3. Debate

Two or more agents critique each other's output — proposing an answer, challenging it, revising it — before a final answer is produced, sometimes with a separate judge agent adjudicating.

Use it when: the cost of a wrong answer is high enough to justify the extra latency and token spend of multiple reasoning passes — legal or compliance review, high-stakes classification decisions, anything where "probably right" isn't good enough and a second independent pass catching an error is worth paying for.

Watch out for: cost and latency multiply with every additional agent in the debate, and debate doesn't guarantee correctness — it guarantees a second, independent look, which is valuable but not infallible. Reserve this pattern for the subset of your workload where that trade-off actually pays for itself.

4. Parallel fan-out

The same query (or variations of it) goes to multiple agents — or the same agent configured with different tools or knowledge bases — simultaneously, and results are merged into one answer.

Use it when: a task benefits from broad, independent coverage rather than a single line of reasoning — a research question that should be answered by checking several sources simultaneously rather than sequentially, or a task where different tool access (one agent with web search, one with an internal knowledge base) should contribute in parallel rather than in a fixed order.

Watch out for: the merge step. Fan-out is only as good as whatever reconciles the parallel results — a naive concatenation of everything every branch returned is rarely as useful as a dedicated synthesis step that resolves contradictions and dedupes overlap.

How this is actually built: a graph, not a script

All four patterns are, structurally, a directed graph of typed nodes — which is exactly how UnderOcean's flow builder represents them, and exactly how they execute underneath: a flow is authored visually with @xyflow/react on the frontend and compiles down to a LangGraph StateGraph on the backend. An agent_node runs a fully configured Agent (with its own memory, guardrails, and knowledge base) as one node in the graph; catch_up_node is the fan-in point after parallel branches complete, re-invoking a parent agent with all accumulated results — the exact mechanism a parallel fan-out pattern needs; condition_node evaluates a boolean expression against flow state in a sandboxed interpreter to decide which branch to take next, which is how a supervisor's routing decision or a pipeline's validation gate gets expressed structurally.

Building these patterns visually rather than as hand-written orchestration code has a specific payoff for multi-agent systems in particular: a debate pattern with three agents and a judge, or a supervisor with five specialist branches, has enough moving parts that seeing the whole graph on one canvas — instead of reconstructing it mentally from nested function calls — is the difference between a design you can review in a meeting and one only its original author fully understands.

Picking a pattern isn't all-or-nothing

These four patterns aren't mutually exclusive within a single system. A supervisor might route one category of request into a sequential pipeline and another into a parallel fan-out; a debate pattern's "judge" step might itself be a small sequential pipeline (extract claims, check each one, synthesize a verdict). The patterns are building blocks, not competing architectures — the question worth asking for any given workload is which shape the problem naturally has, not which pattern is most sophisticated.

FAQ

Do I need a different pattern for every kind of task my agents handle? No — many production systems combine patterns (a supervisor that fans work out into a sequential pipeline for one category, for instance) rather than picking exactly one pattern for the whole system.

Which pattern is fastest? Supervisor-worker and sequential pipelines typically have the lowest latency, since each request only goes through the agents it actually needs. Debate and parallel fan-out trade latency and cost for either higher confidence or broader coverage.

Can these patterns share tools and knowledge bases? Yes — any agent in any pattern can be configured with the same knowledge base, MCP tool connections, or provider configs as any other; the pattern determines how agents are wired together, not what each one can access.

Do I have to choose a pattern before building, or can a flow evolve into a different one? A flow can evolve — adding a catch_up_node to turn a simple sequential chain into a parallel fan-out, or inserting a condition_node to add supervisor-style routing to what was previously a single fixed path, are both incremental edits to an existing graph, not a rebuild from scratch.