Single Agent vs Multi-Agent: When Subagents Pay Off (2026)

When one agent loop beats a team of subagents, when it does not, and how to tell the difference before you pay for it

On October 22, 2026, Anthropic told enterprises to fold most of their subagents back into a single agent loop, after one customer found the single loop ran roughly 2x faster than its multi-agent harness. - Anthropic

Six days earlier, OpenAI went the other way in its flagship consumer product: GPT-6 Pro in ChatGPT gained "multiple agents that can work on different parts of a task in parallel," with each agent's progress visible in the conversation - OpenAI release notes. The same month, Anthropic handed the Agent Skills standard, the format that makes the single-loop approach work, to the Agentic AI Foundation, reporting more than 70 agent platforms that already support it - Anthropic. So in one week, the two largest AI labs appeared to recommend opposite architectures.

The problem is that most teams pick an architecture by analogy ("a team of specialists sounds smarter") instead of by the mechanics of context, tokens and verification. The result is the pattern Anthropic's Applied AI team now sees across enterprise deployments: a router, a planner and a dozen domain subagents that mirror the company's org chart, lose details at every handoff, cost several times more per task, and still score worse than one well-equipped agent. Meanwhile, the cases where subagents genuinely pay off (wide research, clean-context review, parallel builds with a near-perfect test suite) get lost in the backlash.

This guide breaks down what single-agent and multi-agent systems actually are in late 2026, what the research says when compute is held constant, the exact conditions under which subagents pay off, the cost math on current model prices, how to fold an over-engineered system back into one loop, and how to design the multi-agent systems that are worth building. It is written for decision-makers as much as for engineers: you do not need to write code to use the decision framework, but the code is here when you do.

Contents

1. What Single-Agent and Multi-Agent Mean in 2026
2. Why the Pendulum Swung Back in October 2026
3. First Principles: Context Is the Scarce Resource
4. What the Research Says When Compute Is Held Constant
5. When Subagents Pay Off: Six Conditions
6. When Subagents Cost You: The Failure Modes
7. The Cost Math on Current Model Prices
8. How to Build a Strong Single-Agent Loop
9. How to Fold Subagents Back Into One Loop
10. Designing Multi-Agent Systems That Actually Ship
11. Platforms and Frameworks: Who Does What
12. Use Cases: Where Each Architecture Wins
13. Future Outlook: Where Agent Architecture Goes Next
14. Conclusion: A Decision Framework

The Architecture Scorecard: 8 Patterns Ranked

Before the detail, here is the whole argument in one table. It scores the eight architecture patterns that teams actually deploy today, from a single agent loop with on-demand skills to a fully decentralized swarm, on the criteria that decide whether an architecture earns its keep on a typical business task. The scores are built from the published evidence cited throughout this guide: Anthropic's enterprise comparisons, Google Research's 180-configuration study, Berkeley's analysis of 1,642 failed multi-agent traces, and the production reports from Cognition, Cursor and Anthropic's own engineering team.

Read the ranking as a default, not a verdict. A pattern near the bottom can still be the right choice for a specific job: an orchestrator with parallel research subagents scores a 9 on quality for breadth-first research, and it sits mid-table only because it costs several times more per task. The table tells you where to start. The rest of the guide tells you when the evidence justifies moving down the list.

How the criteria were chosen. Quality carries the most weight (30%) because a cheaper architecture that produces worse answers is not cheaper once you count rework. Cost per task (25%) matters because multi-agent token multipliers of 3-15x are the single largest line item in agent budgets. Reliability (20%) measures how errors propagate and how hard failures are to trace, which is where the Berkeley and Google data are most damning for loosely coordinated systems. Speed (10%) is wall-clock time for the user, which is where parallel subagents genuinely shine. Build and upkeep (15%) captures the human cost: who owns the system prompt, how many evals must be maintained, and how quickly the system rots as models improve.

The pattern of the scores matters more than any single number. The top three patterns share one property: one agent owns every write, and any extra model contributes intelligence (a review, an opinion) rather than actions. The bottom three share the opposite property: several agents act, and coordination is left to messages, routers or luck. That single distinction, which Cognition summarized in April 2026 as "writes stay single-threaded," explains most of what follows.

1. What Single-Agent and Multi-Agent Mean in 2026

The vocabulary in this field has drifted so much that two engineers can argue for an hour about "multi-agent" while describing the same system. A precise definition is the first defense against over-engineering. An agent is a model running in a loop: it reads its context, decides on an action (usually a tool call), observes the result, and repeats until it answers or hits a budget. A single-agent system has one such loop with one context window, however many tools it has. A multi-agent system has more than one loop, each with its own context window, exchanging information through messages, summaries or shared files.

The important word is context window, not "agent" or "persona." A system with one loop that loads a "legal skill" and later a "finance skill" is still a single agent, because everything it learns stays in one context. A system where a lead agent hands a question to a "legal subagent" that reads 40 documents in a fresh context and returns a two-paragraph summary is a multi-agent system, because 40 documents of information were compressed into two paragraphs on the way back. That compression is the source of both the main benefit and the main cost of every multi-agent design.

The terms that matter

Several terms recur in every vendor's documentation, and they are worth pinning down because each one implies a different trade-off. A subagent is a separate agent instance that a main agent spawns for a focused subtask; Anthropic's Agent SDK documentation describes the key property plainly: intermediate tool calls and results stay inside the subagent, and "only its final message returns to the parent" - Claude Agent SDK docs. An orchestrator (or lead agent) is the agent that plans the work and spawns the subagents. A handoff transfers control of the conversation from one agent to another, so the specialist takes over the user-facing exchange, while agents-as-tools keeps the original agent in charge and calls the specialist like a function.

Two newer terms complete the picture. A skill is a folder of instructions, scripts and reference files that an agent loads only when a task needs it, which lets one agent carry hundreds of specialties without carrying their text in every prompt. Tool search applies the same idea to tools: the agent sees a search tool and a handful of core tools, and discovers the rest on demand. OpenAI's Agents SDK documents the agents-as-tools versus handoffs distinction explicitly, recommending agents-as-tools when "a specialist should help with a bounded subtask" without taking over the conversation - OpenAI Agents SDK.

• Single loop: one context window, tools and skills loaded on demand
• Subagent: a fresh context for a side task, returns a summary
• Agent team: persistent parallel agents that message each other
• Handoff: control of the conversation moves to a specialist
• Agents-as-tools: the main agent keeps control and calls specialists

These definitions turn an ideological debate into an engineering one. Once you see that every multi-agent pattern is a way of splitting context, the question stops being "is a team smarter than an individual?" and becomes "is the information I lose at each split worth the context I free up and the time I save?" A subagent that reads 50,000 tokens of search results and returns 500 tokens of findings is a good trade if the parent never needed the other 49,500. A subagent that writes the tests for a feature it never saw being designed is a bad trade, because the reasons behind the implementation were the very thing it needed.

One variant blurs the line usefully. Claude Code and the Agent SDK support a fork: a subagent that inherits the parent conversation instead of starting fresh, while everything it then reads and does stays in its own context and only its final message returns - Claude Agent SDK docs. A fork removes the handoff loss on the way out, because the subagent already knows everything the parent knew, but it gives up the clean context that makes an independent reviewer valuable. That makes forks a good fit for parallel exploration of options the parent has already framed, and a poor fit for verification, where the point is a judgment that is not anchored on the author's reasoning.

The spectrum, not the binary

In practice, real systems sit on a spectrum rather than on one side of a binary. At one end is a single prompt with no loop at all. Next comes the single agent loop, then the single loop with progressive disclosure (skills and tool search), then a single writer helped by read-only assistants such as a verifier or an advisor, then an orchestrator with parallel workers, then persistent agent teams, and finally decentralized swarms where no agent is in charge. Each step to the right buys parallelism and isolation and pays for it in tokens, coordination and lost context.

One more distinction sits underneath the spectrum: an agent is not always the right unit at all. Microsoft's Agent Framework documentation separates agents (for open-ended or conversational tasks that need autonomous tool use and planning) from workflows (for processes with well-defined steps where you need explicit control over execution order), and adds a rule that saves a surprising amount of money: "If you can write a function to handle the task, do that instead of using an AI agent" - Microsoft Learn. Many systems described as multi-agent are really workflows with a model call at each step, and they are easier to test and cheaper to run when they are built and named as such.

The diagram below lays out that spectrum. The dashed boundary marks the line that matters most in 2026: to its left, one agent owns every action and other models only contribute intelligence; to its right, several agents take actions, and the system has to reconcile them. Anthropic's October guidance, Cognition's April report and Google's scaling study all converge on the same advice, phrased differently: start at the left, and move right only when a measured limit forces you to.

The practical takeaway is that "single agent vs multi-agent" is rarely an all-or-nothing choice. The strongest production systems in late 2026 are mostly single loops with one or two carefully chosen multi-agent elements bolted on where they pay: a clean-context reviewer before a pull request merges, a research fan-out for one expensive question, a cheap executor that can call a frontier advisor. Knowing which element to add, and when, is the skill this guide is about. If you are new to the underlying loop itself, our guide to AI agent harnesses explains why the same model can swing by 20 points depending on the harness around it.

