Companion code: 07-topologies

TL;DR

• Multiple agents help when work splits into independent, read-heavy pieces (research, broad search, many files), and when a strong lead or a test suite checks and integrates the pieces.
• They hurt when steps depend on each other or when agents must write into shared work, because each agent makes decisions the others can’t see.
• They rarely cost less. Anthropic’s research system used about 15× the tokens of a chat. In our own small, read-only test the total was about the same as one agent, and what four agents bought was a 4× smaller context and a 3× faster run. Spend extra agents where those things matter.

Two essays, one apparent disagreement

In June 2025, within a day of each other, two of the best-known pieces of writing on agent architecture appeared and seemed to point in opposite directions.

Anthropic, How we built our multi-agent research system. Its research feature uses a lead agent that plans a search strategy and spawns sub-agents to explore different directions in parallel, each with its own fresh context. On Anthropic’s internal research evaluation, the multi-agent setup (an Opus 4 lead with Sonnet 4 sub-agents) outperformed a single Opus 4 agent by 90.2%. Its analysis of why was blunt: across one browsing benchmark, how many tokens were spent explained about 80% of the variation in performance. Multiple agents are, among other things, a way to spend more tokens in parallel, each in a clean context.

Cognition, Don’t Build Multi-Agents (Walden Yan). It argued that splitting work across agents is fragile, for two reasons. Sub-agents need the full context of the task, not a one-line brief. And every action carries implicit decisions, so agents working in parallel make choices the others can’t see. Its example: asked to build a Flappy Bird clone, one sub-agent builds a background in the style of a different game, another builds a bird that doesn’t match it, and the agent combining them is stuck with incompatible parts. The recommendation was a single agent with one continuous context, compressing its history when a task runs long.

Read quickly, it’s “multi-agent works” against “multi-agent doesn’t”. Read carefully, they’re describing different kinds of task.

What actually differs: the shape of the task

Anthropic’s example is research: breadth-first, read-heavy work. Sub-agents explore different sources, nothing they read conflicts with what another reads, and the lead integrates a set of findings. Anthropic says plainly that this doesn’t carry over to everything. Domains where agents must share context, or where there are many dependencies between agents, are a poor fit, and they named most coding tasks as one.

Cognition’s example is building software: write-heavy work, where every piece must fit every other piece. The Flappy Bird failure isn’t a failure of reading. It’s two agents writing parts that encode different unstated assumptions.

So the first question isn’t “how many agents?” but “do the pieces of this task need to know about each other?”

The controlled evidence

Essays from teams building products are informative but uncontrolled. In December 2025, Towards a Science of Scaling Agent Systems (Kim et al.) ran the controlled version: 260 configurations across six agentic benchmarks. It compared a single agent against four multi-agent arrangements (independent, centralized, decentralized and hybrid) with the tools, prompts and compute held constant. The findings line up with the two essays:

• Task shape decides. On a financial-reasoning benchmark that splits naturally into parallel analyses, multi-agent setups improved performance by up to 80.8%. On sequential planning, where each step depends on the last, they reduced it by up to 70%.
• Strong single agents leave less to gain. Coordination gave diminishing returns once the single-agent baseline was already good. As models get better, the bar for adding agents rises.
• Someone has to check the work. Architectures without centralized verification let errors spread further than those with a coordinator that reviews what workers produce.
• It’s partly predictable. The authors’ model of task properties picked the best architecture for 87% of held-out configurations. Choosing well is a matter of analysing the task, not luck.

And a counter-example that proves the rule

If coding is a poor fit, how did Anthropic build a C compiler with a team of parallel Claudes (February 2026)? Sixteen agents worked in parallel for about two weeks: roughly 2,000 sessions and about $20,000 of compute, producing a 100,000-line compiler able to build a bootable Linux kernel on three architectures.

The write-up shows exactly how they got around Cognition’s objection: they made the work separable and the decisions explicit.

• A test suite acted as the integrator. Every agent’s work had to pass a large shared suite, so incompatible assumptions showed up as failures, not as a surprise at the end.
• Tasks were claimed explicitly. Agents took tasks by writing lock files into the shared repository, so no two agents picked the same work.
• Monolithic tasks were broken up artificially. When compiling the Linux kernel became one giant task, they used GCC as an oracle to compile part of it, so different agents could chase different bugs.

