Multi-Agent Systems Are a Context Decision, Not an Org Chart

TL;DR

Use a skill when the work needs instructions. Use a subagent when the work needs a separate context window. Use MCP when the work needs a tool that lives outside your process. That is the whole decision, and it is a context decision, not a staffing one. Anthropic's published guidance (23 January 2026) is blunt about the cost: "multi-agent implementations typically use 3-10x more tokens than single-agent approaches for equivalent tasks," and teams that built the planner, implementer, tester and reviewer pipeline you have seen in every diagram "spent more tokens on coordination than on actual work." The rule they give instead is context-centric decomposition: group by shared context needs, and never split sequential phases of one feature, because when agents are split by problem type they "engage in a 'telephone game,' passing information back and forth with each handoff degrading fidelity." Three triggers justify a second agent — context protection, genuine parallelism, and specialisation, signalled by 15-20+ tools or accuracy degrading as tools are added. The one role split that reliably works is verification, because a subagent that blackbox-tests the artifact needs almost no context transferred to it.

Should You Use Subagents or Skills in Claude Code?

Answer first, then the reasoning.

Reach for a skill when the model already has the context it needs and is missing instructions, conventions or a procedure. A skill costs you tokens in the window you are already in. No handoff, no fidelity loss, no coordination overhead.

Reach for a subagent when the work would pollute the main context with material the main agent does not need afterwards — a hundred file reads to answer one question, a test run that produces ten thousand lines of output, an exploration that goes down four dead ends. The subagent's window absorbs all of it and returns a paragraph.

Reach for MCP when the capability lives outside your process: a database, an issue tracker, a monitoring system, someone else's API. MCP is a transport for tools, not a unit of work.

The mistake almost everyone makes is reaching for the second one because the task has phases, or because the task has a name that sounds like a job title. Phases are not context boundaries. Job titles are definitely not context boundaries.

Here is the same decision as a table:

The Decomposition Everybody Draws Is the One That Fails

Open any multi-agent post from the last two years and you get the same picture: a planner agent hands to an implementer agent, which hands to a tester agent, which hands to a reviewer agent. Four boxes, three arrows, very clean.

Anthropic's guide on when and how to use multi-agent systems↗ (23 January 2026) says that exact shape is the one that does not work. In those pipelines, Anthropic reports, "the subagents spent more tokens on coordination than on actual work."

The mechanism it names is the important part: when agents are split by problem type, "they engage in a 'telephone game,' passing information back and forth with each handoff degrading fidelity."

Think about what actually crosses an arrow in that diagram. The planner made a decision at step four for a reason it understood. That reason lives in its context window. What crosses the arrow to the implementer is a plan document — the conclusion, not the reasoning. The implementer hits a constraint the planner did not anticipate, makes a judgement call, and writes code. What crosses to the tester is the code, not the judgement call. The tester writes tests against the code as written, which means it tests the bug faithfully. The reviewer sees code and passing tests and approves.

Nothing in that chain is stupid. Every agent behaved reasonably given what it could see. The failure is structural: you split one continuous reasoning process across four windows, and the joins are lossy by construction.

And you paid a premium for it. From the same guidance: "multi-agent implementations typically use 3-10x more tokens than single-agent approaches for equivalent tasks."

Three to ten times the tokens, for a worse result. That is the baseline you have to beat before a second agent earns its place.

Decompose by Context, Not by Role

The replacement rule in that guidance is context-centric decomposition rather than problem-centric decomposition. Two parts to it:

• Group by shared context needs. If two pieces of work need to see the same files, the same history and the same decisions, they belong in one agent even when they have different names.
• Never split sequential phases of one feature. Planning, building and testing one feature are one continuous piece of reasoning. Splitting them is the telephone game.

The practical test I use before adding an agent: write down, in a sentence, exactly what will cross the boundary. Then ask whether the receiving agent could do its job well knowing only that sentence.

• "Here is a plan for the auth refactor." The implementer cannot do its job on that. It will need to know why session storage was chosen, what was rejected, which files were already checked. Do not split.
• "Here is a built artifact and a test suite. Tell me whether it works." The verifier can do its job on exactly that. Split.

The difference is not seniority or specialisation. It is how much of the sender's context the receiver needs. When the answer is "most of it", you are not designing a team, you are designing a bottleneck.

This is the same reasoning I apply inside a single agent's window, one level down — I cover the levers for that in Context Engineering: Why Compaction Is the Wrong First Lever. Multi-agent architecture is that problem again, at a larger grain.

The Three Triggers That Justify a Second Agent

Anthropic's guidance gives three legitimate reasons, and they are all about context, not about work breakdown.