2. Why the Pendulum Swung Back in October 2026

The October 2026 guidance did not come out of nowhere. Multi-agent systems had a strong run from mid-2025, when Anthropic published how its Research feature used an orchestrator with parallel subagents and outperformed a single agent by 90.2% on an internal research evaluation - Anthropic Engineering. That post became the reference design for a generation of enterprise agents. Teams copied the shape (a planner, a router, a set of specialists) without copying the conditions that made it work: a breadth-first research task, a strong orchestrator, and a willingness to spend about 15 times the tokens of a chat.

By late 2026, two things had changed. Models had become capable enough to manage far more inside one loop, and the tooling for loading context on demand had matured. Anthropic's October article states the model shift directly: "starting with Opus 4.5, models became capable of managing far more in a single loop than most teams expected," and newer models "increasingly narrate their progress and check their work as they go, which makes some harness elements redundant" - Anthropic. The structure teams had built to compensate for weaker models was now doing work the model no longer needed done for it.

What Anthropic actually recommended

The guidance, written by Diane Sarkis and drawn from the Applied AI team's enterprise work, makes a specific and testable claim. Across several deployments, "a single agent with skills frequently outperformed both the one-prompt-for-everything design and the subagent design" on quality, and often did so at lower cost and latency per task. An earlier Anthropic piece on commerce agents, published on September 2, 2026, reported the same comparison across several enterprise deployments and noted that subagents still suit narrow, self-contained tasks that need their own context window, such as deep research - Anthropic.

The article is equally specific about when to keep subagents. It lists three conditions: when "a single agent loop hits measurable performance degradation from context bloat," when multiple tasks "need to be tackled in parallel with fresh context windows that can be discarded once the task is done," and when "a single agent struggles to select appropriate tools or there are conflicting instructions in the system prompt." Anthropic also released a companion migration kit on GitHub that audits each subagent and proposes one of four verdicts (fold, merge, call as a tool, or keep), with the explicit caveat that "the kit does not assume a single loop always wins. It measures" - GitHub: anthropics/single-agent-loop-kit.

The image below, taken from Anthropic's article, shows the three moves the guidance recommends for an existing multi-agent system. Merging combines subagents that share context so there are fewer of them. Calling them as tools keeps the main agent in the conversation and turns each subagent into a function with a structured result. Folding turns a subagent's prompt into a skill and its API calls into tools, so the specialist disappears as a separate agent entirely.

Notice the order of the three panels. Folding is the destination, but the guidance treats it as the last step after merging and tool-calling, and each step is gated on an eval. That sequencing is what separates this advice from a fashion swing: it does not say "delete your subagents," it says "prove each one earns its context, and fold the ones that do not." We return to the exact migration procedure in Section 9.

What OpenAI shipped the same week

OpenAI's October 16 update to GPT-6 Pro in ChatGPT looks, at first glance, like the opposite bet. The release note lists faster responses, improved use of plugins and tools, and "multiple agents that can work on different parts of a task in parallel," rolling out to eligible Pro users - OpenAI release notes. OpenAI has not published how many agents run at once, which model powers them, or how parallel runs count against usage limits, so independent assessment is still thin.

The two moves are less contradictory than they appear. Anthropic's guidance targets enterprise agents that answer customers and run business processes, where most tasks are sequential and share state. OpenAI's parallel agents sit inside a premium reasoning product used for long, research-heavy questions, which is precisely the breadth-first, parallelizable workload where Anthropic itself says subagents pay off. Both labs are converging on the same rule from different product positions: parallelize independent reading, serialize dependent decisions. For a closer look at how OpenAI's always-on agents and Anthropic's Duet compare as products, see our personal AI agent comparison.

The skills standard went neutral

The third October event is the one with the longest tail. On October 22, Anthropic donated Agent Skills (the specification, the name and logo, the GitHub organization and the agentskills.io domain) to the Agentic AI Foundation under the Linux Foundation, reporting that 1 million skills have been published and nearly 280 million installed - Anthropic. Engineers from Anthropic, Google, OpenAI and others now maintain the standard, with David Soria Parra and Mahesh Murag as lead maintainers.

This matters for the architecture debate because skills are the mechanism that removes the main historical reason for subagents. Teams split agents because one prompt could not hold every specialty without bloating. A portable skill format means a single agent can carry hundreds of specialties and load each only when needed, across vendors. OpenAI's own guidance for GPT-6 Astra points the same direction, recommending short skill descriptions, a lean root document that points to supporting files, and warning that "overly specific guidance can now hinder results where it previously helped" - OpenAI Developers. We ranked the most useful skills in our 2026 agent skills guide.

Cognition's reversal, ten months earlier

The industry's most cited skeptic had already moved. In June 2025, Cognition's Walden Yan published "Don't Build Multi-Agents," arguing that parallel agents make conflicting implicit decisions - Cognition. In April 2026 he followed up: Cognition now runs multi-agent systems in production, but only "a narrower class of patterns" where "multiple agents contribute intelligence to a task while writes stay single-threaded" - Cognition. The same post reports that Devin usage in Cognition's largest enterprise segment grew roughly 8x over six months, which pushed teams toward more agents and, at the same time, toward controlling the cost of running them.

Read together, the October guidance and the April reversal describe one consensus forming from two directions. The single-agent camp now accepts verifiers, advisors and read-only research workers. The multi-agent camp now rejects unstructured swarms and parallel writers. The video below, from developer educator Ray Amjad, walks through Anthropic's October guidance and what it changes for people building with Claude Code; it is the most-watched independent breakdown of the article so far.

The video is useful mainly for seeing the guidance applied to a real Claude Code setup, including which subagents survive the audit. The structural point to carry forward is that both labs and both camps now agree on what makes multi-agent work fail: splitting a task by job title instead of by context. The next section explains why, from first principles.

3. First Principles: Context Is the Scarce Resource

Strip away the vendor vocabulary and an agent architecture is an answer to one question: where does each piece of information live, and how much of it can each model attend to at once? A model makes decisions from what is in its context window. Everything else, including what another agent learned five minutes ago, does not exist for it. So the economics of agent architecture are the economics of context: what it costs to fill, what it costs to move, and what happens to decision quality as it grows.

Three facts drive everything. First, model performance degrades as context grows, even on simple tasks. Chroma's 2025 study of 18 models found that reliability declines as inputs get longer, a phenomenon it named context rot - Chroma Research. Second, moving information between agents is lossy: a subagent's summary is a compression of everything it saw, and compression throws away whatever the summarizer judged irrelevant. Third, tokens are performance. In Anthropic's analysis of its research agent on BrowseComp, token usage alone explained 80% of the variance in performance, and three factors (tokens, number of tool calls and model choice) explained 95% - Anthropic Engineering.

Why multi-agent systems win when they win

Put those three facts together and the case for subagents becomes precise. A multi-agent system is a way to spend more tokens in parallel without polluting any single context. If a question needs 2 million tokens of reading, no single context can hold it well, but ten subagents with 200,000 tokens each can read it in parallel and hand the lead agent a few thousand tokens of distilled findings. When the reading is genuinely independent (ten companies to research, ten files to audit), the compression loses little that matters, and the parallelism saves wall-clock time.

This is why Anthropic's research agent beat a single agent by 90.2%: the lead agent could direct far more total reading than any one context could hold, and each subagent read its slice with a clean, focused context. It is also why the same post warned that the approach is a poor fit for "some domains that require all agents to share the same context," naming coding as an example with fewer truly parallelizable tasks - Anthropic Engineering. The win comes from parallel token spend on separable reading, not from any magic in having several agents.

Why single agents win when they win

The counterpart argument is information-theoretic, and an April 2026 paper made it formal. Dat Tran and Douwe Kiela compared single-agent and multi-agent systems on multi-hop reasoning while holding reasoning tokens constant, and found that single agents "consistently match or outperform" multi-agent systems under equal budgets - arXiv 2604.02460. Their explanation rests on the data processing inequality: each processing step can only preserve or lose information, never create it, so a pipeline of agents passing summaries cannot know more than one agent that saw everything. They predict multi-agent systems become competitive only when a single agent's use of its context degrades, or when more total compute is spent.

That prediction is the hinge of the whole debate. Much of the historical evidence for multi-agent superiority compared a multi-agent system that spent several times more compute against a single agent on a smaller budget. Tran and Kiela also flag artifacts in how some APIs control thinking budgets that can inflate apparent multi-agent gains. Once you equalize the spend, the advantage shrinks to the cases where one context genuinely cannot hold the work, which is exactly the "context bloat" condition in Anthropic's October guidance.

The arithmetic of handoffs

