Many Agents: Subagents, Communication and Orchestration

An agent’s context fills as it works (Context Engineering): every file it reads and every tool result stays, and a long task pushes out what it needs. One answer is to compress the context. Another is to split the work: hand pieces of the task to other agents, each with its own fresh context, and collect what they find. This post covers that second answer, its patterns and protocols, and an honest accounting of what it costs.

Table of contents

Why subagents

A subagent is an agent started by another agent to do part of its task, with its own context window, its own instructions, and often its own tools. It returns a result, usually a summary, and its working context disappears. Three things follow:

• Context isolation. The fifty files a subagent read to find one fact never enter the main agent’s context; only the fact does. This is the same benefit as compaction, achieved by never filling the context in the first place.
• Parallelism. Independent subtasks can run at the same time, which cuts wall-clock time.
• Specialization. Each subagent can get a focused prompt, a smaller tool set, or a different model (cheaper for search, stronger for synthesis).

Roles and topologies

Multi-agent systems assign roles: a planner or lead that decomposes the task, workers or specialists that execute parts, sometimes a critic or verifier that checks results. AutoGen (Wu et al., 2023) popularized writing systems as conversations among such agents.

How they talk is the topology:

• Direct: agents message each other pairwise, as in a chain where each passes its output to the next, or a handoff, where one agent transfers the whole conversation to another better suited to continue (a triage agent handing a billing question to a billing agent).
• Central: every message goes through one coordinator, which assigns work and collects results. Easiest to reason about, and the coordinator is a bottleneck and a single point of failure.
• Broadcast: every agent sees every message, as in a group chat or a debate. Maximal information sharing, and every agent’s context fills with everyone else’s work.
• Shared memory: agents read and write a common store (a file, a database, a scratchpad, Agent Memory’s memory) instead of messaging, which decouples them in time.
• Hierarchical: central coordination nested, with leads of leads, for tasks too big for one coordinator.

The choice decides what each agent sees, which is the main lever: too little and they duplicate or contradict each other; too much and the context isolation that justified splitting is gone. Learned Orchestration’s “orchestration collapse”, where agents sharing one transcript all follow the first one’s lead, is what too much sharing looks like.

Protocols: A2A

Inside one application, agents can pass Python objects. Across vendors and services they need a protocol. A2A (Agent2Agent), announced by Google in April 2025 and moved to the Linux Foundation that June, is the main one. Its pieces, as its specification describes them:

• an Agent Card, a JSON document at a well-known URL (/.well-known/agent-card.json) that advertises what an agent can do, its endpoint and how to authenticate;
• tasks, the unit of delegated work, with a lifecycle (submitted, working, input-required, completed, failed, canceled, among others) and the messages and output artifacts that belong to them;
• transport over HTTP, with JSON-RPC 2.0 the original binding (gRPC and a REST-style binding came later), Server-Sent Events for streaming progress, and push notifications to a webhook for tasks that run long.

A2A and MCP (Giving Agents Tools and Knowledge) are complementary: MCP connects an agent to tools and data, which do what they’re told; A2A connects an agent to other agents, which have their own judgment and may take a while, ask questions, or fail in ways a tool doesn’t.

Orchestration patterns

The common shapes, from simplest to most general:

• Sequential: a pipeline; each agent’s output is the next one’s input (draft, then review, then edit).
• Parallel: independent agents work at the same time and their results are merged (several searches, or several answers to vote on).
• Conditional: a router sends the task to one of several agents based on its type (Learned Orchestration’s Fugu is a learned router).
• Loop: an agent and a checker alternate until the checker passes the result (write, test, fix).
• Orchestrator-worker: a lead plans, spawns workers for the subtasks it decided on, reads their results, and decides what to do next, possibly spawning more. The plan is made at run time, which makes this the most flexible pattern and the one used for open-ended research.

What it costs: a model on real sizes

Take one research question over this blog that needs six posts: how do the inference posts trade memory bandwidth against compute? One agent could read all six; or a lead could brief six workers, one per post, and synthesize their summaries. cost_model.py first counts the six posts’ real sizes in tokens, with Qwen2.5’s tokenizer standing in for any model’s, from a snapshot of the blog. Then the cost model:

# A cost model of input tokens (output tokens, fewer but pricier, are left
# out). Each model call rereads its whole context. With prompt caching
# ("Prompt Caching"), a call reads what the previous call sent at 0.1x the price and
# writes only what's new at 1.25x. Assumed: a 2,000-token system prompt and
# task; each post read over STEPS calls; 300 tokens of reasoning per call;
# workers get a 200-token brief and return 600-token summaries; the lead
# writes the briefs in one call and, once all workers have returned in
# parallel, synthesizes in one more.
SYS, THINK, BRIEF, SUMMARY = 2000, 300, 200, 600
def agent(prefix, chunks):
    """(input tokens read, cost with caching in uncached-token equivalents,
    largest context, model calls) for one agent reading chunks in order."""
    read, cached, context, prev = 0, 0.0, prefix, 0
    for c in list(chunks) + [0]:                     # the last call writes the answer
        read += context
        cached += 0.1 * prev + 1.25 * (context - prev)
        prev = context
        context += c + THINK if c else 0
    return read, cached, prev, len(chunks) + 1

def compare(steps, explore):
    """explore: how much each worker reads relative to its share (searching
    finds overlapping and irrelevant material)."""
    single = agent(SYS, [d / steps for d in docs for _ in range(steps)])
    workers = [agent(SYS + BRIEF, [d * explore / steps] * steps) for d in docs]
    lead_plan = agent(SYS, [])                                          # one call: write the six briefs
    lead_synth = agent(SYS + len(docs) * (BRIEF + SUMMARY), [])         # one call: read the summaries, answer
    multi = [sum(x[i] for x in [lead_plan, lead_synth] + workers) for i in (0, 1)]
    seq_multi = 1 + max(w[3] for w in workers) + 1
    return single, multi, max(w[2] for w in workers + [lead_synth]), seq_multi

