Multi-Agent Orchestration Patterns

One agent, many hats vs. many agents, one hat each

A single LLM agent with a broad prompt and a large toolset can, in principle, do anything: research, write code, review its own work, format the output. In practice, pushing one agent to do all of that in one context window tends to produce worse results than splitting the work — the prompt becomes a tangle of competing instructions, and the model has to juggle unrelated concerns (style guidelines and API error handling, say) at the same time.

Multi-agent orchestration splits a task across multiple agents, each with a narrower role, a focused prompt, and often a smaller toolset. A coordinating layer manages how they communicate and in what order they act. This isn't a different model — it's an architecture for structuring work across multiple calls to the same kind of model.

The supervisor/worker pattern

The most common multi-agent pattern is supervisor/worker (also called orchestrator/sub-agent): one agent acts as a manager, breaking the user's request into sub-tasks and delegating each to a specialized worker agent, then assembling the workers' outputs into a final answer.

For example, a research assistant might have:

- A supervisor that interprets the user's question and decides which sub-tasks are needed.
- A search worker that only does web research and returns findings.
- A code worker that only writes and runs analysis code.
- A writing worker that only takes gathered findings and produces prose.

The supervisor never does the actual research or writing itself — it routes and synthesizes. This mirrors how a human team lead delegates to specialists rather than doing every task personally.

The debate / critique pattern

A different pattern uses multiple agents not for division of labor but for adversarial or critical review. In a debate pattern, two or more agents independently produce answers (or arguments for different positions), then critique each other's reasoning, and a final judge agent (or one of the debaters) synthesizes a conclusion.

A simpler variant used widely in production is generator/critic: one agent produces a draft (code, an answer, a plan), and a second agent — often with a different, adversarially-framed prompt — reviews it for errors before it's returned to the user or passed to the next step. This catches a meaningful fraction of mistakes that a single generation pass misses, because critique is a different cognitive task than generation and benefits from a prompt built specifically for finding flaws rather than producing output.

When multi-agent is worth the overhead

Multi-agent systems cost more — more LLM calls, more orchestration code, more places for state to get out of sync between agents. They're worth it when:

- Tasks genuinely decompose into distinct skills (research vs. writing vs. coding) that benefit from separate prompts and tools.
- Context would otherwise overflow. A single agent handling a long research task accumulates so much context that a sub-agent pattern — where workers return only a distilled result rather than their full trace — keeps the supervisor's context manageable.
- You need independent verification. A critic agent catching the generator's mistakes is a cheap way to add a quality gate.
- Different sub-tasks need different tools or permissions. A worker that only reads data can be scoped more safely than a single agent with write access used for everything.

They're usually not worth it for tasks a single well-prompted agent with 2-3 tools can already handle reliably — the added orchestration surface is pure overhead at that point.

Supervisor/worker vs. debate/critique

What's next

Whether an agent operates alone or as part of a team, it needs somewhere to keep track of what it has learned and done across steps and sessions. The next lesson covers agent memory architectures — the difference between what an agent holds in its active context and what it persists for later.