A simple model shows why splitting a task by job title is so costly. Suppose each handoff preserves 90% of the information the next agent needs, a generous assumption for a summary. A router, a planner, a specialist and a reviewer form a chain of three handoffs, so the last agent works with about 0.9 × 0.9 × 0.9 = 73% of the relevant information. Every decision made on the missing 27% is a potential error, and in a multi-agent system errors propagate: Google's study measured that independent agents amplified errors 17.2x through unchecked propagation, while centralized coordination contained this to 4.4x - arXiv 2512.08296.

A single agent with skills avoids the chain entirely. Anthropic's guidance puts it simply: "An agent that has seen the result of each earlier step can connect them." The cost is that its context grows, which is why the mechanisms that keep a single context lean (skills that load on demand, tool search, compaction) are what made the October recommendation possible. A single agent without those mechanisms is the "one-prompt-for-everything" design that lost to both alternatives in Anthropic's comparisons.

The chart below makes the efficiency gap concrete. Google Research matched every architecture to a mean of about 4,800 reasoning tokens per trial and counted successful task completions per thousand tokens. The single agent produced roughly three times more successes per token than a centralized orchestrator and five times more than a hybrid design.

The same table in the paper shows why: a single agent averaged 7.2 turns per task, while a centralized system needed 27.7 turns and a hybrid 44.3, with coordination overhead of 285% and 515% respectively. Those turns are tokens spent on talking about the work rather than doing it. The first-principles conclusion is therefore not "single agents are better." It is that multi-agent systems are a way to buy parallel context, and you should only pay that price when one context genuinely cannot hold the work or when wall-clock time is worth more than the tokens. Everything else in this guide is an application of that rule. For techniques that keep one context lean, our guide to context engineering goes deeper.

4. What the Research Says When Compute Is Held Constant

The research literature on single-agent versus multi-agent systems grew up fast between late 2025 and late 2026, and its main contribution was methodological: it started holding compute constant. Earlier comparisons often pitted a multi-agent system that spent many times the tokens against a single agent on a smaller budget, then credited the gap to the architecture. The newer studies equalize the spend and vary the structure, which is the only way to learn what the structure itself contributes.

Four bodies of evidence now carry most of the weight: Google Research's controlled scaling study, the Tran and Kiela equal-budget paper discussed above, UC Berkeley's taxonomy of how multi-agent systems fail in practice, and the production reports from Anthropic, Cognition and Cursor. They disagree on details, but they agree on the shape: multi-agent structure helps on parallelizable, breadth-heavy tasks with a strong coordinator, and hurts on sequential tasks, tool-heavy tasks and tasks a single agent already does reasonably well.

Google's 180-configuration study

The most rigorous evidence comes from "Towards a Science of Scaling Agent Systems," a study by researchers at Google Research, Google DeepMind and MIT that evaluated five architectures (a single agent plus independent, centralized, decentralized and hybrid multi-agent variants) across 180 configurations and four benchmarks - Google Research. On Finance-Agent, a parallelizable financial analysis benchmark, centralized coordination improved performance by 80.9% over a single agent. On PlanCraft, a strictly sequential planning task, every multi-agent variant degraded performance, by 39% to 70%.

The paper adds two findings that matter for anyone deciding today. First, returns become diminishing or negative once a single-agent baseline passes roughly 45% success, a pattern the authors call capability saturation: if one agent already solves the task reasonably well, adding agents mostly adds overhead. Second, tool-heavy tasks bear a disproportionate multi-agent overhead, because every agent needs its own copy of the tool definitions and its own turns to use them - arXiv 2512.08296. A model built on task properties such as tool count and decomposability predicted the best architecture for 87% of held-out configurations, which means architecture choice is largely predictable from the task, not a matter of taste.

The figure below, from the Google Research post, shows the per-benchmark results. Grey is the single agent; the colored boxes are the four multi-agent variants, with the percentage change versus the single agent printed above each one.

The pattern is unmistakable once you read across the four panels. Finance Agent, where sub-questions such as revenue trends and cost structure can be researched independently, rewards every multi-agent variant (+57% to +81%). PlanCraft, where each step depends on the last, punishes every one of them (-39% to -70%). BrowseComp-Plus and Workbench sit in between, with the independent variant (agents working in parallel with no coordinator checking their work) losing 35% and 11% respectively. The lesson is not that one architecture is best; it is that task structure predicts the winner, and most business tasks look more like PlanCraft than like Finance Agent.

How multi-agent systems fail in practice

The second body of evidence explains why. UC Berkeley researchers annotated 1,642 execution traces from seven multi-agent frameworks and built MAST, a taxonomy of 14 failure modes in three categories - arXiv 2503.13657. System design issues account for roughly 44% of failures, inter-agent misalignment for about 32%, and task verification for about 24%. Crucially, the most common failures are not the model being "dumb." They are agents repeating steps, ignoring when to stop, disobeying the task specification, and acting differently from what they reasoned.

The chart below shows the five most frequent individual failure modes. Step repetition alone accounts for 15.7% of failures, and not knowing the termination conditions for 12.4%: both are coordination problems that a single loop with a turn budget largely avoids.

The Berkeley authors conjecture that improvements in base model capabilities "will be insufficient to address the full MAST," because the failures are organizational rather than cognitive. Their intervention experiments support that view: in ChatDev, adding a high-level verification step raised task success on one benchmark by 15.6%, more than any prompt change. That result points at the multi-agent pattern that does work reliably, a dedicated verifier, which we return to in Section 5.

Error amplification and the coordinator effect

Google's study also quantified how errors spread. When agents work independently and their outputs are simply combined, a mistake by one agent flows straight into the final answer, and the study measured error amplification of 17.2x for that design. Adding a central orchestrator that checks worker outputs before combining them cut amplification to 4.4x. Decentralized peer-to-peer designs landed at 7.8x and hybrids at 5.1x - arXiv 2512.08296.

Two practical rules follow. If you build a multi-agent system at all, put one agent in charge of checking and combining, because a coordinator is the single largest reliability lever in the data. And treat "more agents for robustness" with suspicion: unless something is actively checking their outputs, more agents means more independent chances to be wrong, and those errors compound rather than cancel. The Google results are consistent with Anthropic's January 2026 guidance that multi-agent implementations "typically use 3-10x more tokens than single-agent approaches for equivalent tasks" - Anthropic, which is a lot to pay for a structure that can also multiply mistakes.

What production teams report

Lab studies use benchmarks; production teams see the long tail. Three 2026 reports are especially informative because they come from teams that run agents at scale and changed their minds publicly. Cognition reports that its clean-context review agent, Devin Review, catches an average of 2 bugs per pull request even on code Devin wrote, with roughly 58% of them severe - Cognition. Cursor reports that hundreds of concurrent agents wrote a web browser of over 1 million lines across about 1,000 files in close to a week, but only after flat coordination failed - Cursor. Anthropic reports that 16 parallel Claude agents wrote a 100,000-line C compiler that builds Linux 6.9 - Anthropic Engineering.

All three successes share preconditions that typical business tasks lack. Devin Review works because a diff is a small, self-contained artifact a fresh reviewer can judge. Cursor's and Anthropic's builds work because they had a large, verifiable target (compile the kernel, pass the test suite, render the page), and because the teams invested heavily in the harness. Anthropic's compiler author is blunt about the dependency: "It's important that the task verifier is nearly perfect." When those preconditions are absent, the same teams' own experience points back toward a single writer.

5. When Subagents Pay Off: Six Conditions

With the evidence laid out, the question in the title has a concrete answer. Subagents pay off when they buy something a single loop cannot get cheaply: a clean context, parallel wall-clock time, an independent judgment, a different model's strength, a tighter permission boundary, or the capacity to work on something far larger than one context. Each of those is a specific mechanism with a specific signal that tells you it applies.

The six conditions below are not a menu to pick from; they are tests. If none of them holds for your task, a single loop with skills is very likely the better design, and the burden of proof sits with whoever wants the extra agents. If one holds, add the smallest multi-agent element that addresses it, measure, and stop there. The image below, from Anthropic's October article, captures the governing principle: split work by context, not by problem type.

The top half of the image is the most common mistake in enterprise agent design: a feature agent, a test agent and a review agent, each handing off to the next, with the test writer never learning why the implementation looks the way it does. The bottom half is the fix: one agent writes the feature and its tests because it already has the context, and a verifier that only needs to run the tests and report results sits outside that context, where its independence is an asset rather than a handicap.

Condition 1: Exploration reads far more than the result needs

The cleanest case for a subagent is a side task that reads a large amount of material and returns a small result. Searching a codebase, scanning logs, reviewing a long document set or browsing dozens of web pages all fit this shape. Claude Code's documentation describes exactly this trigger: use a subagent "when a side task would flood your main conversation with search results, logs, or file contents you won't reference again" - Claude Code docs. The built-in Explore subagent is read-only by design, so it can wander through files without the risk of changing them.

Anthropic's January 2026 guidance gives numbers for when the trade is worth it. Context isolation is most effective when subtasks generate more than 1,000 tokens of mostly irrelevant information, and one worked example reduces a 2,000-plus-token order history to a summary of about 50 to 100 tokens - Anthropic. The signal to watch is the ratio of tokens read to tokens kept: when it runs into the dozens or hundreds, a subagent pays for itself in a cleaner parent context. When the parent will need most of what was read, a subagent just adds a lossy summary step.