1. Context protection. The work generates material that would flood the main window and is not needed afterwards. A codebase survey, a log trawl, a broad search. The subagent eats the volume and returns the conclusion. This is the most common good reason and the one I use most.

2. Genuine parallelism. The subtasks are truly independent, in the sense that neither needs the other's output or reasoning. Researching five libraries against the same criteria is parallel. Building the frontend and the backend of one feature is not, no matter how it looks on a Gantt chart.

3. Specialisation. Signalled concretely: you are past 15-20 tools, or accuracy degrades measurably when you add another tool. Anthropic's multi-agent guidance puts the attention cost there — "When an agent has 15-20+ tools, the model spends significant context and attention understanding its options" — while the tool search tool docs↗ put the separate accuracy cliff higher, stating that "Claude's ability to pick the right tool degrades once you exceed 30-50 available tools".

Trigger three deserves a caveat, because splitting agents is not the only fix for too many tools, and it is usually the worse one. The same docs describe the cheaper option: a typical five-server MCP setup covering GitHub, Slack, Sentry, Grafana and Splunk "can consume ~55k tokens in definitions before Claude does any work," and tool search "typically reduces this by over 85 percent, loading only the 3-5 tools Claude needs."

So before you split an agent because it has forty tools, defer-load the definitions and see whether the problem was the tool count or the token count. defer_loading: true keeps a definition out of the system-prompt prefix, and discovered tools arrive as tool_reference blocks expanded inline, so your cached prefix survives. Limits worth knowing: 10,000 deferred tools, 5 results returned by default, 200-character regex queries and 500-character BM25 queries.

One agent with tool search beats two agents with a handoff, most of the time.

The One Split That Reliably Works: Verification

There is exactly one role-shaped split in the classic diagram that survives contact with reality, and Anthropic's guidance names it: the verification subagent.

The reason it works is structural, not a matter of prompt quality. Verification needs almost no context transfer. Give a verifier the artifact and the requirement. It does not need the plan, the rejected alternatives, the file reads, or the three dead ends. Its whole job is to look at the thing without knowing how it was made.

That independence is also the point. The building agent knows what it intended, and it grades against its intent. A blackbox verifier grades against the requirement.

The documented failure mode is specific: verifiers declare success after partial testing. They run three of the twelve tests, everything passes, and they report a pass. The documented mitigation is equally specific — an explicit instruction along the lines of "You MUST run the complete test suite."

That is a strange-looking fix and it is worth saying why it works. The verifier has no context telling it how much testing is enough. It cannot infer the bar from a window it does not have. So the bar has to be stated. This generalises: anything a subagent cannot infer from its narrow context must be written into its instructions. That is the entire art of subagent prompting.

Anthropic's harness design post↗ (Anthropic Labs, dated 24 March 2026 on the engineering blog index) reports the same tendency from the other side. In a generator/evaluator setup, "agents tend to respond by confidently praising the work." Left unconstrained, an evaluator is an approval machine. The harness has to make approving expensive.

Skills, Subagents and MCP Are Three Different Primitives

People conflate these constantly, and the confusion produces architectures where a subagent exists to do something a skill would have done for free.

The clean distinction is what each one does to the context window.

A skill adds instructions to the window you are already in. No new window, no handoff, no fidelity loss. If the model has the right context and is behaving wrongly — wrong conventions, wrong order of operations, missing a procedure — this is the fix, and it is much cheaper than any alternative. Reaching for a subagent here is how teams end up paying the 3-10x multiple to solve a prompting problem.

A subagent creates a second window. That is the only thing it fundamentally gives you. Everything else people attribute to subagents — specialisation, focus, discipline — is achievable with instructions in one window. The separate window is the product. Which means: if you do not want a separate window, you do not want a subagent.

An MCP server exposes tools that live outside your process. It has nothing to do with decomposition. An MCP server is a transport. Its cost model is definition tokens on every request and the tool-selection degradation that comes with a crowded tool list. The July 2026 stateless revision changed how those servers should be built — I go through the migration in MCP Went Stateless: Migrating Your Server, and the fundamentals are in MCP servers and standard tool integration.

There is a fourth thing worth putting in the same sentence, because it solves a problem people reach for subagents to solve: programmatic tool calling. Instead of one tool call per turn with the result landing in context, the model writes code that orchestrates several calls, and the intermediate results never enter the window. Anthropic's documentation↗ reports a roughly 38% reduction in billed input tokens on a 75-tool project-management agent benchmark with no change in task accuracy, and typical savings of 20% to 40% across production traffic where the tools array holds 10 to 49 definitions.

