Single-Agent vs Multi-Agent Architecture: Where You Can Afford to Lose Context

Choosing between single-agent and multi-agent architectures is a trade-off between context preservation and parallelism, not system topology. Every agent boundary acts as a lossy compression step, silently dropping context without throwing errors or warnings.

Two respected teams say opposite things about multi-agent systems. Both are right, and the line between them runs straight through the handoff.

Key Takeaways

• The real question isn't topology, it's information: "Single or multi-agent" is the wrong frame. Ask where your system can afford to lose context, because every agent boundary is a lossy compression step.
• Both camps are right: Anthropic's multi-agent research system beat a single agent by 90.2%. Cognition published "Don't Build Multi-Agents." They're describing different workloads - read-heavy research versus write-heavy coding - not disagreeing.
• A handoff is not a function call: A function loses nothing. A handoff loses whatever the writing agent didn't think to write down, and nothing errors when it does.
• The tax is real and I've paid it: One change in my own coding pipeline silently lost two approved decisions between stages. No automated signal caught either one.
• The rule that works: Fan out for read-only, additive, disposable work. Stay single-threaded when steps depend on each other and share state.

Table of Contents

• Both Camps Are Right, and That Tells You Something
• Every Handoff Is a Lossy Compression Step
• The Handoff Tax: What It Actually Cost Me
• The Rule I Use Now: Read Fans Out, Writes Stay Single
• Architecture Is a Bet About Where You Can Afford to Be Wrong

You've probably read both posts.

Anthropic ships a multi-agent research system and reports it beating a single agent by 90.2% on their internal eval. Cognition publishes an essay titled "Don't Build Multi-Agents." Same industry, same year, opposite conclusions, both from teams whose work I take seriously.

So you sit down to design your own system and the advice cancels out. What's left is whatever orchestration framework you already installed, plus a diagram of an orchestrator fanning out to workers that every vendor now puts on their landing page. None of it tells you when to actually reach for one.

Here's the thing: those two teams aren't disagreeing. They're answering a narrower question than the one they appear to be answering, and once you see which question, the choice stops being a matter of taste.

I run both architectures in the same repository, on purpose. My assistant's reasoning brain is deliberately single-threaded. My coding pipeline is a five-stage multi-agent loop that has shipped more than 30 merged changes. Let me show you what that taught me, including the part it cost me.

Both Camps Are Right, and That Tells You Something

Start with the numbers, because they're more specific than the debate around them.

Anthropic's write-up reports that a multi-agent system with Claude Opus 4 as the lead and Sonnet 4 subagents "outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval." That's not a rounding error. It's also not free: they measure agents at roughly 4x the tokens of a chat interaction, and multi-agent systems at roughly 15x. Call it four times the cost of the single-agent path for that win.

Cognition's position is the opposite in tone: use a single-threaded linear agent where the context is continuous. Their argument is that parallel subagents don't see each other's work, so they drift into conflicting decisions built on partial understanding of the same task.

Now read the workloads instead of the conclusions.

Anthropic's win case is research. Many independent lookups, outputs that stack additively, no shared mutable state, and a search space far bigger than one context window. Cognition's warning case is coding. Steps that depend on each other, shared state, and usually one file that several agents all want to edit.

Anthropic says as much in the same post. Multi-agent systems excel at "heavy parallelization, information that exceeds single context windows," and perform poorly in "domains that require all agents to share the same context or involve many dependencies between agents." They add the line most people skip: "most coding tasks involve fewer truly parallelizable tasks than research."

There's no contradiction to resolve. There's one variable, and both teams are measuring it from different ends: how much context has to survive the boundary between agents.

Every Handoff Is a Lossy Compression Step

Let's break this down from first principles. What actually crosses an agent boundary?

Not the context. A string.

A plan document, a JSON blob, a summary paragraph. That's the entire payload. Meanwhile the agent that wrote it is holding every file it read, every approach it considered and rejected, the correction you gave it six turns ago, and the constraint it quietly inferred from your codebase and never articulated.

The receiving agent gets the artifact. Everything else is gone, and nothing tells you what was dropped.

