Multi-Agent System Patterns

When a single agent gets stuck on a big task, the answer is not always a longer prompt: sometimes it is splitting the work across several agents coordinated by a design pattern. A multi-agent system organises several specialised agents so they solve together a problem that is uphill for one alone. In this guide you will see when the leap is worth it, the three patterns that dominate practice (orchestrator-workers, hierarchical and network), how agents communicate through the handoff, and what all of this costs in tokens and failure modes. This is a guide to patterns, not to tools: if you want the comparison of specific frameworks, it is in LangGraph versus CrewAI and Autogen. The same explanation is available in Spanish.

Key takeaways

• A multi-agent system splits a task across several specialised AI agents; the coordination is imposed by a design pattern, not by the model.
• The orchestrator-workers pattern (a lead agent delegating to parallel subagents) improved the results of a single-agent system by 90.2% on Anthropic’s internal research evaluation.
• The hierarchical pattern nests orchestrators into teams of teams; the network pattern lets any agent hand control to any other through a handoff.
• The cost is real: an agent consumes about 4 times more tokens than a normal chat, and a multi-agent system about 15 times more; token spend alone explains 80% of the variance in performance.
• Always start with one agent. Make the leap to several only for heavy parallelisation, information that does not fit in one context window, or many complex tools.

When is more than one agent worth it?

The practical rule is to start simple: a single agent with good tools solves more than it seems. Adding agents multiplies cost and the ways things break, so the leap must be justified. There are three clear signs that a single agent falls short.

The first is heavy parallelisation: the task decomposes into independent subtasks that can advance at once, such as researching five different sources or analysing twenty files. The second is information that does not fit in one context window: if the work requires reading more than fits in the model’s context, splitting the reading across subagents that each summarise their part avoids the overflow. The third is too many tools: an agent with forty tools gets distracted choosing; several agents with a bounded catalogue each hit the mark more often.

Anthropic sums it up in its engineering of the multi-agent research system: these systems "excel at valuable tasks that involve heavy parallelization, information that exceeds single context windows, and interfacing with numerous complex tools." If your task fits none of those three moulds, the single agent almost always wins: it is cheaper, easier to debug and more predictable. The decision to split the work rests on the same discipline of planning and task decomposition an agent uses internally, only now each subtask is carried by a separate agent.

What is the orchestrator-workers pattern?

It is the most common multi-agent pattern and the easiest to reason about. An orchestrator agent (or lead) receives the task, divides it into subtasks and launches several worker agents that solve each piece in parallel; the orchestrator then collects the results and synthesises them into a final answer. The orchestrator does not do the heavy lifting: it plans, delegates and joins.

Anthropic built its research feature with this exact pattern, using Claude Opus 4 as the lead agent and several Claude Sonnet 4 as subagents. The result was decisive: the multi-agent version outperformed a single-agent system based on Opus 4 by 90.2% on its internal research evaluation. The key is that each subagent explores one direction with its own context window, and the lead sees only the summaries, not the noise.

In pseudo-code, the shape of the pattern is always the same, regardless of the framework:

# Orchestrator-workers (framework-agnostic pseudo-code)
def orchestrator(task):
    subtasks = lead.plan(task)                  # split the problem
    results = run_in_parallel(                   # launch subagents at once
        [worker(sub) for sub in subtasks]
    )
    return lead.synthesise(results)              # join the findings

def worker(subtask):
    return specialised_agent.solve(subtask)      # its own context

The difference from plain task decomposition inside one agent is that here each worker is a full agent, with its own reasoning loop and its own isolated context. That is what enables real parallelisation and stops the reading of one source from contaminating another.

How do the hierarchical and network patterns work?

When a single orchestrator falls short because it coordinates too many workers, the hierarchical pattern nests the orchestrator within another level. Instead of one lead with twenty workers, you have a lead that coordinates several supervisors, and each supervisor directs its own team of workers. It is the same orchestrator-workers principle applied in layers: teams of teams. The LangGraph documentation calls it a hierarchical architecture and recommends it when the number of agents grows until a single supervisor becomes unmanageable.

The network (or mesh) pattern removes the central figure. Each agent can hand control to any other based on what it discovers, without a boss directing everything. It is the most flexible topology and the hardest to control: it serves when the flow is not known in advance and depends on what turns up, but it is easy for agents to loop or step on each other. The following table sums up the three patterns:

The rule is to climb in complexity only when it hurts: start with orchestrator-workers, move to hierarchical when a single orchestrator cannot cope, and reserve the network for cases where no fixed plan works.

How do agents communicate: the handoff?