It also publishes the null result, which is the part I trust it for: on tau-squared-bench, where each turn makes one or two sequential tool calls, it "left scores unchanged and cost roughly 8% more." A fan-out workload benefits. A sequential one does not.

One security note that applies directly to multi-agent designs: Anthropic's own docs state that allowed_callers "is not a hard API-level block on direct invocation... Do not rely on allowed_callers as a security boundary." If your architecture assumes a subagent cannot reach a tool, that assumption has to be enforced in the tool handler, not in the tool definition.

The Orchestrator-Subagent Pattern, and What It Costs

When a second agent is justified, the shape that works is one orchestrator holding the task and the plan, dispatching narrow, self-contained jobs to subagents that return short results.

Properties that make it work:

• The orchestrator never leaves the loop. It holds continuity. Subagents are stateless from its point of view — they get a brief, they return a result.
• Briefs are complete. A subagent cannot ask a clarifying question cheaply, and it cannot infer the bar. State it.
• Returns are small. If a subagent returns 20,000 tokens into the orchestrator's window, you have moved the context problem rather than solved it.
• No subagent talks to another subagent. Every extra hop is another handoff, and handoffs are where fidelity dies.

Anthropic's Managed Agents↗ architecture (8 April 2026) is the industrial version of this. The session becomes a durable, queryable log that lives outside the context window; the harness fetches event slices with getEvents(), and execution environments are called through a stateless execute(name, input) -> string interface. Decoupling the brain from the hands cut p50 time-to-first-token by about 60% and p95 by more than 90%, because containers are only provisioned when they are needed.

Now the bill, because orchestration has a cost line that single-agent designs do not.

Managed Agents charge a session-runtime SKU↗ at $0.08 per session-hour on top of tokens, accruing only while a session's status is running — idle, rescheduling and terminated time is free. The Batch API discount does not apply to it. Anthropic's worked example: a one-hour Opus 5 coding session with 50,000 input and 15,000 output tokens comes to $0.25 + $0.375 + $0.08 = $0.705, falling to $0.525 when 40,000 of that input arrives as cache reads.

Per session-hour that is small. Across a fleet of orchestrators each spawning several long-lived subagent sessions, it is a line item you should model before you fan out. Code execution is billed separately only outside a Managed Agents session — inside one, session runtime replaces container-hour billing and you are not charged twice. Outside one, it is free when used alongside web search or web fetch, otherwise 1,550 free container-hours per organisation per month, then $0.05 per hour per container with a five-minute minimum. Web search is $10 per 1,000 searches.

Tokens are still the dominant term, and how they convert into cost is its own subject — I work through it in Tokens Per Task: The Real AI Cost Model in 2026, along with the tokenizer change that makes cross-model price comparisons misleading. For the broader integration budget, the real cost of AI integration covers the parts that are not inference.

When One Agent Is Correct

Most of the time.

The token multiple is the first argument: 3-10x for equivalent work. The fidelity argument is the second. But there is a measurement argument too, and it is the one that changes minds in review meetings.

Terminal-Bench 4.0's maintainers published a token figure alongside their leaderboard that is more informative than the scores: Sonnet 5 consumed 21.6B tokens on its leaderboard run against 6.5B for Opus 5. On an aggregated board of the same benchmark (last updated 11 September 2026), Sonnet 5 under Claude Code scored 12.42% against Opus 5's 51.82% — aggregator figures, not the canonical leaderboard. The cheaper model burned 3.3x the tokens to do substantially worse — though the maintainers also recorded Sonnet 5 hitting timeouts and output-token-exceeded errors on that run, so part of the score gap is harness limit rather than model quality.

Even with that caveat, the lesson transfers. Token consumption is not a proxy for effort, and it is not a proxy for quality. A system that consumes more tokens is frequently a system that is thrashing. When a multi-agent pipeline uses five times the tokens of the single agent it replaced, that is evidence to investigate, not a badge.

Anthropic's harness post gives the single-versus-harness comparison in money. A retro game maker built by one agent with no harness took 20 minutes and $9 and produced broken gameplay. The same brief through the full generator/evaluator harness took 6 hours and $200 and shipped working mechanics. A DAW built under the post-sprint harness broke down as: planner 4.7 minutes and $0.46, build roughly 3 hours 20 minutes and about $114, QA about 25 minutes and about $10, for a total of 3 hours 50 minutes and $124.70.

Read that honestly in both directions. The harness was 22x the cost and it was worth it, because the cheap run produced something broken. But note what the harness is in that example: a generator and an evaluator, plus a planning step. It is not four role-shaped boxes. The structure that earned the 22x was verification, which is the split that works.