This is what makes a handoff fundamentally different from a function call. A function call loses nothing: arguments in, return value out, and the contract is enforced by a type system that fails loudly when you break it. A handoff loses whatever the writing agent didn't think to write down, and there is no compiler for "you forgot the constraint we agreed on in turn six."

Here's the insidious part. The loss is silent and the receiving agent is fluent. It reads an incomplete plan and produces confident, well-structured, tests-passing work built on a spec that quietly dropped a decision. Nothing throws. Nothing warns. The output looks exactly like correct output, because the failure is an absence and absences don't raise exceptions.

A single-threaded agent has exactly one architectural advantage over this, and it's decisive: zero handoffs, therefore zero handoff loss. Every step is informed by everything that came before it because it's all still sitting in the same context.

Almost everything else about the single agent is worse. It serializes work that could run in parallel. It fills its context window and starts degrading. It drags irrelevant history into every later step.

So that's the actual trade, and it's the only one that matters here: context-window pressure versus handoff loss. Pick which failure mode you'd rather debug.

The Handoff Tax: What It Actually Cost Me

Enough theory. Here's the bill.

My coding pipeline is a five-stage loop running in an isolated git worktree: explore, plan, implement, review, finalize. Different stages run on different models with fresh context at several boundaries. The implement stage is deliberately amnesiac - every iteration starts with no memory of the previous one and re-reads the plan file from disk, so the plan is the entire carrier between what was decided and what gets built.

That's the design working as intended. It's also precisely where the tax gets charged.