Condition 2: Independent parallel breadth where time matters

The second case is breadth-first work whose parts do not depend on each other, such as researching ten competitors, auditing ten services, or checking a claim against twenty sources. Here subagents buy wall-clock time. The Agent SDK documentation explains the mechanism: independent subtasks "finish in the time of the slowest one rather than the sum of all of them" - Claude Agent SDK docs. Anthropic's research system, which combined parallel subagents with parallel tool calls, cut research time by up to 90% for complex queries.

The test is twofold. The parts must be genuinely independent, meaning no part needs another part's intermediate findings to proceed. And the time saved must be worth roughly 3 to 15 times the tokens. For a user waiting on a due-diligence memo or a sales team that needs account research before a call, the answer is often yes. For an overnight batch job that nobody watches, it usually is not: run the same reading sequentially in one agent with compaction and pay a fraction of the price. Google's Finance-Agent result (+80.9% with a coordinator) is the best evidence that genuinely parallelizable analysis rewards this pattern.

Condition 3: You need a judgment that is not anchored on the author's

The third case is verification. A model reviewing its own work in the same context tends to agree with itself, because the reasoning that produced the work is still in front of it. A separate agent with a clean context, given only the artifact and the criteria, judges it fresh. Cognition found that its review loop works best "when the coding and review agents do not share any context beforehand," partly because a clean context "makes the agent smarter because of the math of attention" - Cognition. Anthropic's coordination-patterns guide names generator-verifier as one of five core patterns and warns that "the verifier is only as good as its criteria" - Anthropic.

The design details decide whether a verifier helps or just rubber-stamps. Anthropic's January guidance describes the "early victory problem," where a verifier runs one or two tests and declares success, and recommends concrete criteria such as "Run the full test suite and report all failures" rather than "make sure it works." The Berkeley data shows why this matters: incorrect verification is the fifth most common multi-agent failure mode on its own. A verifier with explicit, checkable criteria and a cap on retry loops is the multi-agent element with the best evidence behind it, which is why it ranks second in our scorecard.

Condition 4: A different model is better at part of the job

The fourth case is capability routing: one model is cheaper or faster for most of the work, and another is better at specific hard decisions. Anthropic's advisor tool formalizes this. A Sonnet or Haiku executor runs the task and consults Opus only when it hits a decision it cannot reasonably solve, and Opus returns guidance without calling tools or writing user-facing output. In Anthropic's tests, Haiku with an Opus advisor scored 41.2% on BrowseComp versus 19.7% alone, at 85% less cost per task than Sonnet working solo - Anthropic.

Cognition's experience adds an important caveat. Its smart friend pattern, where a fast in-house model called a frontier model for help, did not work well when the primary model was too weak, because the hard part is "how does a dumber model know it's at its limits?" It worked well across two frontier models (Cognition runs Claude and GPT together this way in production), where the delegation logic "becomes a capability router rather than a difficulty escalator" - Cognition. The signal for this condition is a measurable gap: one model clearly wins on a sub-task in your evals, and the executor is strong enough to recognize when to ask. For the cost side of routing, see our guide to AI model routing.

Condition 5: Tools or instructions conflict, or permissions must differ

The fifth case is structural conflict that progressive disclosure cannot resolve. Anthropic's guidance keeps subagents when "a single agent struggles to select appropriate tools or there are conflicting instructions in the system prompt." Its tool documentation puts the threshold where tool choice tends to degrade at 30 to 50 tool definitions - Claude docs. Tool search moves that threshold dramatically, so the remaining reason is usually genuine instruction conflict: two jobs whose rules contradict each other (a compliance reviewer told to reject anything ambiguous, a sales assistant told to be helpful and fast).

Permissions are the underrated version of this condition. A subagent can run with a narrower tool set than its parent, and Claude Code lists "enforce constraints by limiting which tools a subagent can use" as a primary benefit. That makes subagents a security boundary: an agent that reads untrusted web pages or inbound emails can be confined to read-only tools and a structured output, so a prompt injection in the content cannot reach the parent's ability to send money or delete data. Our agent sandbox security guide covers the broader set of controls; the architectural point is that an isolation boundary is a legitimate reason for a second context, even when the work itself would fit in one.

Condition 6: The job is far larger than any context, with a near-perfect verifier

The last case is scale: building something so large that no single context could hold it, such as a compiler, a browser or a codebase-wide migration. This is where agent teams and planner-worker fleets earn their cost. Anthropic's compiler project ran 16 parallel agents across nearly 2,000 Claude Code sessions over about two weeks, for just under $20,000 in API costs - Anthropic Engineering. Cursor's experiments ran hundreds of concurrent agents for close to a week on its browser project.

Both teams are explicit that the verifier made the scale possible. Anthropic's agents could work in parallel because there were many separate failing tests, so each agent took a different one; when the work collapsed into one giant task (compiling the Linux kernel), "every agent would hit the same bug, fix that bug, and then overwrite each other's changes," until the author used GCC as a reference oracle to split the work again. If your task lacks an objective, automated pass/fail signal for each piece, this condition does not apply, however large the task. We cover the operational side of these long runs in our guide to long-running coding agents.

6. When Subagents Cost You: The Failure Modes

If the six conditions describe when subagents earn their keep, the failure modes describe what they cost when they do not. These costs are rarely visible in a demo, where a multi-agent system with named specialists looks sophisticated and the first few runs go well. They show up in production, as a slow rise in latency, a creeping bill, and a class of errors nobody can trace because the decision was made three handoffs ago by an agent that no longer exists.

Anthropic's October article lists the failure modes it saw most often in large organizations: context lost in handoffs, subagent sprawl, the "Frankenprompt," unvetted localized evals, and latency. Berkeley's taxonomy and the production reports from Cursor and Anthropic's own engineers add three more: runaway spawning and loops, parallel writers that conflict, and cost blowouts that the architecture makes hard to see. Understanding each one is the fastest way to recognize an over-built system.

The org chart becomes the architecture

The most common enterprise failure is organizational rather than technical. Anthropic describes enterprises that "give each team or problem type its own subagent, with the agent architecture becoming a copy of their org chart (Conway's law at work)" - Anthropic. The billing team owns a billing subagent, the shipping team owns a shipping subagent, and a router sits in front of all of them. Each team optimizes its own subagent against its own small eval, and nobody owns the end-to-end experience.

The consequences compound. Teams ship overlapping subagents "with no enforced standards and no specific owner." Each team adds rules to the shared system prompt until it becomes what Anthropic calls the Frankenprompt, full of conflicting instructions. Leadership makes decisions on "watered-down, overly localized scores" because no shared eval measures the whole journey. One company found that its customer-facing agent's dozen specialist subagents made a consistent on-brand experience hard to maintain and added latency. The fix is not technical cleverness; it is a central owner for the system prompt and the end-to-end eval, with teams contributing skills and tools instead of agents.

The telephone game

The second failure is information loss across handoffs, which Anthropic's January guidance calls the "telephone game": agents split by problem type pass information back and forth, "with each handoff degrading fidelity" - Anthropic. The loss is invisible because each summary looks complete to the agent that wrote it. The details that disappear are precisely the ones the summarizer did not know would matter later: the customer's earlier complaint, the reason a field was left blank, the constraint mentioned in passing.

Anthropic's October article includes a sharp example from a migration test. Folding a subagent into a support agent lowered latency but broke a process: the main agent started answering delivery questions itself instead of consulting the shipping specialist. The reverse failure is just as common in the other direction, where a router sends a question to the wrong specialist, which answers confidently from its narrow context. Both are symptoms of the same structural problem: when information must cross an agent boundary, someone has to decide in advance what crosses, and that decision is often wrong.

Loops, runaway spawning and missing stop rules

The third failure is control. Multi-agent systems have more places to loop and more ways to forget when to stop. In the Berkeley data, step repetition (15.7%) and not knowing the termination conditions (12.4%) are two of the three most common failures. Anthropic's own research system, in early versions, spawned "50 subagents for simple queries" and searched endlessly for sources that did not exist, before the team wrote explicit rules for how much effort different query types deserve - Anthropic Engineering.

Every agent framework now ships controls for this, and they belong in every design from day one. Claude Code lets a subagent spawn its own subagents "up to three layers below the main conversation," with an environment variable to lower the limit or turn nesting off - Claude Code docs. Anthropic's API offers task budgets that give the model a running token countdown for a whole agentic loop, though the documentation is clear they are "a soft hint, not a hard cap" - Claude docs. The hard limits (maximum turns, maximum spend, maximum depth) still have to live in your harness.

Parallel writers that collide

The fourth failure is specific to systems where several agents change the same thing. Cognition's original 2025 warning was that parallel agents make implicit choices about style, edge cases and code patterns that conflict with each other, and its 2026 update says those observations "still hold today for parallel-writer swarms." Cursor's experiments show the mechanics: when agents coordinated through locks, they held locks too long or never released them, and "twenty agents performed like two or three" - Cursor. Without hierarchy, agents became risk-averse, avoided hard tasks and made small safe changes, so work churned without progress.

