What is the orchestrator-worker pattern in multi-agent systems?

The orchestrator-worker pattern is the most common way to coordinate multiple AI agents: a lead agent (the orchestrator) breaks a task into sub-tasks and assigns each one to its own sub-agent (a worker), which works independently with its own isolated context. Each sub-agent reports back only a condensed result — not its full working context — and the orchestrator combines those results into a final answer.

When should agents coordinate sequentially versus in parallel?

Sequential handoff is the right choice when each step genuinely depends on the previous step’s finished output — like an editor that can’t edit a draft that doesn’t exist yet. Parallel fan-out/fan-in is the right choice when sub-tasks are genuinely independent of each other — like researching three unrelated competitors, where none of the results depend on the others. Using parallel fan-out for dependent steps produces wrong or incomplete results, and using sequential handoff for independent steps wastes time nothing required.

← Back to the Introduction level

AI & ML — INTERMEDIATE

Multi-Agent Coordination Patterns: Orchestrator-Worker, Sequential, and Parallel

The Introduction level showed that splitting work across agents helps. This level is about exactly how that split gets coordinated — who assigns work to whom, what actually gets passed between agents, and when to run agents one after another versus all at once.

The Quick Answer

Most multi-agent systems use the orchestrator-worker pattern: a lead agent decomposes a task, assigns sub-tasks to independent sub-agents, and combines their results. Coordination between agents takes one of two shapes. Sequential handoffruns agents one after another, each one’s output becoming the next one’s input — the right choice when a step genuinely needs the previous step’s finished result. Parallel fan-out/fan-inhands several independent sub-tasks out at once and gathers their results back together — the right choice when sub-tasks don’t depend on each other at all.

The Orchestrator-Worker Pattern

One agent — the orchestrator — holds the overall task and decides how to break it apart. It assigns each piece to a sub-agent, which works entirely on its own: its own context window, its own tool calls, no visibility into what the other sub-agents are doing. When a sub-agent finishes, it doesn’t hand the orchestrator its raw working context — it hands back a short, condensed result. The orchestrator’s own context only ever holds the task, the assignments, and those condensed results, never the full detail behind them.

This is the exact shape Anthropic describes in its production research system — a lead agent (Claude Opus 4) decomposing a task and spawning sub-agents (Claude Sonnet 4), each isolated, each reporting back only a summary. It’s covered as a case study in the Introduction level and in more architectural depth in Context Engineering Advanced.

One Question Decides Everything: Does This Step Need the Last One?

Once the orchestrator has split a task into pieces, it has to decide how to run them. There are really only two options, and only one question decides which one applies: does this piece need the result of another piece before it can even start?

Think of it like cooking a meal with a friend. If you’re making a sandwich where you first have to toast the bread, then butter it, then add the filling — those three steps have to happen in that order. You can’t butter bread that hasn’t been toasted yet. That’s sequential: each step waits for the previous one to finish, because it literally needs that previous step’s result to do its own job.

Now imagine instead you and a friend are each making a separatesandwich for two different people. Your friend doesn’t need to wait for you to finish yours — you can both toast, butter, and fill your own sandwiches at the same time, because neither sandwich depends on the other. That’s parallel: everyone starts at once, works independently, and you only come back together at the end to serve both sandwiches together.

Multi-agent systems make the exact same choice. “Fan-out” is just the moment the orchestrator hands a piece of work out to each agent — like both of you grabbing your own bread at the start. “Fan-in” is the moment their results get gathered back together — like both sandwiches landing on the table at the end. The words sound technical, but they just mean “hand work out to several agents at once” and “collect their results back together.”

Try both shapes below on two different tasks, and watch for which one actually needs the step before it, and which one doesn’t:

Getting this choice wrong has a real, concrete cost either way. Force independent sandwiches through a sequential process — toast yours, then wait, then toast your friend’s — and you’ve wasted time nothing actually required. But try to parallelize the sequential sandwich — buttering the bread before it’s even toasted — and you get a broken result, because that step needed information (toasted bread) that didn’t exist yet.

What Actually Gets Passed Between Agents

A sub-agent’s full working context — every tool call it made, every intermediate thought, every source it read along the way — never crosses over to the orchestrator or to another sub-agent. Only the condensed result does: a summary, a specific answer, a short structured output. This is a deliberate design choice, not an accident of the architecture — it keeps every agent’s context window small and focused on exactly what it needs, instead of accumulating every other agent’s working detail as well.

Fun Fact

A single orchestrator can mix both coordination shapes in the same task. A common real pattern: fan a task out to several independent research sub-agents in parallel, then feed all of their condensed results — sequentially — into one final writer sub-agent that needs everything gathered before it can produce the finished answer.

Test Yourself

In the orchestrator-worker pattern, what does each sub-agent send back to the orchestrator?

Which task is a better fit for sequential handoff rather than parallel fan-out?

What would go wrong if independent, parallelizable sub-tasks were forced through sequential handoff instead?

Ready for real orchestrator-worker code, the failure modes that show up in production, and the real cost trade-off of running multiple agents instead of one? Continue to the Advanced level →