Multi-agent patterns: five ways to combine models
Multi-agent patterns: chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer. When each helps, what it costs and when one call is enough.
What is a multi-agent pattern?
A pattern is a design template. It describes how the pieces connect: which call goes first, which one decides the route, which ones run at the same time and who reviews. As in interface design, a pattern does not say what to draw; it says how the parts are organized.
Anthropic distinguishes two families in its guide Building effective agents (December 2024):
- Workflows: systems where LLMs and tools are orchestrated through predefined code paths.
- Agents: systems where the LLM dynamically directs its own process and tool usage, and keeps control over how it accomplishes the task.
The five patterns below are workflows. A caution about the name: not all of them need several agents. A chain can be the same model called three times. That is why this page uses “multi-agent” in a broad sense: any arrangement of several model calls.
What are the five patterns?
| Pattern | Idea in one line | Example Anthropic gives |
|---|---|---|
| Chaining | Each call processes the previous call’s output, with optional checks between steps | Writing marketing copy, then translating it |
| Routing | One call classifies the input and sends it to a specialized process | Support queries (general, refunds, technical) to different processes; easy questions to a small model and hard ones to a larger one |
| Parallelization | Several calls run at once and code combines the results | One model answers while another screens for inappropriate content; several code reviews looking for vulnerabilities |
| Orchestrator-workers | A central model splits the task, delegates subtasks and synthesizes | Complex changes across many files; searches that gather information from several sources |
| Evaluator-optimizer | One model generates, another evaluates and gives feedback, in a loop | Literary translation, where the evaluator critiques nuances |
Parallelization has two variants: sectioning, when the subtasks are independent, and voting, when the same task is run several times and the results are compared. The difference between parallelization and orchestrator-workers is who defines the subtasks: in the first they are fixed in advance; in the second, the central model decides them based on the input.
Other toolkits add one more mechanism. In OpenAI’s Agents SDK, a handoff lets one agent delegate a task to another, and it is presented to the model as a tool: an agent called Refund Agent is exposed as the tool transfer_to_refund_agent. It is used to pass control between specialist agents.
How do you choose?
Anthropic proposes looking for the simplest possible solution and adding complexity only when needed. Often that means not building an agentic system at all: one well-written call with retrieval and examples is enough. Workflows offer predictability for well-defined tasks. Agents suit open-ended problems where the number of steps cannot be predicted and a fixed path cannot be hardcoded, and they require trusting the model’s decisions.
For a designer, the practical question is this: can I draw the step diagram before running it? If yes, it is a workflow. If the steps depend on what the model finds along the way, it is an agent.
One warning from the same guide: frameworks make it easy to get started, but they add layers that hide the prompts and responses and make debugging harder. Anthropic suggests starting by using the model’s API directly.
When should you not use several agents?
In June 2025 Anthropic published how it built its research feature, which uses a lead agent that delegates to subagents searching in parallel. Its own numbers work as a counterweight:
- On its internal evaluation, the multi-agent system outperformed a single agent by 90.2%.
- In exchange, agents use about 4 times the tokens of a chat, and multi-agent systems about 15 times. That only makes sense for tasks whose value justifies the cost.
- It is a poor fit when all agents need the same context or when there are many dependencies between them. It also fits most coding tasks badly, since they have fewer truly parallel subtasks than research does.
Two lessons from that team apply to any design. First: vague instructions produce duplicated work, so each subagent needs an objective, an output format, guidance on tools and sources, and clear task boundaries. Second: scale effort to complexity. Early versions launched 50 subagents for simple queries; rules built into the prompt then set, for example, one agent with a few calls for a simple fact lookup and several subagents for comparisons or complex research.
Why does it matter to a designer?
Each pattern changes what the user sees. A chain shows progress in stages. A parallel run requires showing several things at once and resolving conflicts. An evaluator-optimizer can make the person see intermediate versions they did not ask for. If you do not design it, the system decides for you what is visible.
Each extra call is also a failure point. A four-step chain can fail at step three, and the user needs to know where, what was lost and how to retry. Anthropic lists transparency among its principles for agents: explicitly showing the planning steps. It also notes that agents can pause at checkpoints or when blocked to ask the person for information or judgment. Those moments are screens someone has to design.
Example
Illustrative example: a tool that drafts replies to customer reviews. A router classifies each review as a complaint, praise or a question. Complaints go to a generator that proposes a reply, and an evaluator checks it against three written criteria: tone, promises the company cannot keep, and sensitive data. If it fails, the draft goes back to the generator with the observation, up to a maximum number of attempts. The designer decides what the person sees: a ready reply with the reason for the classification, not the intermediate attempts. The designer also decides what happens when the attempts run out: the review goes to a person, with the draft and the evaluator’s note.
The blog article on AI pipelines describes three staged pipelines with human review, built with Claude. To understand the logic of each step, read the agent loop. If the steps are independent and you want to parallelize them, see how to parallelize work across agents. For the layer that coordinates everything, see agent orchestration.
Common mistakes
- Starting with five agents when one well-written call was enough.
- Using an agent for something that always follows the same steps. It is a workflow in disguise, and it is cheaper to write it as one.
- Not measuring the cost of each step. Without numbers you cannot tell which pattern performs.
- Using evaluator-optimizer without clear evaluation criteria. Anthropic recommends it when criteria are defined and iteration measurably improves the result.
- Delegating with vague instructions, which produces subagents that repeat the same work.
- Hiding failures. If an intermediate step fails, the user must be able to see it and retry.
Sources
- Building effective agents (Anthropic Engineering, December 2024): workflows vs. agents, the five patterns with their examples, the simplicity rule and the warning about frameworks.
- How we built our multi-agent research system (Anthropic Engineering, June 2025): orchestrator-worker architecture, the 90.2%, 4x and 15x figures, where it does not fit, and delegation lessons.
- Handoffs, OpenAI Agents SDK (documentation): definition of a handoff and its representation as a
transfer_to_<agent>tool.