Full script: cost_model.py

posts to read: 5,972, 8,695, 5,638, 5,703, 8,117, 8,626 (total 42,751 tokens)

assumptions                                        tokens read  cached cost  largest context  sequential calls
each post in 4 reads, no extra search  single          651,186      124,862           51,951                25
                                       lead + 6        199,678      102,711           12,095                 7
each post in 1 read                    single          164,128       69,946           46,551                 7
                                       lead + 6         79,751       84,509           11,195                 4
workers search twice as much           single          651,186      124,862           51,951                25
                                       lead + 6        306,555      162,563           20,790                 7

what reaches the lead: 3,600 tokens of summaries for 42,751 tokens of posts (8.4%)

The three blocks change the assumptions: how many separate reads each post takes, and how much extra searching workers do on top of their share. Some conclusions survive all three; one doesn’t.

• The token bill can go either way. Without caching, the single agent reads more in every case, because each call rereads a context that keeps growing. With prompt caching (see Prompt Caching), rereads cost a tenth, and the comparison flips with the assumptions: the lead and workers are cheaper in the first case, more expensive when each post is read in one go, and 30% more expensive when workers search twice as much as their share strictly requires. Splitting is not a reliable way to save tokens. (The single agent here also never compacts its context, which Context Engineering would have it do.)
• The largest context is a quarter to two-fifths the size in every case: no worker’s context exceeds 21,000 tokens, against 47,000 to 52,000 for the single agent. Models use long contexts worse than short ones (Long Context, and Where It Breaks), so that difference is about quality, not price.
• Latency drops because the workers run at the same time: the longest chain of sequential model calls is the lead’s briefing, one worker’s reads, and the lead’s synthesis, 7 calls against 25.
• Information is lost. The lead sees 3,600 tokens of summaries for 42,751 tokens of posts, 8%. Whatever a worker didn’t think to include is gone, and if the question needs a connection between two posts that only appears when both are read side by side, no worker can make it.

Real systems do more work, not less, when they split. Anthropic’s account of its multi-agent research system reports that a Claude Opus 4 lead with Claude Sonnet 4 subagents outperformed a single Claude Opus 4 agent by 90.2% on its internal research evaluation, while multi-agent runs used about 15 times as many tokens as a chat interaction (single agents about 4 times). On a browsing benchmark, token usage alone explained 80% of the variance in performance. Read together: much of the gain comes from spending more tokens, in parallel, across more separate contexts than one agent could hold, and that pays only when the task is worth it.

When multi-agent loses

The same report is direct about poor fits: tasks where all agents need the same context, or where subtasks depend on each other in many ways. Most coding tasks, it notes, involve fewer truly parallelizable parts than research does. The model above shows why. Splitting pays when subtasks are independent (each worker’s summary is enough), when the context one agent would need is too large to use well, and when the value of the result covers the extra tokens. It loses when the answer depends on details only visible across pieces, when coordination messages grow faster than the work, and on easy tasks, where a single agent with good context management is cheaper and just as good.

The case against multi-agent designs has been made directly. Cognition’s “Don’t Build Multi-Agents” (2025) argues that subagents working from partial context make conflicting decisions, and that a single agent with a well-managed context is more reliable for most tasks. A study of failures in multi-agent systems (Cemri et al., 2025) found that many come not from the models but from the system design: badly specified roles, agents ignoring each other’s output, and no one verifying the result. Two practices address both: write each subagent’s brief as carefully as a prompt for a person (the objective, the output format, what’s out of scope, where to look), and verify what subagents return rather than trusting it, with a check or a separate reviewer.

Where this leads

• Learned Orchestration makes the orchestrator a trained model that routes requests to frontier workers or writes whole workflows, and names the herding that too much sharing causes.
• LangChain and LangGraph, from the Inside shows the runtime underneath: a graph with shared state, where the Send mechanism fans work out to parallel nodes.
• How Coding Agents Work shows subagents built into Claude Code and Cursor, mostly for context hygiene during search.

Takeaways

• Subagents buy context isolation, parallelism and specialization; the price is coordination and whatever doesn’t make it into a summary.
• Topology (direct, central, broadcast, shared memory) decides what each agent sees, and too much sharing undoes the isolation.
• A2A standardizes agent-to-agent delegation (agent cards, tasks, JSON-RPC over HTTP); MCP connects agents to tools.
• On real sizes, a lead with six workers kept every context at a quarter to two-fifths of the single agent’s and cut the sequential calls from 25 to 7; its token bill, with caching, was lower or higher depending on the assumptions; and it passed only 8% of the source material to the lead.
• Published results show large gains from multi-agent research at about 15 times the tokens of chat; tasks with shared context or tight dependencies, including most coding, favor a single agent.

References

Start with Anthropic’s account of its multi-agent research system and Cognition’s Don’t Build Multi-Agents, read together; Cemri et al. catalogs how such systems fail.

• Anthropic, How we built our multi-agent research system (2025): the 90.2% gain, the token multiples, and the tasks multi-agent fits poorly.
• Wu et al., AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation (2023): multi-agent systems written as conversations among roles.
• Cognition, Don’t Build Multi-Agents (2025): the case for one agent with a well-managed context.
• Cemri et al., Why Do Multi-Agent LLM Systems Fail? (2025): a taxonomy of how multi-agent systems fail, many of the failures from system design rather than the models.
• A2A Protocol (specification, Linux Foundation): agent cards, tasks and their lifecycle, and the transport bindings.