One more thing about where the ceiling sits. Delegation works where the work is easily verifiable or low-stakes. Conceptually difficult, design-dependent work stays with the human. That is the same boundary the verification-subagent result describes, seen from the other end, and it is the boundary I would draw before adding a second agent to anything.

Harness Complexity Should Shrink as Models Improve

This is the part almost nobody designs for, and it is the most useful idea in Anthropic's harness post:

Every component in a harness encodes an assumption about what the model can't do on its own, and those assumptions are worth stress testing.

Assumptions expire. When Anthropic moved from Opus 4.5 to Opus 4.6, they removed the sprint decomposition that Opus 4.5 had needed. The scaffolding was load-bearing and then it was not.

So your orchestration layer has a shelf life, and you should be able to state what each box is compensating for. If you cannot name the model weakness a component addresses, you cannot tell when it becomes dead weight. Two habits that follow:

1. Write the assumption next to the component. "Splitting the plan from the build because the model loses the requirements past 40 tool calls." Now it is falsifiable.
2. Re-test the assumption on every model upgrade. Run the pipeline with the component removed. If quality holds, delete it — and the cost drops by more than the component, because you also drop a handoff.

The general shape of agent architecture, and the patterns that predate this guidance, are in multi-agent systems architecture. The point of this article is narrower: the boxes should follow context boundaries, and they should be deleted as soon as the model stops needing them.

How to Tell If Your Multi-Agent System Is Working

None of the above is worth anything without measurement, and Anthropic's eval guidance↗ (9 January 2026) has the most practical starting point I have seen: "20-50 simple tasks drawn from real failures is a great start," because early-stage effect sizes are large enough that a small set separates architectures.

The distinction that matters most for an agent pipeline is pass@k versus pass^k:

• pass@k is the probability that at least one of k attempts succeeds. The right metric for a one-shot tool a developer runs and retries.
• pass^k is the probability that all k trials succeed. The right metric for anything customer-facing.

These diverge sharply as k grows, and multi-agent systems flatter themselves on pass@k. More agents means more chances for one path to produce a good answer. Under pass^k, every handoff is another place the chain breaks on any given run, and the 3-10x token multiple stops looking like an investment.

The rest of that guidance applies cleanly here:

• Grade outputs, not process paths. Rigid step-sequencing rubrics punish an agent for solving the problem a different way.
• Give LLM judges an explicit "Unknown" option, so uncertainty does not get rounded into a pass.
• Use structured rubrics that score isolated dimensions rather than one overall number.
• Read transcripts regularly, to validate the grader as well as the agent.
• Watch for eval saturation. A suite everything passes has stopped measuring.

One related question worth holding before you trust any agent eval, which I could not settle against a primary source: whether models behave differently when they detect they are being evaluated. If they do, and if your eval harness looks obviously like an eval harness, you are measuring a slightly different system than the one you ship. The wider problem of harness effects on scores is the subject of Your Agent Benchmark Number Is Mostly Your Harness.

Key Takeaways

• Skills, subagents and MCP are separated by what they do to the context window — instructions in the current window, a second window, and tools outside the process. Pick by which one you actually need.
• Multi-agent implementations typically use 3-10x more tokens than single-agent approaches for equivalent tasks, and teams building role-based pipelines "spent more tokens on coordination than on actual work" (Anthropic, 23 January 2026).
• Never split sequential phases of one feature. Each handoff is a telephone game that degrades fidelity, because the conclusion crosses the boundary and the reasoning does not.
• Three triggers justify a second agent: context protection, genuine parallelism, and specialisation signalled by 15-20+ tools or measurable degradation as tools are added.
• Verification is the split that reliably works, because it needs almost no context transfer — with a documented failure mode (declaring success after partial testing) and a documented mitigation (an explicit instruction to run the complete suite).
• Try tool search before splitting on tool count. A five-server MCP setup can burn around 55,000 tokens in definitions before any work happens, and tool search cuts that by over 85%.
• Measure with pass^k, not pass@k, for anything customer-facing, and start with 20-50 tasks drawn from real failures.
• Every harness component encodes an assumption about what the model cannot do. Write the assumption down and re-test it on every model upgrade, because Anthropic deleted their own sprint decomposition when the move from Opus 4.5 to Opus 4.6 made it unnecessary.

About the Author

I'm Uvin Vindula — a Web3 and AI engineer based between Sri Lanka and the UK. I build agent systems in production and spend most design reviews arguing boxes out of diagrams rather than into them. You can see my work at iamuvin.com or reach out about a project at hello@iamuvin.com↗.

If your agent pipeline costs more than the single agent it replaced and is not measurably better, let's talk about your project.