Multi-Agent Systems: Patterns and Pitfalls

What multiple agents actually buy you

A single agent running a tool loop is the baseline, and for many tasks it's the right answer. Anthropic's "Building effective agents" guide still recommends starting with the simplest thing that works: a single call, then a fixed workflow, and only then autonomous agents. So why split work across several agents?

The costs are just as real. Every agent spends tokens, every handoff can lose information, and coordination itself can fail. The core trade-off for this module: multi-agent designs buy parallelism and context isolation at the price of tokens and coordination overhead. They shine when subtasks are independent and context-heavy, and they struggle when subtasks are tightly coupled.

The main patterns

Real systems often mix these, but almost every multi-agent design is built from a handful of shapes.

Case study: Anthropic's multi-agent research system

In June 2025 Anthropic published a detailed write-up of the system behind Claude's Research feature. It's one of the best public accounts of an orchestrator-worker system in production, and its numbers are worth knowing.

1. 1

   A lead agent plans

   A lead agent (Claude Opus 4 at the time) analyzes the question, decides on a strategy, and writes its plan to memory so it survives if the context gets long.

2. 2

   Subagents search in parallel

   The lead spawns several subagents (Claude Sonnet 4), each with its own context window and a specific slice of the question. They search, evaluate results and return condensed findings.

3. 3

   The lead synthesizes

   The lead combines the findings and decides whether more research is needed, spawning more subagents if so.

4. 4

   A citation agent attributes sources

   A separate agent goes through the final report and attaches citations to the claims.

The most important number is the second one. If token usage explains most of the performance difference, then a big part of why the multi-agent system wins is that it spends more compute, spread across many fresh context windows. That's a fine trade for high-value research questions. It's a bad trade for a quick lookup.

• Teach the orchestrator to delegate. Each subagent needs an objective, an output format, guidance on tools and sources, and clear boundaries. Vague instructions caused duplicated work and gaps.
• Scale effort to complexity. Simple questions get one agent and a few tool calls; complex ones get many subagents. Without explicit rules, agents over-invest in easy queries.
• Start wide, then narrow. Broad queries first to map the territory, then targeted ones.
• Evaluate with judges and humans. An LLM judge with a rubric scales; human review catches what the rubric misses.

An orchestrator-worker sketch

Here's the shape of an orchestrator-worker loop in Python-style pseudo-code. Real frameworks hide much of this, but the structure is the same.

def research(question, budget):
    plan = lead.plan(question)            # decide how many workers, and on what
    memory.save("plan", plan)             # survive context limits

    findings = []
    while not plan.done and budget.remaining():
        briefs = [
            Brief(
                objective=sub.goal,
                output_format="5 bullet points with source URLs",
                tools=["web_search", "fetch"],
                boundaries=sub.out_of_scope,   # avoid overlap between workers
                max_tool_calls=sub.effort,     # scale effort to difficulty
            )
            for sub in plan.next_subtasks()
        ]
        # Each worker runs in its own context window, in parallel.
        results = run_in_parallel(worker.run, briefs, timeout=600)
        findings += [r.summary for r in results if r.ok]
        plan = lead.update_plan(question, findings)

    draft = lead.synthesize(question, findings)
    return citation_agent.attach_sources(draft, findings)

Notice where the design effort goes: the brief. Most of what makes this work is that each worker gets a clear goal, a defined output format, boundaries that prevent overlap, and an effort budget. The lead also has an explicit stopping rule (the plan is done or the budget runs out), which turns out to matter a lot, as the next section shows.

Why multi-agent systems fail

The most cited study of multi-agent failures is MAST, the Multi-Agent System Failure Taxonomy, from Cemri and colleagues at UC Berkeley ("Why Do Multi-Agent LLM Systems Fail?", NeurIPS 2025). The team analyzed seven popular multi-agent frameworks across more than 200 tasks, annotating over 1,600 execution traces, with high agreement between annotators (κ = 0.88).

They found 14 failure modes in 3 categories:

The headline finding: most failures came from system design and coordination, not from the underlying model being too weak. In one example, ChatDev reached only 33.33% correctness on the ProgramDev benchmark. That means many fixes are engineering fixes: clearer roles, explicit handoff formats, and real verification steps.

The 2026 skeptics, and why diversity matters

By 2026 a wave of papers had started asking whether multi-agent systems help as much as their popularity suggests. These are recent preprints, so treat them as an active debate rather than settled results.

• Recent papers argue that automatically designed multi-agent systems often fail to beat a single model using chain-of-thought plus self-consistency (sampling several answers and voting) at equal cost ("The Illusion of Multi-Agent Advantage").
• Others study how agent systems scale and where flat designs hit limits as you add agents ("Towards a Science of Scaling Agent Systems"; "Width, Memory, and Delay").
• Some work tries to distill multi-agent behavior back into a single agent ("AgentArk"), suggesting that part of the benefit can be captured without the coordination overhead.

The common thread is equal cost. As the Anthropic case study showed, a multi-agent system often wins partly because it spends more tokens. A fair comparison gives the single agent the same budget, and when you do that, the advantage often shrinks.

One line of research offers an explanation. A paper on agent scaling through diversity argues that homogeneous agents saturate: if every agent is the same model with the same prompt, their mistakes are correlated, so adding more of them mostly repeats the same errors. Heterogeneous agents (different models, prompts, tools or information) add genuinely new information.

Design principles

1. 1

   Start with one agent

   Build the single-agent version first and measure it. You need a baseline anyway to know whether the multi-agent version is better.

2. 2

   Split along independent seams

   Divide work where pieces don't need to talk to each other. If two workers must constantly coordinate, they probably should be one agent.

3. 3

   Write briefs, not wishes

   Every delegation needs an objective, output format, tools, boundaries and an effort budget.

4. 4

   Use structured handoffs

   Pass results in a defined shape (JSON, a schema, an A2A artifact) rather than free text, so nothing gets lost or reinterpreted.

5. 5

   Verify independently and stop deliberately

   Add checks that don't share the author's blind spots, and give the system explicit termination rules and budgets.

6. 6

   Diversify where you need judgment

   For critique or voting, vary models, prompts or evidence so errors aren't correlated.

7. 7

   Trace everything

   Log every delegation, message and result with shared IDs. Multi-agent bugs are nearly impossible to fix without traces.

Decision checklist: do you need multiple agents?

Before reaching for a multi-agent architecture, run through these questions. The more "yes" answers, the stronger the case.

1. Does a well-built single agent clearly fall short on your evals?
2. Does the task split into pieces that can run independently?
3. Would one agent's context overflow, or get polluted, if it did all the work?
4. Do different pieces need different tools, permissions or models?
5. Is the task valuable enough to justify several times the token cost?
6. Can you verify the combined output automatically or cheaply?
7. Does part of the work belong to another team or organization's agent?