Multi-Agent Systems: When Orchestrators and Subagents Pay Off

1.What makes a system multi-agent

A multi-agent system runs several LLM instances, each with its own conversation context, and coordinates them through code. Each agent handles a distinct slice of the task. Several coordination patterns exist, including agent swarms, capability-based systems and message bus architectures. The one Anthropic recommends starting with is orchestrator-subagent: a lead agent spawns specialised subagents for specific subtasks and manages them. It is hierarchical and has a simple coordination model.

Claude Managed Agents builds this pattern into the platform. One agent coordinates the others, and the others can work in parallel, each in its own isolated context. The docs say this can improve output quality and can also shorten time to completion. The coordinator reports its activity in the primary thread, which is the same as the session-level event stream. New threads are spawned at runtime whenever the coordinator delegates work.

Sources12

2.Deciding whether multiple agents are worth it

The starting point is one agent. Anthropic reports that some teams spent months building elaborate multi-agent architectures, only to find that better prompting of a single agent gave the same results. One design split planning, execution, review and iteration into separate agents. It lost context at every handoff and spent more tokens coordinating than executing. Every added agent is another possible point of failure and another set of prompts to maintain.

Anthropic names three situations where multiple agents consistently beat one: context pollution is degrading performance, the tasks can run in parallel, or specialisation improves tool selection or task focus. Outside those situations, coordination usually costs more than it returns. The Managed Agents docs describe the same fit: complex tasks that need work across many surfaces, or several well-scoped tasks that each contribute to an overall goal. The research-system post adds where it fits poorly. Domains where every agent needs the same context, or where agents depend heavily on each other, are poor candidates today. Most coding tasks offer fewer truly parallelisable pieces than research does.

Sources123

3.Context isolation: keeping the main agent's reasoning clean

Context windows are finite, and response quality can drop as context grows. Context pollution happens when material gathered for one subtask stays in the context and is irrelevant to the subtasks that follow. Anthropic's example is a customer support agent that has to look up order history while diagnosing a technical fault.

class OrderLookupAgent:
    def lookup_order(self, order_id: str) -> dict:
        # Separate agent with its own context
        messages = [
            {"role": "user", "content": f"Get essential details for order {order_id}"}
        ]
        response = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=1024,
            messages=messages,
            tools=[get_order_details_tool]
        )
        # Returns only essential information
        return extract_summary(response)

Isolation works best under three conditions. The subtask generates a lot of context (over 1,000 tokens) and most of it is irrelevant to the main task. The subtask is well defined, with clear criteria for what to extract. Or it is a lookup or retrieval that needs filtering before its result is used. Managed Agents enforces this separation: each agent runs in its own thread, so a subagent's reading never lands in the coordinator's history.

Sources12

4.Parallel subagents: buying thoroughness with tokens

The second reason to split is to cover a larger search space than one agent can. In Anthropic's Research feature, a lead agent analyses the query, plans a strategy and spawns subagents to investigate different facets at the same time. The post calls search a problem of compression. Each subagent works in its own context window and condenses the most important tokens for the lead agent. Each also has its own tools, prompt and exploration path, which reduces path dependency.

async def research_topic(query: str) -> dict:
    # Lead agent breaks query into research facets
    facets = await lead_agent.decompose_query(query)

    # Spawn subagents to research each facet in parallel
    tasks = [
        research_subagent(facet)
        for facet in facets
    ]
    results = await asyncio.gather(*tasks)

    # Lead agent synthesizes findings
    return await lead_agent.synthesize(results)

On Anthropic's internal research eval, a system with Claude Opus 4 as lead and Claude Sonnet 4 subagents beat single-agent Claude Opus 4 by 90.2%. The gains were largest on breadth-first queries. One example was listing the board members of every IT company in the S&P 500: the single agent failed with slow, sequential searches. The post's explanation is budget. In its BrowseComp analysis, token usage alone explained 80% of the performance variance, and spreading the work across separate context windows adds capacity. The cost is steep: multi-agent systems used about 15× more tokens than chat interactions. They only make economic sense when the task is valuable enough to pay for the gain.

Sources132

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Splitting a task into separate planning, execution, review and iteration agents will improve quality.Why is that wrong?

   Teams that built exactly this found it lost context at each handoff and spent more tokens coordinating than doing the work. Split only for context pollution, parallel work or specialisation.

   Covered in Deciding whether multiple agents are worth it

2. 2.Running subagents in parallel makes a multi-agent system faster end to end than a single agent.Why is that wrong?

   Parallelism only beats running the same work in sequence. Because total computation goes up so much, multi-agent systems often take longer overall. What you gain is thoroughness.

   Covered in Parallel subagents: buying thoroughness with tokens