On one change (a fix to my assistant's daily reflection job), the pipeline lost two owner-approved decisions between gates, and no automated signal caught either.

1. A decision that silently changed. The explore stage committed to "no new state file, read the existing one." The plan introduced a new state file anyway. That deviation turned out to be correct on the merits, but nobody proposed it as a change. It just appeared, and it only got recorded as a deliberate deviation because I diffed the two documents.

2. A decision that silently vanished. Explore approved suppressing an error line on retryable attempts. The plan dropped it entirely. The implement stage then built the plan faithfully, which is its job. The result would have written three exception dumps into the daily logs on any failing day, and those logs are the input corpus for the next reflection run. Caught at review, one stage from merge.

Look at the pattern. Every stage did its job correctly. Explore explored, plan planned, implement implemented faithfully, review caught one of the two. No stage failed. The loss happened in the gaps between them, which is exactly the place no stage is responsible for.

Two practices came out of that, and I run both now.

Diff every gate against the previous one. Not the headline items - every numbered decision. Checking only the big-ticket changes is precisely how the second one slipped past me.

Verify RED by mutation, not by reading the report. When an agent says "confirmed the test fails without the fix," that claim is prompt-enforced with nothing mechanical behind it. Reverting the fix and re-running takes seconds and is the only thing that actually proves a test isn't vacuous. On that change it reddened 4 of 4 tests, then restored clean.

That second practice generalizes further than it looks. In a multi-agent system, a downstream agent's report about an upstream agent's work is itself a handoff. Same lossy boundary, same silent failure mode. You cannot audit a claim by reading a summary of it.

The Rule I Use Now: Read Fans Out, Writes Stay Single

Same repository, two architectures, and the split isn't arbitrary.

The assistant brain is single-threaded on purpose. One reasoning path, one continuous context, and a human approval gate on anything that writes. It has exactly one fan-out slice: a read-only research worker. That worker gets a fresh isolated context, a restricted read-only tool manifest, and no write tools at all. It runs as many searches and page fetches as its budget allows, then returns one distilled synthesis. The dozens of intermediate results never touch the main context.

That's a context firewall, and it's cheap for one specific reason: the output is additive and disposable. If the worker's synthesis is wrong, I've lost tokens. Nothing was mutated. Nothing needs unwinding.

Compare that to a fan-out on a write path. When a stage in the coding pipeline drops a decision, the artifact isn't a paragraph I can ignore. It's a commit. Undoing it costs a revert, a re-review, and a re-run.

The same asymmetry showed up in an audit I ran on this codebase: 6 read-only subagents in parallel, one per fragile subsystem, producing a 32-finding register. That fan-out carried almost no handoff risk, because every agent produced findings, not changes, and I re-read each one at source before acting on it. The parallelism bought coverage. The verification stayed mine.

So, the rule, in three lines:

1. Fan out for breadth, read-only work, and disposable output. Research, audit, search, parallel review. It costs tokens and risks almost nothing.

2. Stay single-threaded when steps depend on each other and share state. One writer. Continuous context. This is most coding work, and Cognition is right about it.

3. If you must fan out on a write path, treat the handoff artifact as the product. Version it, diff it at every boundary, put a human on the gate, and verify claims by mutation rather than by report.

One more thing, because it gets skipped in every architecture diagram I've seen: an agent boundary is a trust boundary. Every summary passing between agents is text one agent generated and another treats as instruction. In my system, anything crossing back into the main reasoner is sanitized and wrapped as untrusted external data first, even when it came from my own worker. A subagent that read a poisoned web page should never get to write the orchestrator's next prompt.

Frequently Asked Questions

Isn't a multi-agent system just microservices for LLMs?

It's a useful analogy right up to the point where it breaks. Microservice boundaries carry typed, versioned contracts that fail loudly when violated. Agent boundaries carry prose that fails silently. That single difference is why the operational discipline has to be so much heavier.

Won't bigger context windows make this problem go away?

They remove one reason to split, which is real progress. But the loss was never about capacity, it's about what the writing agent chose to write down. A million-token window doesn't help if the plan document omits a decision. Bigger windows shift the trade toward single-threaded designs; they don't delete the handoff tax.

How much more does multi-agent actually cost?

Using Anthropic's published figures as a baseline: a single agent runs about 4x the tokens of a chat interaction, and a multi-agent system about 15x. So budget roughly 4x on top of your single-agent cost. That's affordable for high-value research and hard to justify for a task one agent could have done serially.

What are the security implications of adding agents?

Every boundary is a new place for untrusted content to enter as if it were instruction. Treat subagent output as external data: sanitize it, wrap it in a trust boundary, and never let a read worker hold write tools. Isolation helps too - my coding pipeline runs in a separate git worktree so a bad iteration can't touch the main tree.

Do I need an orchestration framework for any of this?

No. My five-stage pipeline is a YAML file of prompts and bash steps, and the assistant's fan-out is a single function that mints an isolated session. The hard part is designing the boundary and the verification, not wiring the graph. A framework that makes fan-out one line easier while leaving the handoff undesigned has made your problem worse.

How do I tell whether my handoffs are already losing information?

Diff consecutive artifacts and check that every decision from stage N still appears in stage N+1. If your stages don't produce artifacts you can diff, that's the finding - you can't see the loss because you never made it visible. Fix that before you add another agent.

Architecture Is a Bet About Where You Can Afford to Be Wrong

The single-versus-multi framing is a distraction, and I think it persists because it's phrased as a question about topology when it's really a question about information.

Every architectural choice here is a bet. A single agent bets that your task fits in one context and that you'd rather pay in serialization than in fidelity. A multi-agent system bets the opposite: that the work decomposes cleanly enough for a written artifact to carry everything the next stage needs. Neither bet is wrong. Making one without knowing you made it is.

This matters more each month, not less. The tooling is getting very good at making fan-out easy, and easy is the problem. The cost of a handoff never shows up in the demo. It shows up three stages later, in a change that passed every check and quietly did the wrong thing, and it will cost you an afternoon of diffing to find out that no single component misbehaved.

So before you add a second agent, ask one question: what has to survive the boundary between them? If you can write that down completely, fan out and enjoy the parallelism. If you can't, you don't have a topology problem. You have a specification you haven't finished writing.

Adding an agent is easy. Carrying the context across the gap you just made is the entire job.

P.S. If you want the deepest published look at what a real multi-agent system costs and returns, read Anthropic's engineering write-up on their research system - and pair it with my earlier piece on the agent harness, since the harness is what makes any of these topologies survivable.

Don't miss out on future posts and exclusive content—subscribe to my free newsletter today.

Ready to connect or explore more? Head over to my LinkedIn profile