The Orchestrator-Worker Pattern Explained

In the orchestrator-worker pattern, one lead agent (the orchestrator) receives the task, breaks it into subtasks, sends each subtask to a worker agent, and combines the results into a final answer. Workers do the focused work; the orchestrator keeps the overall picture. It is the most widely used multi-agent pattern because it maps naturally to how people delegate.

How it works

1. Receive. The orchestrator gets the user's goal.
2. Decompose. It decides which subtasks are needed. The list may be fixed or chosen by the model at run time.
3. Delegate. Each subtask goes to a worker with its own prompt, tools and fresh context.
4. Collect. Workers return results, usually short summaries or structured data.
5. Synthesize. The orchestrator merges the results, resolves conflicts, and writes the final output.

Why it works

The orchestrator's context stays small. It never sees the raw pages a worker read, only the worker's conclusions. Workers can run in parallel, and each can be tuned to its job. If a worker fails, the orchestrator can retry that piece without restarting everything.

A concrete example

Say a user asks: "Compare three Python web frameworks for a small API." The orchestrator creates three subtasks, one per framework. Each worker researches one framework against the same checklist (speed, learning curve, ecosystem). The orchestrator receives three short reports and writes the comparison table. No worker needs to know about the other two.

Orchestrator design choices

Who decomposes: code or model?

If subtasks are known in advance, such as "check each file in this list", your own code can decompose and the orchestrator is just a loop. If the subtasks depend on the question, let a model plan them. Prefer code when you can; it is cheaper and predictable.

What do workers return?

Return the minimum the orchestrator needs. A 2,000-word report from each of ten workers will overflow the orchestrator's context and bury the signal. Ask for a summary, key facts and source references.

Is the orchestrator also an agent loop?

It can be. In the "agents as tools" variant, the orchestrator is a normal tool-using agent, and each worker is exposed to it as a tool. The model then decides when and how often to call workers. This is flexible but less predictable.

Pseudocode

def orchestrate(goal: str) -> str:
    subtasks = plan(goal)                       # list of strings
    results = [run_worker(t) for t in subtasks]  # could run in parallel
    return synthesize(goal, subtasks, results)

These three lines are the entire pattern. Everything else in this course is about making each line robust: better planning, parallel execution, validation of results, and safe synthesis. The next post turns this skeleton into working code.

Where it breaks

• Bad decomposition. If the plan misses a subtask, no worker covers it. The final answer looks complete but is not.
• Lossy summaries. Workers drop details the orchestrator needed. Tell workers what the result will be used for.
• Orchestrator bottleneck. Everything flows through one agent. For huge fan-outs, use a hierarchy (covered later).
• Overlapping workers. Two workers researching the same thing waste money. Give subtasks clear, non-overlapping scope.

When to choose it

Pick orchestrator-worker when a task splits into parts that can be done mostly independently, and when the final answer needs a single voice or a merged view. For a strictly sequential process, a pipeline is simpler. For routing different requests to different specialists, see the routing pattern.

Orchestrator responsibilities in detail

It helps to list exactly what the orchestrator owns, because beginners often leave these jobs to nobody. The orchestrator owns the plan and the definition of "done". It owns the budget, so it should stop spawning workers when limits are reached. It owns error handling: when a worker fails or returns nonsense, the orchestrator decides whether to retry, skip or report the gap. It owns the final quality: workers return partial results, and only the orchestrator sees whether the pieces fit together.

Workers, in contrast, own only their subtask. They should not call other workers, change the plan or ask the user questions. Keeping this boundary firm makes the system easier to reason about: control flows down, results flow up.

Anthropic-style research systems

The pattern is widely used for research assistants. A lead agent analyses the question, spawns several research subagents in parallel, each exploring one angle with search tools, and then a final step merges the findings and adds citations. The reason it pays off there is exactly the reason given earlier: the material read by the subagents is far larger than what the lead agent could hold, so each subagent compresses its findings before reporting back.