Orchestrator-Worker Patterns for Agents That Hold Up

Of all the multi-agent shapes people try, one keeps working: a lead agent that decomposes a task, spawns workers to handle the pieces, and synthesises what comes back. Anthropic described its research system in exactly these terms, with a lead planning and spawning three to five subagents in parallel.

It works because it does not ask the workers to agree with each other. They read, they return, and one agent decides. Everything hard about multi-agent systems lives in the boundaries, and this shape has the fewest boundaries that matter.

That does not make it cheap or automatic. The orchestrator is where most implementations go wrong, and it goes wrong in ways that look like model failure but are design failure.

What the orchestrator is actually for

The orchestrator does three jobs, and it is worth naming them separately because teams usually do one well and two badly.

It decomposes: turning a goal into subtasks that do not overlap and do not depend on each other. It briefs: writing each worker a specification complete enough to execute without guessing. It synthesises: folding returned results into an answer, including deciding what to do when two workers disagree.

Decomposition gets the attention. Synthesis is where quality is won or lost, because an orchestrator that concatenates worker output has not synthesised anything — it has produced a longer document with the same gaps.

Keep the orchestrator out of the work itself. The moment the lead starts reading files directly, its context fills with the noise the workers existed to absorb, and by the time results return it has no room to think about them.

Briefs are the whole design

A worker knows only what its brief says. Everything else it invents, and it invents differently from its siblings.

Over-specify. Include the decisions already made, the naming conventions, the directories in scope, what has already been ruled out. Cognition's Flappy Bird example is the canonical failure: split the task, and one worker produces Super Mario Bros scenery because nothing in its brief said otherwise. Neither worker disobeyed. The briefs were lossy.

Specify the return shape too. Fixed fields — what was found, where, confidence, open questions — turn synthesis into a mechanical merge instead of a second reasoning problem. The same argument applies here as in structured output generally: parsing prose is a tax you pay on every run.

And give every worker a budget. Maximum steps or maximum tool calls, so a confused worker fails fast rather than burning a thousand calls converging on nothing. This is the cheapest single guard in the whole design, and it is closely related to the ceilings discussed in agent token budgets.

Choosing how many workers

More workers is more coverage and more synthesis burden. The relationship is not linear: past a handful, the orchestrator starts skimming results rather than reading them, and coverage you paid for goes unused.

Scale the fan-out to the question, not to the available concurrency. A narrow factual question wants one worker. A comparison across four candidates wants four. A vague exploratory question wants the orchestrator to sharpen it first, because fanning out on a vague question produces four vague answers. There is more on where the ceiling sits in agent fan-out limits.

Resist recursive spawning. Workers that spawn workers produce trees nobody can debug, and each additional level compresses the original intent again. Two levels is the practical maximum.

Synthesis, done properly

Synthesis is a real reasoning task and deserves its own step with its own budget.

The orchestrator should reconcile rather than concatenate: note where two workers found the same thing, note where they conflict, and say which it believes and why. A conflict between workers is information — usually it means the question was ambiguous, or one worker looked at stale material.

It should also notice absence. If three workers were asked about error handling and none found retry logic, that is a finding. Models are poor at reporting negatives unless the return schema has a field for them, which is another reason to fix the schema.

Where the output matters, run a separate verification pass over the synthesis with a fresh context, checking claims against the worker results that supposedly support them. Fresh context is the point — the synthesiser has already been persuaded by its own reasoning.

Cost, honestly

This design is expensive. Anthropic reported its multi-agent research system used roughly fifteen times the tokens of a chat interaction, against about four times for a single agent, and that token spend alone explained around eighty percent of the performance variance in its evaluations.

That last figure should change how you decide. A large part of why orchestrator-worker wins is that it spends more compute. Before building one, try a single agent with a bigger step budget and better tools; if that closes the gap, you have saved yourself an architecture.

When you do build one, the levers are the usual ones: a cheaper model for mechanical workers and a strong one for the lead, caching on the stable parts of the brief, and hard budgets everywhere. Agent cost control patterns covers the mechanics in more detail.

Where it does not fit

Do not use it for implementation split across workers. Writes to shared state need a single thread, and workers editing the same repository make choices that must agree with no channel in which to agree.

Do not use it when subtasks are sequentially dependent. If worker two needs worker one's answer, you have a pipeline, not a fan-out, and you should build it as one.

Do not use it for cheap tasks. The coordination overhead is fixed, so it eats a routine request whole while barely registering against a high-value one.

A build order

Start with one agent and find the actual bottleneck. If the bottleneck is breadth of reading, split reads into workers and keep every write in the lead. Fix the return schema before you increase the fan-out. Give each worker a step budget on day one. Log every brief and every result verbatim, because when a run goes wrong the question is which brief was ambiguous, and the briefs are the only evidence you will have.