Multi-Agent Orchestration Patterns

One agent doing everything fills its window and mixes jobs. Multi-agent orchestration splits the work across specialists in parallel, then one supervisor merges results and breaks ties.

One supervisor splits five research topics across five workers at six minutes each, then merges in three minutes for a ten minute parallel run instead of thirty sequential.

Why Does This Exist?

One agent with many tools can do a lot until the job outgrows it. The window fills with five half-finished threads, tool calls queue instead of running together, and one prompt mixes researcher, coder, and critic voices until the answer sounds like all three and satisfies none. Adding a bigger window only delays the jam.

Multi-agent orchestration answers with specialization plus parallelism. A supervisor splits one goal into independent pieces, hands each to a worker that does one job well, runs them at once, then merges the pieces and settles conflicts. The wall clock drops from the sum of the parts to the slowest part plus the merge.

This page covers the split, the parallel run, and the merge. The boss-and-workers shape lives in supervisor subagent patterns. What moves between workers lives in agent communication protocols. The plan the supervisor starts from lives in planning in agents, and the long jobs this unlocks live in long-horizon planning.

Basics first: each worker still runs the same small loop: think, call one tool, read the result, repeat. If that cycle is new, read ReAct first. Everything below assumes workers that can already act alone.

Think of It Like This

A documentary crew, not one filmmaker with five cameras

One filmmaker can shoot a short alone. A feature needs a director, two researchers, a camera operator, and a fact-checker. The director does not hold five cameras. The director assigns streets, sets the deadline, then cuts the returned footage into one story.

The assignment is delegation. The simultaneous shooting is parallel execution. The cutting room is the merge, where two crews that filmed conflicting interviews get reconciled into one timeline. The credit roll lists who shot what, so a bad scene traces to its source.

Where it stops: a film crew shares one set and sees each other's work. Agents share only what the supervisor forwards, so two workers can confidently contradict each other for hours. And a director can shout across the set, while every agent message costs tokens and latency, which is why the merge must be ruthless about what travels upward.

How It Actually Works

Call the goal $G$ , which means the whole job. Call the pieces $g_1$ through $g_n$ : independent sub-tasks with no ordering between them. Call the supervisor the agent that splits $G$ , assigns the pieces, and merges the returns. Call each worker the agent that owns one $g_i$ .

The supervisor splits, workers run, the supervisor merges

The supervisor decomposes $G$ into $g_1$ through $g_n$ , assigns each with its inputs and its done rule, and launches workers together. Each worker runs its own loop with its own tools and returns a structured summary, not a raw dump. The supervisor collects the summaries, checks them against each other, and writes the final answer. When workers disagree, it votes, weights by reported confidence, asks a critic worker to reconcile, or escalates to a human on high stakes. The envelope those messages travel in lives in agent communication protocols.

Independent pieces set the clock

Sequential time is the sum. Parallel time is the slowest worker plus the merge. That gap is the entire economic case, and it only holds for independent pieces. Dependent steps stay sequential no matter how many workers you hire. The plan that marks which is which lives in planning in agents.

Worked example: five topics, ten minutes instead of thirty

Five research topics, each taking 6 minutes alone: 4 minutes searching plus 2 minutes reading. Sequential time is $5 \times 6 = 30$ minutes. Run five workers at once. Four finish in 6, one straggler takes 7. The supervisor merges in 3. Parallel time is $7 + 3 = 10$ minutes. The saving is $30 - 10 = 20$ minutes, and the diagram draws exactly this run.

Tokens tell the same story. Each worker returns an 800-token summary, so five workers send $5 \times 800 = 4000$ tokens. The supervisor adds 500 tokens of merge. The supervisor reads $4000 + 500 = 4500$ tokens inside an 8000 window, leaving $8000 - 4500 = 3500$ spare. Had each worker pasted raw pages, the same merge would burst the window. Summaries are what make the merge fit.

Use this shape when pieces are independent and each wants a different skill. Skip it for a three-step chain, where five workers add coordination without any parallelism to sell.

Code

The point here is the clock and the vote, not the research. This stdlib-only sketch recomputes the sequential bill, the parallel bill, and a three-way tie-break:

1planned: list[int] = [6, 6, 6, 6, 6]2print(sum(planned))  # -> 303print(7 + 3)  # -> 104print(30 - 10)  # -> 205print(5 * 800 + 500)  # -> 45006
7votes = ["A", "B", "A"]8print(max(set(votes), key=votes.count))  # -> A

Thirty sequential minutes against 10 parallel, 20 saved, a 4500-token merge, and a 2-to-1 vote for A. Count your own runs the same way before hiring more workers.

Watch Out For

A silent worker failure poisons the merge

The symptom is a polished final report with one invented section. A worker timed out, returned a partial guess with no status flag, and the supervisor merged it as fact. Nothing errored, so the mistake reads as success until a reader checks the source.

Fix it by requiring an explicit status on every worker return: done, partial, or failed, with the evidence attached. Retry failed pieces with backoff, skip with a note when the piece is optional, and never merge a return with no status.

The supervisor drowns in raw worker output

The symptom is a merge that starts sharp and ends vague. Five workers each pasted 6000 tokens of pages, the supervisor's window filled, and the final answer summarizes the first worker loudly and the rest from memory. The run looks well-staffed and behaves single-sourced.

Fix it by capping what travels upward. Workers return structured summaries around 800 tokens with sources attached, and raw details escalate only on conflict. The step loop inside each worker lives in ReAct.

The Quick Version

Multi-agent orchestration splits one goal into independent pieces, runs specialists in parallel, and merges with a tie-break rule.
Five 6-minute topics cost 30 minutes sequential and 10 minutes parallel: a 7-minute straggler plus a 3-minute merge saves 20.
Five 800-token summaries plus a 500-token merge total 4500 tokens, fitting an 8000 window with 3500 spare.
Conflicts resolve by vote, confidence weight, a critic worker, or human escalation on high stakes.
Every worker return needs an explicit status, or silent partials become confident final answers.
Summaries travel upward by default, since raw dumps drown the supervisor.