The authors’ main lesson was about tests, not agents: autonomous agents solve whatever problem the verification defines. Parallel writing works when something objective checks that the pieces fit.

A decision guide

Putting the four sources together, five questions settle most cases:

1. Is the work separable? Can you split it into pieces that don’t need each other’s results? Research questions, many files, and many records usually are. Multi-step plans and single designs usually aren’t.
2. Is it read-heavy or write-heavy? Parallel reading is safe, because the worst case is redundant reading. Parallel writing into shared work needs explicit coordination.
3. What integrates and checks the results? A lead model that reviews, a test suite, or plain code with a strict output format. Without one, errors pass straight through.
4. Is the single agent already good enough? If one agent with good context management (post #3) solves it, more agents mostly add cost.
5. Is the task worth several times the tokens? Anthropic measured its multi-agent system at roughly 15× the tokens of a chat (a single agent was about 4×). That’s fine for an hour of research, and wasteful for a quick lookup.

There’s also a middle path that captures most of the benefit: use sub-agents for reading, keep writing in one place. A single main agent hands self-contained investigations (“summarize these ten reports”, “find where this function is used”) to sub-agents with fresh contexts, gets back short answers, and makes every decision itself. That’s the “sub-agent” option from post #3, seen as a topology.

The experiment

The companion code runs the incident-report question from post #3 under three topologies:

async def workers(n: int = 4) -> str:
    """Code splits the work, sub-agents read in parallel, code merges. No model coordinates anything."""
    files = all_files()
    batches = [files[i::n] for i in range(n)]
    tables = await asyncio.gather(*(reader(b, f"worker {i + 1}") for i, b in enumerate(batches)))
    return answer_from_table("\n".join(tables))

• single: one agent reads all 24 reports.
• workers: code splits the reports four ways, four sub-agents read in parallel, and code adds up their results. This is the “independent” architecture with a strict output format standing in for verification.
• orchestrator: a lead model decides how to split the reports through a delegate tool, and writes the final answer itself.

Each run reports the total tokens across all agents, the largest context any single agent held, and the time taken. Here’s what one run of each looked like against Claude Opus 5.5. All three answered correctly.

Topology	Agents	Total tokens read	Largest single context	Time
single	1	71,106	70,493	20 s
workers (code merges)	4	73,723	18,034	6 s
orchestrator (model merges)	4	75,199	23,903	16 s

The total cost barely moved: within about 6% across all three. What changed was everything else. Splitting the work made the biggest context four times smaller and the run three times faster. The orchestrator added a little overhead for its own planning and merging, and the code-merged workers were fastest because no model had to read the combined results. That’s the trade in its purest form: on a separable, read-only task, multiple agents buy you smaller contexts (which matters as tasks grow past what one context can hold well) and parallel speed, not lower cost.

Then try the README’s experiments: make the sub-agents return prose instead of the fixed line format, and watch the code merge break while the orchestrator copes, at a cost in tokens.

This task is deliberately on the friendly side of the guide: separable, read-only, with an exact way to combine results. That’s the point. Most real tasks need checking against the five questions first.

Trade-offs

• Hand-offs lose information. Every sub-agent works from a brief, not from the full context. Anthropic’s write-up spends much of its prompting advice on teaching the lead to delegate well: objectives, output formats, boundaries.
• Errors multiply quietly. A sub-agent’s mistake becomes the lead’s input. Without verification, the lead can’t tell a wrong finding from a right one. Post #8 is about exactly this.
• Debugging is harder. Several non-deterministic agents running in parallel need tracing to understand after the fact. We’ll come back to that in post #15, on observability.

Next in the series: Why multi-agent systems fail.

Sources & further reading

• Anthropic, How we built our multi-agent research system (Jun 2025).
• Walden Yan (Cognition), Don’t Build Multi-Agents (Jun 2025).
• Kim et al., Towards a Science of Scaling Agent Systems (Dec 2025).
• Anthropic, Building a C compiler with a team of parallel Claudes (Feb 2026).

#multi-agent #architecture #evidence