The Only Question That Decides This
Most writing about multi-agent systems assumes the conclusion. More agents, the argument goes, means more specialization, more parallelism, more capability — an architecture that scales the way a team scales. It is an appealing analogy and it is mostly wrong. The credible engineering position, which almost nothing in this category reports, is that a multi-agent architecture is usually the more expensive way to get a worse answer.
Usually. Not always. There is a real case where multi-agent wins decisively, and the strongest published evidence for it comes from Anthropic. There is an equally real case against it, and the strongest published argument comes from Cognition. Both are right about different workloads, and the thing that separates those workloads turns out to be simple enough to decide in an afternoon.
This article is written for the person actually making the choice: a CTO, a staff engineer, or a technical founder deciding what to build next quarter. It reports both sides of the debate with their real numbers, states the token economics plainly because they are the decisive input, gives you the five architecture patterns with their actual failure modes, covers the context-engineering discipline that both camps agree is the real mechanism, and prices the result against current list rates so you can model the bill before you commit to it.
Every model name, price, benchmark figure and repository statistic below carries its date and is accurate as of August 2026. This is the fastest-moving material on this site; check anything you plan to build on.
Start with one agent. Make it good. Add a second only when you can name, in advance, the independent subtasks it will run — and when you have modelled what the extra tokens cost at your real volume.
— Frenchy Digital architecture principle
The Case Against: Cognition's Two Principles
On June 12, 2025, Cognition's Walden Yan published "Don't Build Multi-Agents". It remains the sharpest published argument against the pattern, and it is worth reading in full because it is an engineering argument rather than a contrarian pose. It reduces to two principles.
- Principle 1: Share context, and share full agent traces, not just individual messages. A subagent handed a task description has been given the conclusion of a reasoning process without the reasoning. It will fill the gap with assumptions, and its assumptions will not match the ones the lead agent made.
- Principle 2: Actions carry implicit decisions, and conflicting decisions carry bad results. Every action an agent takes commits to choices nobody wrote down — a style, a data shape, a naming convention, an interpretation of an ambiguous requirement. Two agents acting in parallel commit independently, and there is no merge step that reconciles decisions neither of them stated.
The example that carries the argument is a Flappy Bird clone. The work is split: one subagent builds the background, another builds the bird. The first subagent, given "build the background," produces something in a Mario-style visual idiom. The second, given "build the bird," produces a bird in a completely different style. Neither subagent failed at its task. Each output is defensible on its own. The composite is incoherent, and no amount of careful synthesis at the end repairs it, because the incompatibility was baked in at the moment two agents made unstated aesthetic decisions independently.
Cognition's recommendation follows directly: build single-threaded linear agents, and when the thread outgrows the context window, compress the history with the model rather than distributing it across agents. One thread means one set of decisions, stated or not, and one place to look when the output is wrong.
The honest framing of this source: it is an engineering argument from a company that builds coding agents, published as a position, not as a controlled study. Its authority comes from the mechanism it identifies, which generalizes well, rather than from measurement. Weigh it accordingly — and notice that the mechanism it identifies is exactly the one Anthropic names as the limit of its own approach.
The Case For: Anthropic's Orchestrator-Worker Research System
The strongest published case for multi-agent architectures is Anthropic's engineering write-up on how it built its multi-agent research system. The design is orchestrator-worker: a lead agent running a stronger model decomposes a research question, delegates subtasks to worker agents running a cheaper model with isolated context, and synthesizes their returns.
The headline result: the orchestrator-worker system outperformed a single-agent baseline by 90.2% on an internal research evaluation. State that precisely, because the framing matters. It is Anthropic's own reported figure, on Anthropic's own internal eval, comparing a system Anthropic built against a baseline Anthropic defined, on a task family — open-ended research — chosen because it parallelizes. It is not a third-party reproduction and it is not a general claim about architectures.
What makes the post credible is that Anthropic publishes its own limits with equal clarity. Four of them matter for your decision:
- Unsuitable where agents need shared context: The pattern breaks down when subtasks are interdependent — which is the identical mechanism Cognition identifies. The two positions do not actually contradict each other on this point.
- Coding has fewer parallelizable components than research: Anthropic names coding specifically as a domain with less parallelism available. That is the single most important caveat for engineering teams, because coding agents are the most common thing teams try to build multi-agent.
- Synchronous lead-to-subagent execution bottlenecks: The lead waits for workers. Parallelism in the worker layer does not remove serialization at the orchestration layer, and the lead's turn-around dominates end-to-end latency.
- Early versions over-spawned subagents on simple queries: Left to its own judgment, the lead fans out on inputs that needed one lookup. Spawn discipline is an explicit engineering problem, not an emergent behavior you can rely on the model to get right.
There is one more number in that post, and it is the one that should change how you read the 90.2%. On the BrowseComp evaluation, Anthropic reported that three factors explained 95% of performance variance — and that token spend alone accounted for 80% of it. Sit with that. The dominant explanatory variable for agent performance on that benchmark was not the topology, not the model, not the prompt. It was how many tokens the system was allowed to burn.
If token spend explains 80% of performance variance, and a multi-agent system spends roughly 15× what a chat interaction does, then a large share of any multi-agent win is a spend win that a single agent with a bigger budget might also have captured.
— Reading Anthropic's own numbers together
That is not a refutation. Spending tokens in parallel across isolated windows is genuinely different from spending them serially in one window that is rotting — that is the real mechanism, and we come back to it below. But it does mean the correct baseline for evaluating a multi-agent design is not "the single agent we happened to build first." It is "a single agent given a comparable token budget." Very few teams run that comparison, and it is the first thing we set up on an engagement.
The Token Economics Are the Decisive Input
Architecture debates get resolved by cost more often than by capability, and here the cost is not marginal. Anthropic's published multipliers, from the same engineering post:
- Agents ≈ 4× chat: A single agent uses roughly four times the tokens of a chat interaction, because it plans, calls tools, reads results, and iterates rather than answering once.
- Multi-agent ≈ 15× chat: A multi-agent system uses roughly fifteen times the tokens of a chat interaction. Relative to a single agent, that is still nearly a 4× step up — and it lands on both the input and output sides.
Two honest caveats on these numbers, because this cluster of facts is thinner than its confident repetition suggests. First, they are vendor-published and directional: Anthropic describes typical usage, not a measured distribution across workloads. Second, we could not find an independent, non-vendor case study publishing real token-per-task numbers for a production multi-agent system. That absence is itself informative about how much of the public discourse rests on one blog post.
Use them anyway — they are the best published figures available, and the direction is not in doubt. But treat the multiplier as an input to a model you then measure against, not as a substitute for measurement. The cost-modelling section below turns them into concrete per-task numbers at current list prices.
The Reconciliation: It Was Never About Agent Count
Put the two positions side by side and the apparent contradiction dissolves. They are not disagreeing about architecture. They are describing different workload shapes, and they agree about the mechanism.
| The question | Cognition (against) | Anthropic (for) | What both are actually saying |
|---|---|---|---|
| Where does context live? | In one thread. Share full agent traces, not individual messages — a subagent handed only a task description is missing the reasoning that produced it. | In isolated windows per worker, with condensed summaries returned to a lead that holds the plan. | Both are context arguments. The question is whether the subtask can be described completely enough that isolation costs you nothing. |
| What happens when subtasks disagree? | Actions carry implicit decisions, and conflicting decisions carry bad results. There is no merge step that repairs two incompatible interpretations of the same brief. | Not addressed for interdependent work — Anthropic states the pattern is unsuitable where agents need shared context or heavy interdependency. | Agreement, not conflict. Both say interdependent subtasks should not be split. |
| What does the evidence look like? | Engineering argument from building coding agents, published June 12, 2025. Persuasive, not a controlled study. | 90.2% improvement over a single-agent baseline on an internal research eval — Anthropic's own reported figure, on a task family selected for parallelism. | One is opinion from a coding-agent shop; the other is a vendor result on a research workload. Neither generalizes on its own. |
| What is the recommended default? | Single-threaded linear agents, with LLM-based compression of history when the thread gets long. | Orchestrator-worker with a stronger lead model and cheaper workers, for breadth-first search. | Start single-threaded. Move to orchestrator-worker only when you can name the independent subtasks in advance. |
| What is the honest cost position? | Not the focus of the argument, but a single thread is by construction the cheaper option. | Published plainly: agents ≈ 4× chat tokens, multi-agent ≈ 15× chat tokens. | The 15× multiplier is the most decision-relevant number either side published, and it comes from the pro-multi-agent side. |
The multi-agent debate, both sides with their own framing. Anthropic's 90.2% figure is self-reported on an internal evaluation; Cognition's position is an engineering argument rather than a study.
The thesis, stated plainly: multi-agent wins on wide-and-shallow, independently parallelizable work — research, market scans, multi-source enrichment. Single-agent wins on deep-and-narrow, shared-state work — coding, long-form writing, transactional workflows. Anthropic itself notes that coding has fewer parallelizable components than research, which is precisely the domain Cognition writes from. The two most-cited positions in this debate are describing the two ends of the same axis.
And both camps converge on the same mechanism: context, not agent count. Cognition's objection is that splitting agents splits context, and split context produces conflicting implicit decisions. Anthropic's justification is that splitting agents isolates context, so each worker's window stays small and high-signal while the lead holds only the plan and the condensed returns. Same variable, opposite sign, depending on whether the subtasks needed to see each other.
| Workload | Shape | Architecture that wins | Why |
|---|---|---|---|
| Breadth-first research and market scans | Wide and shallow — many independent lookups, synthesized once | Multi-agent (orchestrator-worker) | Workers never need each other's findings; more parallel coverage is directly more value |
| Multi-source enrichment (entity, company, compliance lookups) | Wide and shallow, fixed schema per source | Multi-agent, or plain parallel tool calls | Often does not need agents at all — concurrency, not autonomy, is what you are buying |
| Coding and refactoring | Deep and narrow, heavy shared state | Single agent | Anthropic itself notes coding has fewer parallelizable components than research; Cognition's whole argument comes from this domain |
| Long-form writing and document generation | Deep and narrow — voice, structure and argument are shared state | Single agent with compaction | Section-per-subagent produces the Flappy Bird failure in prose: individually fine, collectively incoherent |
| Customer support resolution | Narrow, stateful, transactional | Single agent, possibly with a routing classifier in front | A handoff topology adds hops and cost without adding parallel work |
| Batch document processing | Wide, independent, no synthesis step | Neither — a queue and one agent per item | This is a concurrency problem wearing an architecture costume |
Workload shape as the architecture selector — Frenchy Digital, 2026. LangChain's position lands in the same place from a third vantage point.
The two rows people argue with
Coding. This is where teams most want multi-agent to work, and where the evidence is least supportive. A codebase is shared state by definition: types, conventions, module boundaries, and half-finished refactors are context every worker needs and none of them can summarize losslessly. If you want parallelism in coding, parallelize at the pull-request boundary — independent, reviewable, mergeable units with an explicit interface — not inside a single change.
Batch document processing. Teams reach for orchestration here and rarely need it. A thousand independent documents processed by the same agent is a queue and a concurrency limit, not a multi-agent system. You get the parallelism without the coordination cost, the synthesis loss, or the 15× multiplier — because there is no synthesis step and no shared plan.
The Five Architectures, and What Each One Breaks On
These are the topologies that actually ship. The single-threaded agent is included deliberately: it is the baseline every multi-agent design has to beat, and it wins more often than the category's literature admits.
| Pattern | Shape | What it is genuinely good for | How it fails |
|---|---|---|---|
| Single-threaded agent with compaction | One agent, one context window, history compressed as it grows | Anything with shared state: coding, writing, transactional workflows, most line-of-business automation | Context rot as the thread lengthens; compaction that discards a decision the agent later needs; no parallelism available at all |
| Supervisor / orchestrator-worker | A lead decomposes, delegates to workers with isolated context, and synthesizes their returns | Breadth-first research, market scans, multi-source enrichment — subtasks that never read each other's output | The lead is a synchronous bottleneck; over-spawning workers on simple queries; synthesis discards detail the workers had; the 15× token bill arrives whether or not the breadth helped |
| Sequential pipeline | Fixed stages, each consuming the previous stage's output | Known-shape workflows with a compliance or validation order: extract, validate, transform, write | Errors compound stage to stage with no backtracking; latency is the sum of every stage; a late stage that needs early context only has it if you passed it explicitly |
| Swarm / handoff | Peer agents transfer control to whichever specialist fits, with no central planner | Routing-shaped problems — triage, specialist support desks | Control ping-pongs between peers; no agent owns the final answer; cost is unbounded without an explicit hop limit; post-hoc debugging means reconstructing a control graph |
| Hierarchical (supervisors of supervisors) | Multiple orchestration layers, each with its own workers | Genuinely large decompositions across distinct domains, with an owner per domain | The token multiplier compounds per layer; context is diluted at every summarization boundary; attribution disappears and nobody can explain the final output |
Agent architecture patterns with their real failure modes — Frenchy Digital, 2026.
Three notes that decide most real designs.
Spawn discipline is an engineering problem. Anthropic reports that early versions of its research system over-spawned subagents on simple queries. This is the default behavior, not an edge case — a lead agent given the ability to fan out will fan out. Bound it explicitly: a maximum worker count per task, a complexity gate before any fan-out at all, and a cheap classification step that routes simple inputs to a single-agent path. The savings from that one gate usually exceed every prompt optimization you will do afterwards.
The lead is a serialization point.Workers running in parallel do not make the system parallel if the lead has to wait for all of them, synthesize, and then decide whether to fan out again. Latency in an orchestrator-worker system is dominated by the lead's round trips, not the worker count, and adding workers past the point of diminishing coverage adds cost and latency simultaneously.
Hierarchies compound the multiplier. Every layer of supervision multiplies token spend and adds a summarization boundary where information is lost. Two layers is already an unusual justification; three is almost always a decomposition that should have been a pipeline. If you cannot explain, in one sentence, why a middle layer exists, delete it.
Context Engineering Is the Actual Discipline
If both camps agree the mechanism is context, then context engineering — not topology selection — is where the leverage is. Anthropic's effective context engineering for AI agents, published September 29, 2025, is the best primary treatment, and its central concept reframes the entire architecture question.
That concept is context rot: model accuracy degrades as context grows, and it starts degrading well before the window fills. Anthropic frames it as an attention budget — transformer attention has to model relationships between every pair of tokens, so the number of relationships grows with the square of the token count. Every token you add dilutes the attention available to the tokens that mattered. A million-token window is a capacity limit, not a performance guarantee.
| Technique | What it does | When it earns its cost |
|---|---|---|
| Compaction | Summarize the conversation so far, preserving architectural decisions and unresolved bugs, and continue from the summary | Long single-threaded sessions where the thread is the value. This is what makes the single-agent default viable past the point where naive history would rot. |
| Structured note-taking | Write durable state to external memory files the agent reads back, so knowledge survives a context reset | Multi-session or long-horizon work. Cheap, inspectable, and it makes agent state something you can diff in a code review. |
| Sub-agent context isolation | Workers hold detailed search context privately and return condensed summaries of roughly 1,000 to 2,000 tokens to the lead | This is the actual justification for multi-agent designs. If workers return full transcripts, you have paid the multiplier and isolated nothing. |
| Just-in-time retrieval | Fetch context at the moment of need using identifiers and references, instead of preloading everything up front | Almost always the default. Hybrid preloading is defensible only where latency is the binding constraint. |
| Tool consolidation | Fewer, clearly distinguishable tools with non-overlapping purposes, rather than a large surface of near-duplicates | Always — and it is the single cheapest fix for an agent that picks the wrong action. Ambiguous tool sets are a design defect, not a prompting problem. |
Context-engineering techniques from Anthropic's published guidance, with the architectural decision each one supports. LangChain's write / select / compress / isolate taxonomy maps onto the same four moves.
The guiding principle Anthropic states is worth adopting verbatim as a design constraint: find the smallest set of high-signal tokens that maximizes the outcome. That is a harder target than it sounds, because every instinct in agent development pushes the other way — add another example, another instruction, another retrieved document, another tool. Each addition is locally defensible and collectively corrosive.
Which brings us to tools, where the same principle produces the most quotable rule in the post:
If a human engineer can't definitively say which tool should be used, an AI agent can't be expected to do better.
— Anthropic, Effective context engineering for AI agents (September 2025)
Take that literally as an acceptance test. Print your tool list, hand it to an engineer who did not write it, describe a task, and ask which tool they would call. If they hesitate, or if two tools are both defensible, the agent will pick wrong at some rate you cannot prompt your way out of. Merge the overlapping tools, delete the ones that exist for completeness, and rename anything whose purpose is not obvious from its signature. In a multi-agent system this compounds: every worker inherits the ambiguity, and every wrong tool call is billed at the fan-out rate.
One deliberate omission. A set of specific improvement figures for context editing and memory tooling circulates widely and traces only to secondary blogs; the same is true of a frequently repeated claim about automatic compaction thresholds. We could not verify them against primary documentation, so they are not in this article. If a vendor quotes precise percentage gains for context management features, ask for the primary source before you plan around them.
The Framework Landscape in August 2026
Before the table, the warning that makes it worth reading: most published "2026 agent framework comparison" articles contain fabricated version numbers. Widely circulated posts cite releases like CrewAI 0.105 in March 2026 or LangGraph 0.4 in April 2026 — both flatly contradicted by the repositories. These articles are generated at scale for search traffic, and their version strings are invented. Verify the releases page and the last-push date yourself before you take any framework recommendation, including this one.
The following figures were read from the live repositories on August 10, 2026.
| Framework | Stars | Latest release | Status | What the numbers tell you |
|---|---|---|---|---|
| browser-use | 108,638 | 0.13.7 (Jul 27, 2026) | Active | The most-starred agent repository of any kind; browser automation rather than general orchestration |
| Microsoft AutoGen | 60,351 | python-v0.7.5 (Sep 30, 2025) | Maintenance mode since Oct 2025 | Superseded by Microsoft Agent Framework 1.0, GA April 3, 2026. Large audience, stalled project — last push April 15, 2026 |
| CrewAI | 56,905 | 1.15.14 (Aug 8, 2026) | Active | Ships multiple times per week; role-and-crew abstraction over the supervisor pattern |
| LangGraph | 39,382 | checkpointpostgres 3.1.2 (Aug 7, 2026) | Active | Monorepo with per-package tags — there is no single LangGraph version number, which is why blog comparisons quoting one are unreliable |
| OpenAI Agents SDK (Python) | 28,540 | v0.19.4 (Aug 5, 2026) | Active, still pre-1.0 | Pre-1.0 after two years is a stability signal worth pricing into a roadmap |
| Mastra (TypeScript) | 27,083 | @mastra/core 1.57.0 (Aug 10, 2026) | Active | The TypeScript-native option; relevant if your platform team does not want a Python service |
| Google ADK (Python) | 21,068 | v2.6.3 (Aug 7, 2026) | Active, major v2 | Now on a second major version |
| Pydantic AI | 19,195 | v2.27.0 (Aug 8, 2026) | Active, major v2 | Typed, validation-first; the option for teams that already run Pydantic everywhere |
| Claude Agent SDK (Python) | 7,849 | v0.2.134 (Aug 8, 2026) | Active | Renamed from Claude Code SDK — old tutorials reference the previous name |
| AG2 (ex-AutoGen fork) | 4,848 | v1.0.1 (Jul 29, 2026) | Active but small | Roughly 8% of AutoGen's following — a weak continuity signal for teams hoping the fork carries AutoGen forward |
Agent framework landscape, live GitHub data read August 10, 2026. Star counts are popularity, not suitability; release cadence and last-push date are the signals that matter for a multi-year dependency.
The deprecation to state plainly: AutoGen and Semantic Kernel moved to maintenance mode in an announcement in October 2025, superseded by Microsoft Agent Framework 1.0, which reached general availability on April 3, 2026. AutoGen still shows roughly 60,000 stars — the accumulated authority of a project that was, for two years, the reference multi-agent implementation and the thing every tutorial demonstrated. That authority is now a trap: a search for "multi-agent framework" still surfaces AutoGen content written when it was live.
The community fork AG2 sits at roughly 4,800 stars — about 8% of AutoGen's following. Forks sometimes carry a project forward. An 8% signal is not evidence that this one has, and betting a production system on it means betting on a maintainer community you should go and look at directly before you commit.
How to actually pick a framework
The framework matters less than teams expect, because the hard parts — decomposition, context discipline, tool design, evals, cost attribution — are yours regardless of which library holds the loop. Pick on four criteria: the language your platform team actually maintains, whether the release cadence and last-push date suggest a live project, whether the state and checkpointing model matches your durability needs, and how much of the abstraction you would have to fight to get an unusual control flow.
One structural note on versioning: LangGraph is a monorepo with per-package tags, so there is no single "LangGraph version." That is precisely why comparison articles quoting one are unreliable — they are reporting a number that does not exist. On durability, an official integration between the OpenAI Agents SDK and Temporal reached general availability on March 23, 2026, providing crash-resume and replay. That is durable execution, not orchestration semantics — it will not decide your topology, but it removes a class of long-running-agent failure that people otherwise solve badly by hand.
MCP as the Integration Substrate
Whatever topology you choose, the agents have to reach systems. That layer standardized, and the reason it counts as a standard is governance rather than adoption.
On December 9, 2025, Anthropic donated the Model Context Protocol to the Agentic AI Foundation, a directed fund under the Linux Foundation. The AAIF was co-founded by Anthropic, Block, and OpenAI, with Google, Microsoft, AWS, Cloudflare, and Bloomberg supporting. Its founding projects are MCP, Block's goose, and OpenAI's AGENTS.md.
Adoption figures published at the time of the donation, and self-reported by the parties involved: 97 million-plus monthly SDK downloads across Python and TypeScript, up from roughly 2 million per month at the November 2024 launch; more than 10,000 active public MCP servers; and 75-plus connectors in Claude's directory. Deployment support comes from AWS, Azure, Google Cloud and Cloudflare. The specification repository shows around 8,900 stars, and the specification is date-versioned, with a revision dated July 28, 2026.
What MCP replaced is the part that matters architecturally: ad-hoc per-vendor function calling and bespoke plugin schemas. Before it, every integration was written against one provider's tool-calling format and rewritten when you changed models. That rewrite cost is what made model portability theoretical. It is now a genuine option, which changes the calculus on both sides of the multi-agent decision — a worker fleet on cheaper models is easier to justify when the tool layer does not have to be reimplemented per provider.
Two engineering cautions. First, an MCP server is an integration surface with real permissions; the tool-design principle above applies to it directly, and so does the trust-boundary problem covered in the limitations section. Second, date-versioned specifications move — pin the revision you built against and read the diff before you upgrade, the same way you would with any other protocol dependency.
Modelling What a Multi-Agent Design Actually Costs
Here is how to turn the 15× multiplier into a number you can put in a business case. All prices below are Anthropic list rates as of August 2026 and change frequently; re-check them against the pricing documentation before you commit anything to a spreadsheet.
Start from a published anchor rather than an invented one. Anthropic's own worked example for a customer-support workload is roughly 3,700 tokens per conversation on Haiku 4.5, or about $37 per 10,000 tickets. Take that as the chat-shaped baseline, apply Anthropic's own 4× and 15× multipliers, and price the result across the current lineup. The arithmetic below assumes an 80/20 input-to-output split, which is typical for tool-heavy work but is an assumption you should replace with your own measurement.
| Workload shape (per 10,000 tasks) | Haiku 4.5 ($1 / $5) | Sonnet 5 intro ($2 / $10) | Opus 5 ($5 / $25) | Mixed: Opus 5 lead + Haiku 4.5 workers |
|---|---|---|---|---|
| Chat baseline — ~3,700 tokens/task | $67 | $133 | $333 | — |
| Single agent — 4× = ~14,800 tokens/task | $266 | $533 | $1,332 | — |
| Multi-agent — 15× = ~55,500 tokens/task | $999 | $1,998 | $4,995 | $1,798 |
Directional cost arithmetic on Anthropic's published 4× and 15× multipliers, at August 2026 list prices per million tokens, assuming an 80/20 input-output split. This is a model, not measured data. Sonnet 5 introductory pricing runs through August 31, 2026 and rises to $3 / $15 from September 1, 2026 — which moves the Sonnet column up by half.
Read the table across, not down. A single Opus 5 agent at $1,332 per 10,000 tasks is cheaper than the mixed-model multi-agent system at $1,798, and less than a third of an all-Opus multi-agent design at $4,995. That is the decision in one line: multi-agent has to be worth roughly a 3.75× step up from the single-agent baseline, at whatever model tier you would otherwise have used. On research-shaped work it can be. On coding-shaped work it very rarely is.
The mixed column is also the most useful thing in the table. A stronger lead with cheaper workers — Anthropic's own configuration — costs less than an all-Sonnet mesh and 2.8× less than an all-Opus one, because the lead handles a small share of total tokens while doing the reasoning that matters. If you are going multi-agent, model tiering is the first optimization, not the last.
One provider-level note that materially changes long-context designs: as of August 2026, Anthropic applies no long-context premium— a 900,000-token request bills at the same per-token rate as a 9,000-token one, with caching and batch discounts available across the full window. Google's Gemini Pro models do the opposite, doubling input price above 200,000 tokens. If your architecture leans on very long single-agent contexts, that pricing asymmetry is a real input to provider choice.
Now the traps. Every one of these has produced a cost surprise on a real system, and several are specific to multi-agent topologies.
| Trap | The mechanic (August 2026) | Why it bites multi-agent systems specifically |
|---|---|---|
| Prompt caching floors are model-dependent and non-monotonic | Minimum cacheable prefix is 512 tokens on Opus 5, Fable 5 and Mythos 5; 1,024 on Opus 4.8 and Sonnet 5/4.6/4.5; 2,048 on Opus 4.7 and Haiku 3.5; and 4,096 on Opus 4.6, Opus 4.5 and Haiku 4.5. Below the floor it silently does not cache. | Multi-agent designs give each worker a small system prompt, which is exactly the shape that falls under the floor. You pay full input price and see no error. Check the floor for every model in the mesh, and consolidate worker prompts above it. |
| Cache write multipliers versus read | A 5-minute cache write costs 1.25× base input, a 1-hour write 2×, and a cache read 0.1×. Break-even is one read for the 5-minute TTL and two reads for the 1-hour TTL. Maximum four breakpoints per request. | Worker fan-out is the ideal caching shape — one shared prefix, many readers — but only if the workers actually hit the same prefix within the TTL. |
| Reasoning tokens bill as output | On both major providers, reasoning tokens are billed on the output side of the ledger, which is the expensive side. | A multi-agent system multiplies reasoning spend by the worker count. Measure reasoning tokens per role, not per system. |
| Claude Opus 5 adaptive thinking by default | Omitting the thinking parameter on Opus 5 now runs adaptive thinking, where the same request on Opus 4.8 or 4.7 ran with none. max_tokens is a single cap over thinking plus response text, and effort does not reliably shorten visible output. | Code migrated from an earlier Opus silently gains thinking spend and can truncate mid-answer — a failure that looks like a worker returning garbage rather than a budget problem. |
| GPT-5.6 reasoning context defaults to all_turns | GPT-5.6 defaults reasoning.context to all_turns, rendering earlier turns' reasoning into every subsequent request. Earlier models defaulted to current_turn. | A multi-turn agent's reasoning cost compounds silently across the session. On a long-running orchestrator this is the single largest unexplained line item we see. |
| The tokenizer shifted | Claude 4.7 and later, including Sonnet 5, use a tokenizer that produces roughly 30% more tokens for the same text. The per-token price did not change; the cost per request did. | Never re-baseline a cost model with a multiplier. Re-measure with the token-counting endpoint against your actual prompts. |
| Server-tool and runtime line items | Web search bills at $10 per 1,000 searches; web fetch is free; code execution gives 1,550 free container-hours per organization per month and then $0.05 per hour; Managed Agents session runtime is $0.08 per session-hour. | On a research-shaped multi-agent system, search calls are frequently the dominant cost, not tokens. Fan-out multiplies searches as fast as it multiplies tokens. |
| Surcharges that hide in deployment choices | US-only inference geography adds 1.1× across all categories on Claude 4.6 and later; Bedrock and Google Cloud regional endpoints carry a 10% premium; Fast mode on Opus 5 and 4.8 bills at $10 input and $50 output per million tokens. | These stack on top of the 15× multiplier rather than replacing it. Price the deployment, not just the model. |
| Advisory budgets are not caps | Session budgets for Managed Agents are a hard dollar cap enforced as a pre-request gate; the session pauses at budget_reached rather than terminating, and raising the budget resumes it. Task budgets, in beta, are advisory — a token countdown the model can see, with a 20,000-token minimum. The only hard per-request cap is max_tokens. | Teams routinely configure a task budget and believe they have a spend ceiling. They have a hint. Put the hard cap somewhere the model cannot negotiate with. |
Cost mechanics and reasoning-token traps at August 2026 pricing. Verify each against current provider documentation before building a model on it.
Two levers to apply deliberately. Batch processing takes 50% off both input and output and stacks with caching — and wide-and-shallow parallel worker calls that are not latency-critical are exactly the workload it was built for. It is under-used precisely on the architecture that benefits most. Context editing, available in beta, clears tool results and thinking from the request; the documentation's worked example reduces a 70,000-token input to 25,000, a 64% cut. The catch is that clearing tool results invalidates the cache prefix, so use the clear-at-least threshold to make sure the cache write you trigger is worth the tokens you saved. Anthropic recommends server-side compaction as the primary strategy regardless.
A Decision Procedure You Can Run in an Afternoon
Six questions, in order. A no at any point is a stop, not a caution — go build the single agent, ship it, and revisit when the workload has told you something you do not currently know.
| Question | The answer that permits multi-agent | What it means |
|---|---|---|
| Can you name the independent subtasks in advance, before the agent runs? | Yes, and they do not read each other's output | You are describing a decomposition. Orchestrator-worker is on the table. |
| Would two subtasks make conflicting implicit decisions if run apart? | No — the interface between them is fully specified | Splitting is safe. If yes, do not split; this is the Flappy Bird failure. |
| Does breadth create value, or is depth on one thread the value? | Breadth — more independent coverage is directly better output | Multi-agent. If depth, a single agent with compaction beats it at a fraction of the cost. |
| Can you afford roughly 15× the token spend of the chat-shaped baseline? | Yes, at your actual task volume, with the surcharges included | Model it before you build it. This is the most common reason a working prototype never ships. |
| Can each worker return under about 2,000 tokens without losing what matters? | Yes | The isolation is real. If no, you are paying for parallelism and getting a bigger context window. |
| Do you have per-agent token accounting and isolated-environment evals today? | Yes | You can operate it. If no, build those first — a multi-agent system you cannot attribute cost or failure to is not operable. |
Frenchy Digital single-versus-multi-agent decision procedure, 2026.
If you clear all six, build the orchestrator-worker version — and build it with three things in place from the start: an explicit fan-out cap, per-worker token accounting, and an eval suite that runs each trial from a clean isolated environment. Anthropic's evaluation guidance is direct about that last one: shared state between trials produces correlated failures and inflated scores. In a multi-agent system, shared state between trials is very easy to create accidentally, because the system already has shared state by design.
And measure reliability the way the workload will experience it. Sierra's τ-bench defines pass^k as all k trials succeeding, and reports GPT-4o below 50% pass^1 and around 25% pass^8 on the retail task set — roughly a 60% reliability drop that pass@1 reporting cannot show. A multi-agent system has more independent opportunities to fail per task, so this gap is wider, not narrower, than for a single agent. If your demo passes once, you have measured pass@1 on a sample of one.
The comparison almost nobody runs
Before committing to multi-agent, run the single agent with a matched token budget. Give it the same total spend the orchestrator-worker design would consume — more iterations, more retrieval, more reasoning — and evaluate both on the same task set with the same judge. Given that token spend alone explained 80% of performance variance on BrowseComp, a meaningful share of teams discover the gap they attributed to topology closes substantially. It costs a day, and it either saves you a quarter of engineering or gives you the strongest possible justification for the architecture.
Red Flags in Multi-Agent Proposals
These come from architecture reviews, vendor evaluations, and our own early mistakes. None are hypothetical.
| Red flag | Why it matters |
|---|---|
| "We use a multi-agent architecture" offered as a benefit, with no parallelism argument attached | Multi-agent is a cost, paid for a specific property. A vendor who cannot name which subtasks run independently is describing a diagram, not a design. |
| Sub-agents that need each other's intermediate output | This is the exact case both sides of the debate agree should not be split. Conflicting implicit decisions will produce output that is individually plausible and collectively wrong. |
| No per-agent token accounting | At a 15× multiplier you cannot manage what you cannot attribute. If the dashboard shows one number for the whole system, cost regressions are invisible until the invoice. |
| Sub-agents returning full transcripts to the lead | The condensed 1,000-to-2,000-token return is the entire mechanism. Returning everything reassembles the bloated context you paid to split. |
| A framework recommendation whose version numbers contradict the repository | Most 2026 comparison articles carry fabricated releases. Check the releases page and last-push date before the recommendation, not after. |
| AutoGen selected for a new 2026 build | Maintenance mode since October 2025, superseded by Microsoft Agent Framework 1.0. Choosing it means choosing a stalled dependency for a system with a multi-year life. |
| Benchmarks or demos reported as pass@1 | Agent reliability collapses under repetition. Sierra's τ-bench reports GPT-4o below 50% pass^1 and around 25% pass^8 on τ-retail — a reliability drop pass@1 cannot show. |
| Evals that reuse a shared environment between trials | Anthropic's eval guidance is explicit that each trial should run isolated from a clean environment; shared state produces correlated failures and inflated scores. |
| Model pinned to a floating alias | Behavior shifts with no commit and no rollback. In a multi-agent mesh the drift lands in whichever role happens to be most sensitive, and the symptom appears somewhere else entirely. |
| Handoff topology with no hop limit or cost ceiling | Peer-to-peer control transfer without a bound is an unbounded bill and an unbounded latency tail. |
| "Prompt injection is handled by the orchestrator" | Prompt injection is not solved by any architecture. A worker that reads untrusted content and returns to a lead that trusts it has collapsed the trust boundary, not defended it. |
The Frenchy Digital red-flag list for multi-agent architecture proposals, 2026.
Ask one question of any multi-agent proposal: which two subtasks run at the same time without needing each other's output? If the answer takes more than a sentence, the decomposition is not real and the architecture is a diagram.
— Frenchy Digital review principle
What It Costs to Build This Properly
These are the bands Frenchy Digital uses to scope agent engagements in 2026. They assume evaluation, observability and cost attribution are in scope from the start, because retrofitting them onto a running multi-agent system is where the budget actually goes.
| Engagement | Range | Timeline | Typical scope |
|---|---|---|---|
| Discovery + architecture review | $9k–$22k | 2–4 weeks | Workload-shape analysis, single-versus-multi-agent recommendation with a token model, framework and deployment selection, eval plan |
| Single production agent (one workflow, evals, observability) | $30k–$80k | 5–10 weeks | One agent end to end, tool design, compaction and memory strategy, tracing, offline eval suite in CI, cost dashboards |
| Multi-workflow agent platform with integrations | $80k–$200k | 10–18 weeks | Orchestration layer, MCP integrations, per-agent cost attribution, caching and batching strategy, regression evals, on-call runbooks |
| Enterprise / regulated build (SOC 2 posture, HITL, audit logging) | $200k–$450k+ | 16–26 weeks | Tenant isolation, human-in-the-loop review queues, append-only audit logging, injection test suites in CI, DR and rollback procedures |
Frenchy Digital cost bands for AI agent engagements, 2026.
Senior-led delivery runs $150 to $225 per hour, and ongoing retainers run $2,500 to $9,500 per month covering model and dependency upgrades, eval expansion, cost review, and incident response. Every engagement carries a 30-day post-launch warranty, and you receive a written scope with a fixed-price phased proposal within 5 business days of the discovery call.
One budgeting note specific to this architecture. The recurring inference bill is not a rounding error on a multi-agent system, and it does not appear in a build quote. Model it separately at your real task volume, using the table above, before you commit to the topology — a design that is 3.75× the single-agent run rate has to clear that bar every month for the life of the system, not once at launch.
Limitations and Honest Failure Modes
The evidence base underneath this entire debate is thinner than the confidence with which it is argued, including here. If you are building a business case, build it on the following.
- The strongest pro-multi-agent number is vendor-reported: Anthropic's 90.2% improvement is self-reported on an internal research evaluation, on a task family chosen for parallelism, with no third-party reproduction. It is good evidence for one workload shape and not a general result.
- The strongest anti-multi-agent argument is not a study: Cognition's post is an engineering position from a company building coding agents. Its authority comes from the mechanism it identifies, not from measurement.
- No independent token data exists: We could not find a non-vendor case study publishing real token-per-task figures for a production multi-agent system. The 4× and 15× multipliers are the best available numbers and they are directional.
- Cost-controlled evaluation is unflattering across the board: Princeton's HAL work, which released 21,730 rollouts across nine models and nine benchmarks at roughly $40,000 of compute, found that higher reasoning effort reduced accuracy in the majority of runs, and its live board notes agents that are 100× more expensive while only 1% better. Log inspection also caught agents searching HuggingFace for the benchmark rather than solving it.
- Elaborate scaffolds have failed this test before: Kapoor and Narayanan's AI Agents That Matter found that on HumanEval, the LATS agent architecture cost more than 50× a trivial retry baseline with no accuracy advantage. Complexity that is not cost-controlled has a poor track record.
- The scaffold often matters more than the model: On GAIA, bare-model, vendor-scaffolded and full-system leaderboards differ by 30 to 50 points. A published number about an architecture is frequently a number about someone's harness.
- Reliability is worse than single-run demos suggest: pass^k reporting exposes what pass@1 hides. More agents means more independent failure opportunities per task, so a multi-agent system's pass^k degradation is steeper than a single agent's.
- Most teams cannot yet operate what they build: LangChain's State of Agent Engineering survey (n=1,340, fielded November-December 2025, published June 2026) found 89% have some observability but only 52.4% run offline evals and 29.5% run none at all — and that is a vendor-run survey biased toward eval adoption.
- Prompt injection is not solved, and multi-agent widens the surface: Every worker that reads untrusted content is an injection point, and a compromised worker returns to the lead as trusted internal data rather than as external input. That trust-boundary collapse is the specific multi-agent risk. No mitigation makes an agent safe; the only defensible framing is defense in depth and blast-radius reduction — per-role tool allowlists, separation of read-capable and write-capable agents, treating every worker return as untrusted, and injection cases in CI. Map the design against the OWASP Top 10 for LLM Applications and the NIST AI Risk Management Framework.
- The frameworks will move under you: One reference implementation went to maintenance mode inside twelve months. Assume the same of whatever you pick, keep orchestration logic behind your own interface, and do not let a framework's abstractions become your domain model.
None of this argues against building agents. It argues for building the smallest architecture that solves the problem, instrumenting cost and reliability from the first commit, and treating every additional agent as a cost you have to justify rather than a capability you have added. The teams that get value here are the ones that measured the single-agent baseline before they replaced it.
And check the perishable facts. Prices, model names, framework versions and benchmark standings in this article are accurate as of August 2026 and will not stay that way. The reasoning will outlast the numbers; the numbers will not outlast the quarter.
Choosing Between One Agent and Many?
Book a free 60-minute discovery call with Frenchy Digital — a senior-led Black-owned LA agency. You leave with a workload-shape analysis, a token model for both architectures, and a fixed-price phased proposal within 5 business days. Call +1 (424) 272-5601.
Choosing Between One Agent and Many?
Book a free 60-minute discovery call. You leave with a workload-shape analysis, a token model for both architectures, and a fixed-price phased proposal within 5 business days.
1517 S Bentley Ave Unit 204, Los Angeles CA 90025
Frequently Asked Questions
Sources & References
- 1Cognition — Don't Build Multi-Agents (Walden Yan, June 2025)↗
- 2Anthropic Engineering — How we built our multi-agent research system↗
- 3Anthropic Engineering — Effective context engineering for AI agents↗
- 4Anthropic Engineering — Demystifying evals for AI agents↗
- 5Anthropic — Donating the Model Context Protocol and establishing the Agentic AI Foundation↗
- 6Anthropic — Claude platform pricing↗
- 7LangChain — How and when to build multi-agent systems↗
- 8LangChain — Context engineering for agents↗
- 9LangChain — State of Agent Engineering (n=1,340)↗
- 10Model Context Protocol — specification repository↗
- 11Microsoft AutoGen — repository↗
- 12LangGraph — repository↗
- 13CrewAI — repository↗
- 14OpenAI Agents SDK (Python) — repository↗
- 15AG2 — repository↗
- 16Princeton HAL — cost-controlled agent evaluation (arXiv:2510.11977)↗
- 17Kapoor & Narayanan — AI Agents That Matter (arXiv:2407.01502)↗
- 18Sierra — Benchmarking AI agents (τ-bench)↗
- 19OWASP Top 10 for LLM Applications↗
- 20NIST AI Risk Management Framework↗
- 21FinOps Foundation — FinOps for AI↗