Cursor's eventual fix was structural: planners that explore and create tasks, workers that focus only on their assigned task, and a judge that decides at the end of each cycle whether to continue. It also dropped an "integrator" role that "created more bottlenecks than it solved." The general rule is that parallel writing only works when the work is partitioned so that writers rarely touch the same thing, and when an objective check (a test suite, a compiler, a renderer) arbitrates. Claude Code's agent team documentation gives the same advice in plain terms: two teammates editing the same file "leads to overwrites," so break the work so each owns a different set of files - Claude Code docs.

The hidden bill

The final failure is economic, and it hides in the architecture itself. Each subagent starts with its own context, so shared instructions, tool definitions and background are paid for again in every context. Prompt caching softens this within one loop, but parallel agents often miss each other's caches. Claude Code's documentation notes that an in-process teammate's requests fall outside the main conversation's cache bucket, so its cache holds for five minutes by default unless you configure a longer one - Claude Code docs. The same page warns that agent teams "use significantly more tokens than a single session," with usage scaling with the number of active teammates.

This is why the multi-agent bill so often surprises teams that budgeted from a single-agent prototype. Gartner predicted in June 2025 that over 40% of agentic AI projects will be canceled by the end of 2027 due to escalating costs, unclear business value or inadequate risk controls - Gartner. Architecture choices that multiply token spend by 3 to 15 times without a matching quality gain are one of the most direct paths to the first of those causes. Our analysis of why most agent pilots never scale covers the other two.

7. The Cost Math on Current Model Prices

Architecture debates tend to stay abstract until someone puts a price on them. This section does that with current list prices, so you can estimate what a multi-agent design costs relative to a single loop for your own workload. The method is deliberately simple: take a realistic token footprint for one task done by a single agent, apply the multipliers that the labs themselves publish for multi-agent designs, and price both on the models teams actually use in late 2026.

The prices below come from each provider's own pricing pages, retrieved on October 27, 2026. Anthropic's current lineup is Claude Fable 5.1 at $10/$50 per million input/output tokens, Claude Opus 5.5 at $4/$20, Claude Sonnet 5.5 at $2/$10 and Claude Haiku 5.5 from $0.10/$0.50 - Anthropic. OpenAI's API lists GPT-6 Astra at $10/$50, GPT-6.1 Sol at $2/$10, GPT-6.1 Terra at $1/$5 and GPT-6 Luna at $0.10/$0.50 - OpenAI. Among open-weight options, Moonshot's Kimi K3.1 Pro lists at $2/$10 and scored 55 on the Artificial Analysis Intelligence Index against 58 for Claude Opus 5.5 - AI Weekly, and DeepSeek's deepseek-flash costs $0.15 per million cache-miss input tokens and $0.60 output off-peak, doubling at peak hours - DeepSeek.

The worked example assumes one task consumes 400,000 input tokens and 20,000 output tokens in a single loop (a moderately long agentic task with a dozen or two tool calls, before caching), and that the multi-agent version consumes four times as much. Four is a conservative middle of Anthropic's published range of 3-10x more tokens than a single agent for equivalent tasks, and it matches the ratio implied by Anthropic's earlier observation that agents use about 4x the tokens of chat while multi-agent systems use about 15x. Prompt caching and batch discounts would lower every number in the table, but they lower the single loop more, because one long-lived context reuses its cache better than many short-lived ones.

The tiering effect: where multi-agent gets cheap

The headline multiplier hides the most important lever: subagents do not have to run on the same model as the lead. Anthropic's original research system used Claude Opus 4 as the lead and Claude Sonnet 4 as subagents, and the same logic applies with today's models. Suppose the lead agent on Claude Opus 5.5 consumes the same 400,000 input and 20,000 output tokens ($2.00), and it fans out to five read-only subagents, each reading 240,000 tokens and writing 12,000. On Claude Haiku 5.5 at entry pricing, each subagent costs about $0.03, so the whole system costs roughly $2.15, only 7.5% more than the single Opus loop. On Claude Sonnet 5.5, each subagent costs $0.60 and the system costs $5.00, two and a half times the single loop.

This changes the shape of the decision. A multi-agent design that runs every agent on a frontier model is expensive by construction. A design with a frontier lead and small-model readers can be nearly cost-neutral, provided the readers' tasks are simple enough for a small model (search, extract, summarize) and the lead does the judgment. The advisor pattern inverts the same idea: a cheap executor does most of the work and pays frontier prices only for the few decisions that need them, which is how Anthropic measured Sonnet with an Opus advisor improving SWE-bench Multilingual by 2.7 percentage points while cutting cost per agentic task by 11.9%. Our guide to cheap LLM APIs for agents lists more options for the reader tier.

A break-even rule you can use

The cost table becomes a decision rule once you put a value on the outcome. A multi-agent design pays off when the value it adds exceeds what it costs: the quality gain times the value of a correct result, plus the time saved times the value of that time, must be greater than the extra token cost plus the expected cost of the new failure modes. In words: extra agents are worth it when a better or faster answer is worth more than the extra tokens and the extra risk.

Two examples make the rule concrete. A due-diligence memo for an acquisition is worth thousands of dollars if it catches one red flag, so spending $8 instead of $2 on Opus 5.5 for a 90% faster, broader search is trivially justified, as long as a verifier checks the citations. A support reply to a "where is my order" question is worth cents, the task is sequential, and the single loop is already accurate, so a router and three specialists that quadruple the cost and add latency are pure loss. Most enterprise agents handle many low-value sequential tasks and a few high-value broad ones, which is why the right architecture is usually a single loop with a narrowly scoped multi-agent element for the few tasks that justify it. For techniques that cut the single loop's bill further, see our guides to prompt caching and the true cost of LLM inference.

8. How to Build a Strong Single-Agent Loop

Folding subagents into one loop only works if the loop is built well. A single agent with a 40,000-token system prompt, 120 tool definitions loaded up front and no stop conditions is not the design that won Anthropic's comparisons; it is the "one-prompt-for-everything" design that lost to both alternatives. The winning design is a lean loop that pulls in context only when a task calls for it, with hard rules enforced in code rather than in prose.

Anthropic's October guidance describes the minimum surprisingly concretely: in many deployments, "one clear system prompt, 4-5 thin data tools, and firm output guardrails would cover most of the use case" - Anthropic. Everything beyond that should earn its place through an eval. The five building blocks below, in roughly the order you should add them, are what turn a basic loop into one that can absorb the work of a dozen specialists.

Start with a lean system prompt

The system prompt is the one piece of context every turn pays for, so it is where over-engineering hurts most. Anthropic reports that it "removed over 80% of Claude Code's system prompt for models like Claude Opus 5 and Claude Fable 5 with no measurable loss on our coding evaluations," including shrinking one tool description from about 9,100 characters to a single line - Claude Developers blog. The principle behind the cut is that current models need judgment and context, not step-by-step rules written for weaker models.

In practice, a lean prompt states what the agent is for, who it serves, what it must never do, and where to look for more: skills for procedures, search tools for knowledge, and a short list of tool categories. It does not paste in policy manuals, product catalogs or long examples. OpenAI's guidance for GPT-6 Astra makes the same point from the other side, telling developers to revisit older instructions because rules that restrained weaker models can make a stronger one stop too early or test unnecessarily. If your prompt has grown through many teams adding "just one more rule," that is the Frankenprompt, and trimming it is usually the cheapest quality improvement available.

Move procedures into skills

Skills carry the domain procedures that subagents used to carry, without the separate context. The Agent Skills specification defines a skill as a directory containing at minimum a SKILL.md file with a name and a description in its frontmatter, and it describes three levels of loading: about 100 tokens of metadata for every skill at startup, the full instructions (under 5,000 tokens recommended) only when the skill activates, and supporting files only when required - Agent Skills specification. That progressive disclosure is what lets one agent hold hundreds of specialties.

A folded refunds specialist might become a skill like the one below. The description tells the agent when to use it; the body carries the procedure and points to reference files rather than inlining them.

---
name: refund-requests
description: Handle customer refund and return requests. Use when a customer asks for money back, a return label, or a replacement for a damaged or late order.
---

# Refund requests

1. Look up the order with `orders_lookup` before promising anything.
2. Check eligibility against references/refund-policy.md (window, condition, region).
3. Refunds above the auto-approve limit go through `refund_request`, which
   returns an approval status. Never tell the customer a refund is done until
   the tool says so.
4. Offer a replacement first when the item is in stock and the customer has not
   asked for money specifically.

Edge cases (marketplace sellers, gift orders, chargebacks): see references/edge-cases.md

The structure matters more than the wording. The skill states when it applies, sequences the steps that must happen in order, and leaves the hard rule (no refund confirmation without an approval status) enforceable by a tool rather than by the model's memory. Because the procedure only loads when a refund comes up, a support agent can carry this alongside dozens of other skills without paying for all of them on every turn. Our Claude Agent SDK deep dive shows how skills plug into a full agent built on that SDK.