Agents in a multi-agent system coordinate in two ways, and the choice defines the character of the system. The first is the handoff: one agent cedes control to another, which becomes the active agent for the rest of the turn. The OpenAI Agents SDK implements it as a first-class primitive: a triage agent decides which specialist should respond and passes it the whole conversation. It is a decentralised model, natural for the network pattern, in which the specialist responds directly to the user.

The second is the manager pattern (or agents-as-tools): a manager agent keeps control and calls specialists as if they were tools, through something like Agent.as_tool(). The manager receives each result, combines it and produces the final answer. It is a centralised model, the natural form of orchestrator-workers. The SDK itself advises using the handoff "when you want the specialist to respond directly," and the manager pattern "when you want one agent to own the final answer."

# Handoff (decentralised) versus manager (centralised)

  # Handoff: triage cedes control to the specialist
  triage = Agent(name="triage", handoffs=[support, sales])
  # after the handoff, the specialist responds on its own

  # Manager: the manager calls specialists as tools
  manager = Agent(
      name="manager",
      tools=[researcher.as_tool(), writer.as_tool()],
  )
  # the manager collects each output and writes the final answer

Choosing between the two is not a technical detail: it defines who talks to the user, where guardrails are applied and how the system is debugged. The manager pattern concentrates control and auditing in one point; the handoff spreads responsibility and gains flexibility at the cost of clarity. Frameworks like CrewAI build their role teams on these same two ideas.

What do multi-agent systems cost, and how do they fail?

Cost is the great counterweight. According to Anthropic’s measurements, an agent consumes around 4 times more tokens than a normal chat interaction, and a multi-agent system about 15 times more. It is not a detail: in their BrowseComp evaluation, token spend alone explained 80% of the variance in performance. Put another way, much of what a multi-agent system gains it gains because it spends more, so it only makes sense when the value of the task justifies that spend.

The failure modes are characteristic and worth knowing before you suffer them. Anthropic reports that its early versions went as far as "spawning 50 subagents for simple queries, scouring the web endlessly for nonexistent sources, and distracting each other with excessive updates." To that list add the classics: agents that loop by passing control back and forth, subtasks that overlap and duplicate work, and errors that propagate when a worker hands over a bad result the orchestrator takes as good. The defence runs through explicit limits (a maximum number of subagents, steps and cost), human oversight at the critical points and observability that reveals what each agent did. A multi-agent system is not a better agent: it is a distributed system, with everything that implies.

Frequently asked questions

How does a multi-agent system differ from a single agent with many tools?

A single agent with many tools shares one reasoning loop and one context window: the whole task lives in the same head. A multi-agent system splits the work across agents with separate contexts, each with its own reasoning. That separation enables real parallelism and isolates information, but it adds coordination, token cost and new failure modes. That is why it pays to start with the single agent and make the leap only when the task demands it.

Which multi-agent pattern should I choose first?

Start with orchestrator-workers. It is the easiest to reason about and debug: a lead that plans, delegates to parallel subagents and synthesises. Move to the hierarchical pattern when a single orchestrator coordinates too many agents and becomes a bottleneck. Reserve the network pattern for unpredictable flows in which no fixed plan works, accepting that you gain flexibility in exchange for much harder control.

Are the handoff and the manager pattern mutually exclusive?

No. Many real systems combine both: a central manager that calls specialists as tools for most of the work, plus occasional handoffs when it suits for a specialist to keep the conversation. What matters is deciding consciously who owns the final answer and where the guardrails are applied, because the system’s auditing and debugging depend on it.

Conclusion

Multi-agent system patterns are, at heart, three ways to split a task: a lead that delegates (orchestrator-workers), teams of teams (hierarchical), or a bossless mesh (network), communicating through handoffs or a manager’s calls. They are not magic: a well-built multi-agent system comfortably beats a single agent on parallel, broad tasks, but it spends far more and fails in new ways. The sensible next step is to stick with the single agent while it suffices and, when you truly need to split, start with orchestrator-workers and compare frameworks in the guide to LangGraph versus CrewAI and Autogen.

Sources: [1] Anthropic, how we built our multi-agent research system^[1], [2] OpenAI Agents SDK, orchestrating multiple agents^[2], [3] LangGraph, multi-agent architectures^[3], [4] Anthropic, building effective agents^[4].

Sources

1. Anthropic, how we built our multi-agent research system
2. OpenAI Agents SDK, orchestrating multiple agents
3. LangGraph, multi-agent architectures
4. Anthropic, building effective agents

Route: AI Agents Fundamentals