Use tool search instead of splitting toolsets

Tool overload was the second historical reason for subagents, and tool search largely removes it. Anthropic's documentation reports that a typical multi-server setup (GitHub, Slack, Sentry, Grafana and Splunk) can consume about 55,000 tokens of tool definitions before the agent does any work, that tool search "typically reduces this by over 85 percent," and that selection accuracy degrades once an agent has more than 30 to 50 tools loaded - Claude docs. With deferred loading, an agent can work across up to 10,000 tools, loading 3 to 5 per search.

The configuration is small. You add a search tool, mark the rarely used tools with defer_loading: true, and keep your three to five most common tools loaded so the agent can call them without searching first:

{
  "model": "claude-opus-5-5",
  "tools": [
    { "type": "tool_search_tool_bm25_20251119", "name": "tool_search_tool_bm25" },
    { "name": "orders_lookup", "description": "Find an order by id, email or phone", "input_schema": { "type": "object", "properties": { "query": { "type": "string" } }, "required": ["query"] } },
    { "name": "refund_request", "description": "Request a refund; returns approval status", "input_schema": { "type": "object", "properties": { "order_id": { "type": "string" }, "amount": { "type": "number" } }, "required": ["order_id", "amount"] }, "defer_loading": true },
    { "name": "shipping_track", "description": "Carrier tracking for a shipment", "input_schema": { "type": "object", "properties": { "tracking_id": { "type": "string" } }, "required": ["tracking_id"] }, "defer_loading": true }
  ]
}

Two design habits make tool search work well. Group tools by user intent rather than mirroring every API endpoint, which Anthropic's October guidance recommends explicitly; a single orders_lookup beats five endpoint-shaped tools. And use consistent prefixes (billing_, shipping_) so one search finds a whole family. The documentation also recommends standard tool calling, without search, when you have fewer than 10 tools or every tool is used in every request, so do not add the search layer to a small agent just because it exists.

Put the hard rules in the tools

A rule written in a prompt is a request; a rule enforced in a tool is a guarantee. Anthropic's guidance moves validation, approval gates and permission checks into tools, so that when a user lacks access, the tool "returns a plain refusal the model can read." This is the single most important habit for a folded agent, because it removes the main argument for keeping a separate "compliance subagent": the compliance logic lives in code that every path goes through.

The pattern generalizes. A refund tool checks the amount against an approval threshold and returns "requires manager approval" rather than executing. A data export tool checks the user's role and refuses otherwise. A send-email tool enforces a recipient allowlist during testing. Each refusal is readable text the model can relay or act on. The agent stays flexible in how it reasons, while the boundaries that matter for money, privacy and safety stay rigid. For the observability side (seeing which refusals fire and why), our comparison of agent observability tools covers the current options.

Budget every loop and measure it

The last building block is control over how long the loop runs. Anthropic's guidance has the harness set turn and cost budgets and write gates, so "the loop stops when the model answers or hits a budget." On the API side, task budgets give the model a running countdown of tokens for a full agentic loop, with a minimum of 20,000 tokens, and the model paces itself against it:

with client.beta.messages.stream(
    model="claude-opus-5-5",
    max_tokens=128000,
    output_config={
        "effort": "high",
        "task_budget": {"type": "tokens", "total": 64000},
    },
    messages= [{"role": "user", "content": "Resolve ticket 48213 end to end."}],
    betas= ["task-budgets-2026-03-13"],
) as stream:
    response = stream.get_final_message()

Because task budgets are advisory, pair them with hard limits in your own harness: a maximum number of turns, a maximum spend per task, and a write gate that requires approval for irreversible actions. Then measure. A single loop's great advantage is that it produces one trace per task, which makes it far easier to see where time and tokens go than in a system of five agents passing messages. If you are not yet measuring cost and success per task, that is the place to start, and our guide to agent evals and benchmarks covers how.

9. How to Fold Subagents Back Into One Loop

If you already run a multi-agent system, the October guidance does not ask you to rip it out. It asks you to measure each subagent and remove the ones that do not earn their context, one at a time, with an eval as the referee. Anthropic's migration kit encodes that procedure, and it is worth following even if you do not use Claude, because the logic is model-agnostic: inventory, baseline, merge, call as tools, fold, and keep what survives.

The kit's own README is careful about its claims, which is a good sign. It describes itself as a reference implementation, "not maintained and not accepting contributions," validated on real models in two runs by one person, with several steps checked only offline - GitHub. Treat it as a structured checklist with helper scripts, not as an automated migration. The diagram below shows the sequence.

Step one: build the eval before touching anything

Every later decision depends on being able to tell whether a change helped. Anthropic's guidance recommends one shared end-to-end eval owned by a central team, plus smaller eval sets that each team ships with its skills, and notes that "even a set of 10 golden examples is enough to start." Grade final answers against a rubric. While an orchestrator still exists, also track routing accuracy, and once subagents are folded in, check whether the agent loaded the right skill or called the right tool.

Two details from the guidance are easy to skip and expensive to miss. First, make sure the eval covers every chain of agents that runs together in production and every rule the agent must not break, because a fold that breaks a rarely used chain will not show up in an average score. Second, run each task more than once. In one of Anthropic's tests, folding a subagent broke a process (the main agent started answering delivery questions itself instead of consulting the shipping specialist), and that break "only showed up in one run out of two." The kit's README recommends starting with ten tasks and two or three repetitions.

Step two: audit, merge and call as tools

The audit assigns each subagent a verdict. Subagents that always run together, chain on each other's output or touch the same data are merge candidates, because their separation creates handoffs without creating useful isolation. Subagents that need their own context but do not need to talk to the user become tools: the main agent keeps the conversation and calls them with a structured result. Anthropic recommends a full handoff only when a subagent "needs to talk to the user directly."

The kit's offline smoke test runs without an API key and is a cheap way to see the workflow before spending tokens:

git clone https://github.com/anthropics/single-agent-loop-kit
cd single-agent-loop-kit/examples/support-desk
KIT_MODEL=fake python3 evals/run_eval.py --variant smoke
# then, to use the guided workflow on your own agent repo:
cp -r ../../skill <your repo>/.claude/skills/single-agent-loop

The bundled example is a support agent with a router and six subagents, which is close to the shape many enterprises run today. Its coupling_map.py script reads a trace export and shows which subagents carry traffic and which always run together, which is the data you need for merge decisions rather than intuition.

Step three: fold one at a time and read the flips

Folding means converting a subagent's prompt into a skill and its API calls into tools in the main agent, then running the eval with and without the subagent. Do one subagent per change, so that a drop in score has one cause. The guidance's sharpest advice is to examine flipped tasks, not just the average: a fold can keep the overall score flat while breaking one specific process, and the average will hide it.

Keep the subagents that survive. The kit's README lists the legitimate reasons: "Parallel research across fresh contexts, independent verification, or work that reads far more than the main agent needs afterwards." Those map directly onto Conditions 1, 2 and 3 in Section 5. When the dust settles, most enterprise systems that went through this process end up with one main loop, a few dozen skills, a well-grouped toolset with tool search, and between zero and three subagents called as tools. Our hands-on Claude Code subagents guide shows the same trade-offs inside a coding workflow.

10. Designing Multi-Agent Systems That Actually Ship

When the conditions in Section 5 hold, the goal is to build the smallest multi-agent system that addresses them, designed around the lessons the field paid for in 2025 and 2026. The successful designs share a handful of properties: work is decomposed by context, one agent owns every write, subagents return compact structured results, a coordinator checks outputs before combining them, each role runs on the model suited to it, and every loop has a depth and spend limit.

Anthropic's April 2026 coordination-patterns guide offers a sensible default: "For most use cases, we recommend starting with orchestrator-subagent" - Anthropic. Its five patterns (generator-verifier, orchestrator-subagent, agent teams, message bus and shared state) map onto increasing coordination complexity, and the guide is candid about how each fails. The orchestrator becomes a bottleneck when subagents need each other's intermediate findings; agent teams struggle when subtasks are not truly independent; a message bus makes chains of events hard to trace; shared state can burn tokens in reactive loops that never converge.

Decompose by context and keep one writer

The decomposition rule from Anthropic's October guidance is the most useful single sentence in this field: decompose "by context" so each subagent needs little from the rest of the system and returns a compact result. Good candidates are independent research paths, components with clean interfaces, and black-box verification. Bad candidates are anything split by job title where the second agent needs the first agent's reasoning.

Cognition's production rule complements it: keep writes single-threaded. Its review loop has one coder and one reviewer that only reads; its smart-friend pattern has one primary that writes and one advisor that only advises; its manager Devin splits larger tasks into child Devins coordinated through an internal MCP, with the manager synthesizing the results. Cognition calls the shape "map-reduce-and-manage" and describes unstructured swarms of agents negotiating with each other as "mostly a distraction" - Cognition. If several agents must write, partition what they write (different files, different services, different records) and let an objective check arbitrate.

Define the subagent contract

A subagent is only as good as the instruction it receives and the shape of what it returns, because, unless it is a fork of the parent conversation, its context starts fresh. Anthropic's SDK documentation is explicit that the only content passed from parent to subagent is the Agent tool's prompt string, "so include any file paths, error messages, or decisions the subagent needs directly in that prompt" - Claude Agent SDK docs. In Claude Code, a reusable subagent is a Markdown file with frontmatter that pins its tools and model:

---
name: diff-reviewer
description: Reviews a finished diff against the task's acceptance criteria. Use after implementation, before merge.
tools: Read, Grep, Glob, Bash
model: sonnet
maxTurns: 30
---

You review a diff you did not write. You receive the acceptance criteria and the
diff only. Run the full test suite and report every failure. Check each criterion
and mark it pass or fail with the file and line that proves it. Do not edit files.
Return JSON: {"verdict": "pass" | "fail", "failures": [...], "criteria": [...]}.

This definition applies most of the lessons in one place. The reviewer cannot edit, so it cannot collide with the writer. It gets concrete criteria ("run the full test suite and report every failure") instead of "make sure it works," which addresses the early-victory problem. It returns a structured verdict the parent can act on rather than prose the parent has to reinterpret. And it caps its own turns. Claude Code's documentation lists maxTurns, disallowedTools, permissionMode, skills and mcpServers among the supported fields, so the same file can also scope which data sources a subagent may touch - Claude Code docs.

Subagents versus agent teams

When the work genuinely needs agents that talk to each other, the choice is between subagents that report back to one caller and agent teams whose members share a task list and message each other directly. Claude Code's documentation draws the line clearly: subagents are for "focused tasks where only the result matters," with lower token cost because results are summarized back; agent teams are for "complex work requiring discussion and collaboration," at higher cost because each teammate is a separate instance - Claude Code docs. The diagram from that documentation shows the structural difference.

Agent teams are experimental in Claude Code and off by default, enabled with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1. The documentation's own guidance is a useful brake on enthusiasm: start with 3 to 5 teammates, aim for 5 to 6 tasks per teammate, and remember that "three focused teammates often outperform five scattered ones." It also states that for "sequential tasks, same-file edits, or work with many dependencies, a single session or subagents are more effective." Research, review, debugging with competing hypotheses and cross-layer features owned by separate teammates are the documented sweet spots.

Assign models by role and verify at the end

The production reports agree that one model for every role is a missed opportunity. Cursor found that different models suited different roles in its planner-worker system and now "assigns the best-suited model to each role," and it noted that prompt design affected behavior more than the harness or the models did. Cognition routes sub-tasks to whichever frontier model is strongest at them. The cost math in Section 7 shows why this matters financially: a frontier lead with small-model readers can cost little more than a single frontier loop.

The talk below, from Factory's Luke Alvoeiro at the AI Engineer conference in May 2026, is the best concise walkthrough of a production multi-agent architecture built on these principles: an orchestrator, workers and validators, with validation contracts, structured handoffs, and a case for serial over parallel execution where it matters. It is one of the most-watched conference talks on the subject this year.

The talk reinforces two points worth carrying into any design review. Validation is a first-class role, not an afterthought: the system improves when a validator with a written contract checks each worker's output, which matches the generator-verifier evidence. And serial execution is often the right default even inside a multi-agent system, because parallelism only pays when the parts are truly independent. Model choice per role compounds over time, since each model generation can be slotted into the role it does best.

11. Platforms and Frameworks: Who Does What

Every major agent framework now supports both single-agent and multi-agent designs, so the framework rarely decides the architecture for you. What differs is the default each one nudges you toward, and how much of the plumbing (skills, tool search, subagent isolation, budgets, tracing) it provides out of the box. The table below summarizes the main options as of late October 2026; the sections after it explain where each fits.

Reading the table top to bottom shows a convergence. Frameworks that began as multi-agent toolkits now document single-agent patterns and warn against premature splitting, while the vendors that began with single loops now ship carefully scoped multi-agent primitives. For a scored comparison of the open-source frameworks, see our LangGraph vs CrewAI vs AutoGen ranking.

Anthropic: Claude Agent SDK and Claude Code

Anthropic's stack is the most explicit about the single-loop-first philosophy, because its October guidance and its tooling come from the same team. The Agent SDK and Claude Code provide skills, tool search with deferred loading, task budgets, the advisor tool for executor-advisor pairs, subagents that can nest up to three levels below the main conversation, and experimental agent teams with a shared task list and mailboxes. The pricing of the underlying models (Opus 5.5 at $4/$20 per million tokens, Haiku 5.5 from $0.10/$0.50) makes the frontier-lead, small-reader design straightforward.

The trade-off is that Anthropic's primitives are designed around Claude models. Cognition runs Claude and GPT together in production, and many enterprises want the same flexibility, which requires either a model-agnostic framework or a custom harness. Anthropic's documentation is also candid about rough edges: agent teams cannot be resumed with in-process teammates, task status can lag, and teammates cannot spawn their own teams. Our Claude Code subagents guide covers the practical setup.

OpenAI: Agents SDK and ChatGPT parallel agents

OpenAI's Agents SDK documents two orchestration styles, LLM-driven (the model plans and picks tools or handoffs) and code-driven (your code decides the flow), and two multi-agent primitives: agents-as-tools, where a manager keeps control and calls specialists, and handoffs, where a specialist takes over the conversation - OpenAI Agents SDK. The code-driven patterns it lists (structured-output routing, chaining, evaluator loops, parallel runs) are the deterministic end of the spectrum and are often the right tool for well-defined business processes.

On the product side, the parallel agents added to GPT-6 Pro in ChatGPT on October 16 bring multi-agent execution into a mainstream subscription product. At the API level, GPT-6 Astra at $10/$50 per million tokens is priced like Claude Fable 5.1, while GPT-6.1 Sol and GPT-6.1 Terra cover the middle tiers and GPT-6 Luna at $0.10/$0.50 is a natural candidate for reader subagents. Our guide to OpenAI's agents API covers building long-running agents on that stack.

LangChain, Microsoft and Google

The model-agnostic frameworks have moved in the same direction. LangChain's documentation now opens its multi-agent page by noting that "not every complex task requires this approach," and it documents a skills pattern (one agent stays in control and loads context as needed) alongside subagents, handoffs and routers - LangChain docs. Microsoft's Agent Framework, the successor to AutoGen and Semantic Kernel, adds a Harness Agent with planning, todo tracking, context compaction and memory for long single-agent tasks, alongside graph-based workflows for explicit multi-agent orchestration - Microsoft Learn. Its function-before-agent rule, quoted in Section 1, is worth pinning above every architecture review.

Google's Agent Development Kit leans toward explicit structure, with sequential, loop and parallel workflow agents and, since ADK 2.0, graph workflows that mix AI agents with deterministic nodes - Google ADK. CrewAI remains the most role-oriented of the group, with sequential and hierarchical processes in which a manager model delegates to role-based agents - CrewAI docs. Role-based crews are intuitive to design, which is exactly why they need the most discipline: they make it easy to split by job title rather than by context.

Platforms that make the choice for you

For many businesses, the architecture question is best answered by not having to answer it. Coding agents such as Devin and Cursor already embed the patterns that work (single writers, clean-context review, manager-child delegation) inside their products. Consumer agents such as ChatGPT's parallel agents decide internally when to fan out. Open-weight model providers are pushing the other way: Moonshot's agent swarm approach, which we analyzed in our Kimi K2.6 agent swarm guide, shows how cheap tokens change the cost side of the trade-off.

At the business level, platforms like O-mega take a similar stance for an entire company: one AI builds and runs the website, app, billing, content and admin from a single conversation, so the founder never has to design routers, specialists or handoffs. Whether you buy a platform or build your own harness, the evaluation questions are the same: who owns every write, how context is kept lean, how outputs are verified, and what each task costs. For research-heavy orchestration that beats single frontier models on reasoning benchmarks, our coverage of Sakana's Fugu orchestration is a useful counterpoint to the single-loop trend.

12. Use Cases: Where Each Architecture Wins

The evidence becomes most useful when applied to specific jobs. The same organization will often run a single loop for one workflow, a verifier pair for another, and a research fan-out for a third, because the task structure differs. The five use cases below cover most of what businesses deploy agents for in 2026, with the architecture the evidence favors and the reasons.

A common thread runs through all five: the architecture follows the shape of the work, not the shape of the team that owns it. Where the work is a sequence of dependent decisions over shared state, a single loop wins. Where it is a broad sweep of independent reading, parallel readers win. Where mistakes are expensive and checkable, a separate verifier wins. Where the work is enormous and objectively testable, a fleet can win.

Customer support and service

Customer support is the poster child for over-built multi-agent systems, and it is where Anthropic's October guidance draws most of its examples. A typical design routes each message to a billing, shipping, returns or technical specialist. The evidence says this hurts: conversations jump between topics, each specialist sees only part of the history, the brand voice drifts between subagents, and the router adds latency on every turn. One Anthropic customer found that the dozen specialist subagents in its customer-facing agent made a consistent experience hard to maintain.

The architecture that wins is a single loop with skills for each process (refunds, delivery issues, account changes), a well-grouped toolset behind tool search, and hard limits in the tools (refund thresholds, identity checks). Subagents earn a place only at the edges: a read-only researcher that searches a large knowledge base and returns a cited answer, or an isolated agent that reads untrusted inbound content. Our comparison of AI customer support agents shows how the leading vendors approach this.

Research, analysis and due diligence

Research is where multi-agent systems have their strongest evidence, and the reason is structural: a broad question decomposes into independent sub-questions that each require heavy reading and return light findings. Anthropic's research system (90.2% better than a single agent on its internal eval), Google's Finance-Agent result (+80.9% with a coordinator) and OpenAI's decision to put parallel agents into GPT-6 Pro all point the same way. Speed matters here too, since parallel reading can cut research time by up to 90%.

The design that wins is an orchestrator with parallel read-only subagents, a frontier model as the lead, cheaper models as readers where the reading is simple, and a citation or fact-check verifier at the end. The orchestrator needs explicit effort rules, since early versions of Anthropic's system spawned dozens of subagents for simple questions. The single-loop alternative remains better for narrow questions with one thread of reasoning, where Tran and Kiela's equal-budget result applies directly.

Software engineering

Coding sits in the middle, which is why the field's most influential voices have moved back and forth on it. Most coding tasks are sequential and share state (the design decision in one file constrains the next), which favors a single writer. Anthropic's 2025 research post named coding as a domain with fewer truly parallelizable tasks, and Cognition's original warning was about parallel coders making conflicting implicit decisions. Yet the most impressive multi-agent results of 2026 (a compiler, a browser, large migrations) are also coding.

The resolution is that coding needs different architectures at different scales. For a feature or a bug fix, a single loop that writes code and tests, plus a clean-context reviewer before merge, is the strongest default; Devin Review's two bugs per pull request is the evidence. For codebase-wide work with a large, reliable test suite, a planner-worker fleet with partitioned ownership and a judge can compress weeks into days. Our guides to AI coding CLIs and loops for coding agents cover both ends.

Back office, finance and operations

Back-office processes (invoice handling, reconciliations, onboarding, report generation) are usually well-defined sequences with known steps and auditable outputs. Here the strongest architecture is often not an agent swarm or even a free-form agent, but a code-driven workflow with agents at the judgment points: extract this document, classify this exception, draft this reply. Microsoft's guidance to use a workflow when "the process has well-defined steps" and OpenAI's code-driven orchestration patterns both describe this design.

Where these processes involve judgment across many documents, a single loop with skills for each process type and strict tools for every write (posting, paying, sending) is the next step up. Multi-agent elements fit narrowly: parallel extraction across a large batch of independent documents, or a verifier that re-checks totals and approvals before anything is posted. The error-amplification data is especially relevant in finance, where an independent agent's undetected mistake can flow straight into a ledger.

Sales, marketing and growth operations

Sales and marketing operations mix both shapes. Account research before a call, competitor monitoring and content research are broad and parallelizable, which suits parallel readers. Personalized outreach, campaign execution and CRM updates are sequential writes over shared state, which suit a single loop with strict tools (sending limits, approval for new recipients, suppression lists enforced in code).

The practical design is a single operations agent with skills for each motion, that calls a research subagent as a tool when it needs to prepare an account brief, and that never delegates writes. This keeps one voice in every outbound message, one record of what was promised to whom, and one place to enforce consent and compliance rules. Teams that instead build a "prospecting agent," a "copywriting agent" and a "sequencing agent" handing off to each other tend to rediscover the telephone game in the form of messages that contradict each other.

13. Future Outlook: Where Agent Architecture Goes Next

The direction of travel is clear even if the pace is not: models absorb orchestration that used to live in harnesses, multi-agent elements become narrower and better engineered, and the economics shift as open-weight and small models make the reader tier nearly free. Each of those trends has a concrete driver already visible in October 2026, which makes them more than speculation.

The first driver is model capability. Anthropic's guidance traces the shift to Opus 4.5, and the 80% system-prompt reduction for Claude 5-generation models shows how much scaffolding newer models no longer need. Each generation moves more decision-making from the harness into the model. The second driver is training for delegation. Cognition describes the open problems in multi-agent systems as communication problems (when a weaker model should escalate, how a child agent should surface a discovery that changes its siblings' work) and expects the next generation of models, including those it trains itself, to close them.

Multi-agent becomes a model capability, not an architecture

The likeliest medium-term outcome is that much of today's multi-agent orchestration disappears into the model and the platform. Parallel agents in GPT-6 Pro are an early sign: the user asks one question, and the product decides internally whether to fan out. Anthropic's advisor tool is another: a pattern that teams used to build by hand is now one tool definition with a call cap. As this happens, the architecture question for most builders moves up a level, from "how do I wire agents together" to "which tasks do I let the platform parallelize, and how do I verify the result."

This mirrors earlier technology shifts. Developers once managed threads and memory by hand; runtimes and languages absorbed most of that work, and engineers moved on to higher-level design. Multi-agent coordination is following the same path, but with a twist: unlike thread scheduling, agent delegation involves judgment about what context to share, which is exactly the kind of decision models are getting better at. The teams best positioned for this shift are the ones that already have good evals, because evals are what let you trust a platform's internal choices.

Cheap tokens change the reader tier

The economics are moving fast at the low end. DeepSeek's Flash model costs $0.15 per million input tokens off-peak, and its Search and Fetch APIs are priced at $0.75 per 1,000 successful requests, with per-request billing starting November 1, 2026 - DeepSeek. Moonshot has promised open weights for Kimi K3.1 Pro, a model within a few points of the frontier on the Artificial Analysis index, by November 4 - AI Weekly. When reading costs approach zero, the token multiplier that makes multi-agent systems expensive matters much less for the reader tier, and the binding constraints become coordination quality and verification.

That shift favors exactly the patterns this guide recommends: a strong lead or single writer, cheap parallel readers, and rigorous verification. It does not rescue the patterns at the bottom of the scorecard, because their problem is not token price but error amplification and lost context. A swarm of cheap agents that amplifies errors 7.8x is still a swarm that amplifies errors. Our analysis of Kimi K3's open weights and our October 2026 LLM ranking for agents track these model economics as they move.

Standards, protocols and the eval moat

The Agent Skills donation to the Agentic AI Foundation, following MCP before it, means the building blocks of the single loop are becoming vendor-neutral infrastructure. A skill written once can run on more than 70 platforms. That portability favors single-loop designs, since the expensive asset (encoded procedure) moves freely while the model underneath can change. Agent-to-agent protocols will matter more for agents that cross company boundaries than for agents inside one system, a distinction we cover in our MCP vs A2A guide.

The durable advantage, then, is not an architecture but the ability to measure. Anthropic's migration advice starts with an eval; Google's study shows architecture choice is predictable from task properties; Berkeley's data shows that verification and clear termination fix more failures than better models. Teams that own a shared, end-to-end eval can adopt whatever the next model generation makes possible, fold or add agents with confidence, and avoid the costly swings between fashions that defined 2025 and 2026.

14. Conclusion: A Decision Framework

The question "single agent vs multi-agent" has a better answer in late 2026 than it did a year ago, because the evidence finally holds compute constant and the labs have published what they learned in production. Start with one agent loop, kept lean with skills and tool search, with hard rules in the tools and budgets on every loop. Add multi-agent elements only when a specific, measured condition calls for them, and add the smallest one that addresses it. The flowchart below condenses the six conditions into the order in which to ask them.

Most tasks will exit at the first question. That is not a failure of ambition; it is what the 67.7-versus-21.5 successes per thousand tokens, the 2x latency difference and the 39-70% losses on sequential tasks are telling you. The cases that reach the lower branches are real, valuable and worth engineering carefully, and the guidance for each one is now specific enough to follow.

Three rules sit underneath every branch. One agent owns every write, so parallel agents contribute reading and judgment, not conflicting actions. Split by context, never by job title, so no agent depends on reasoning it never saw. And measure before and after every change with a shared end-to-end eval run more than once, because the failures that matter hide in flipped tasks, not in averages.

If you are building, begin with Anthropic's migration kit or the equivalent discipline in your own framework, and treat every existing subagent as a hypothesis to test. If you are buying, ask vendors which of their agents can write, how context moves between them, what verifies the output, and what a task costs, and favor platforms such as O-mega that keep one accountable AI in charge of the work. Either way, the architecture that wins is the one whose structure matches the shape of the task, and for most tasks in 2026, that shape is a single, well-equipped agent.

This guide reflects the state of agent architecture, research and model pricing as of October 27, 2026. Model prices, product features and experimental capabilities such as agent teams and parallel agents change frequently, so verify current details with each provider before you build or buy.