Share

13 min

The short version

A practical 2026 guide to choosing between one AI agent and a team of agents. It walks through verified benchmark numbers, real failure modes, the current vendor tooling, and a numbered decision procedure, so builders and curious readers can pick the architecture that fits their task instead of the hype.

Summarize with AI

Editorial Disclosure & Affiliate Notice

This content is published for informational and educational purposes only. It is not intended as a substitute for professional, legal, financial, or medical advice. AIUnpacker is funded through clearly labeled sponsored articles and reviews, relevant paid link placements, and affiliate commissions where disclosed. Commercial partnerships help fund the free editorial library. Sponsored work is labeled, and a payment does not change the verdict.

  • For educational purposes only. Nothing here should be taken as a guarantee, recommendation, or professional recommendation.
  • AI-assisted editing. Drafts are produced with AI assistance and get a human pass before they go up.
  • Opinions are our own. Also, we are not affiliated with most tools we cover unless explicitly stated.
  • Information may be outdated. Verify pricing, features, and policies directly with the vendor.
  • Last reviewed: . Published .

Read more on our About page, Terms and Editorial Policy.

For most tasks in 2026, one capable AI agent beats a team of agents, and the evidence keeps getting stronger. Google’s agent scaling study found that on sequential tasks, every multi-agent setup it tested performed 39-70% worse than a single agent, while the real wins for multi-agent systems show up on parallelizable, read-heavy work like research sweeps. Run one agent with deterministic scripts until you hit a measurable wall, then add read-only subagents or a clean-context reviewer, not a swarm.

What is a multi-agent system, exactly?

A multi-agent system is AI software where several independent agents (each with its own context window, model calls, and often tools) divide one job. The usual shape is the orchestrator-worker pattern: a lead agent breaks the task down, spawns workers, and merges their results.

Two distinctions matter. One agent calling tools repeatedly is still one agent: that’s just agentic AI, a model deciding its own steps in a loop. And a subagent is a worker that runs in a fresh context window: in the Claude Agent SDK, “intermediate tool calls and results stay inside the subagent; only its final message returns to the parent.”

Here’s the catch that runs through everything else in this article: because each subagent starts fresh, it knows only what the orchestrator told it. The failure modes come from that design choice, not from a bug you can patch.

Why do so many builders say “don’t build multi-agent systems”?

Because subagents can’t truly share context, so they make conflicting decisions without anyone noticing. That’s the core of Cognition’s “Don’t Build Multi-Agents,” published June 12, 2025 by co-founder Walden Yan. Two principles he calls “so critical, and so rarely worth violating”: “share context, and share full agent traces, not just individual messages,” and “actions carry implicit decisions, and conflicting decisions carry bad results.”

His examples are uncomfortably concrete: two subagents asked to build the same game produced clashing designs, one drawing a Super Mario-style background the other knew nothing about. Compressed briefs drop details, and nobody holds the full picture anymore.

The academic work backs this up. A UC Berkeley-led study, “Why Do Multi-Agent LLM Systems Fail?” (March 2025), annotated 1,642+ traces from frameworks like LangGraph and AutoGen and sorted failures into three buckets: specification issues (vague goals), inter-agent misalignment (miscommunication, duplicate or conflicting actions), and task verification issues (nobody checks the output). Their point: these failures are usually design failures, not model failures.

Reliability numbers make the same argument. On Sierra’s τ-bench, agents succeeded on fewer than half of tasks and scored under 25% on pass^8 in retail: the same task solved eight times in a row, failing more often than not even for GPT-4o-era models. The single-agent baseline was already humbling: CMU’s TheAgentCompany benchmark (December 2024) found the best agent completed just 30.3% of tasks autonomously, and GAIA (November 2023) showed humans at 92% versus 15% for GPT-4 with plugins. If one agent is that fragile, splitting a task across five semi-blind agents doesn’t obviously help.

When do multi-agent systems actually win?

When the work is parallelizable, read-heavy, and you can pay for it. Anthropic’s engineering post (June 13, 2025) described its Research feature: a Claude Opus 4 lead agent spawning three to five Claude Sonnet 4 subagents, each doing independent searches. That system beat a single-agent Opus 4 setup by 90.2% on Anthropic’s internal research evals, and parallelization cut research time by up to 90%.

But check the bill: multi-agent systems used about 15× more tokens than a standard chat, and token usage alone explained 80% of the performance variance Anthropic measured on its BrowseComp eval.

Anthropic says so itself (the architecture suits tasks where users pay for value, not latency- or cost-sensitive work) and it concedes where multi-agent was not effective: tasks needing shared context, with coding tasks named explicitly.

Google Research’s “Towards a Science of Scaling Agent Systems” (December 2025) made this predictable, running 180 agent configurations across five architectures, four benchmarks, and three model families. Centralized coordination improved performance by 80.9% over a single agent on financial reasoning tasks, but on the sequential planning benchmark, every multi-agent variant degraded performance by 39-70%. Independent architectures amplified errors by up to 17.2×; centralized designs contained amplification to 4.4×. Google’s predictive model picked the optimal architecture for 87% of unseen task configurations: architecture choice should be a measurement problem, not a vibe.

And in April 2026, Cognition’s Walden Yan published “Multi-Agents: What’s Actually Working,” conceding real patterns had emerged while keeping his guardrails. His summary line: multi-agent systems work best today “when writes stay single-threaded and the additional agents contribute intelligence rather than actions.” Three patterns made his list:

  1. Generator-verifier loops. Devin and Devin Review iterate against each other and catch roughly 2 bugs per pull request, about 58% of them severe. It works best when the reviewer shares no context with the coder: a clean-context reviewer reasons from the diff alone and avoids what Cognition calls Context Rot.
  2. “Smart friend” delegation. A primary agent calls out to a stronger model when stuck, turning delegation into a capability router.
  3. Manager/child delegation. A manager Devin splits large tasks across child Devins: workable, but only after substantial context engineering.

What stayed banned: parallel-writer swarms. Yan calls unstructured swarms of negotiating agents “mostly a distraction”; the practical shape is “map-reduce-and-manage.”

What changed in the 2026 tooling?

Multi-agent stopped being something you hand-roll and became a product feature. That cuts both ways.

On the consumer side, Anthropic launched Claude Cowork on January 12, 2026, a desktop agent for general knowledge work, and OpenAI launched ChatGPT Work on July 9, 2026, an agent “for longer, more involved tasks” powered by GPT-6, per OpenAI’s release notes. Neither markets an agent count; the decomposition happens internally. On the developer side, Claude Managed Agents entered public beta on April 8, 2026, and OpenAI’s Agents API entered public beta on September 10, 2026: a managed harness that “automatically compacts earlier context” near the limit and exposes delegation via settings like max_concurrent_subagents. You pay for tokens and tools.

Anthropic’s Claude Agent SDK (renamed from the Claude Code SDK in early 2026) is the most transparent about mechanics: up to 20 subagents running concurrently by default, nesting depth of 3, per-subagent tool restrictions, and budget caps via maxBudgetUsd because “a subagent can spawn subagents of its own, so one prompt can grow into a tree of agents.” Claude Code also gained experimental Agent Teams (a lead session with a shared task list for named teammates) while the docs steer “dozens to hundreds of agents” to the Workflow tool, which runs orchestration outside the conversation entirely.

In the framework layer, Microsoft Agent Framework hit 1.0 on April 3, 2026, uniting AutoGen and Semantic Kernel; LangChain’s own guidance positions LangGraph for production work needing durable execution and checkpoints, and CrewAI for fast role-based prototyping. And a November 2026 Capgemini report found 59% of financial institutions piloting or deploying multi-agent AI: only 10% have achieved full orchestration.

Single agent vs multi-agent: which fits your scenario?

Match the architecture to the task’s structure, not the hype. The most predictive property, per Google’s study: does your task decompose into independent, parallelizable chunks, or run as one sequential chain? Here’s how common scenarios shake out:

ScenarioLean towardWhy
Scheduled reports, data pulls, file renamesSingle agent or plain scriptFixed steps need little judgment; scripts cost no tokens
Customer support with written policiesOne agent, tightly scoped toolsConsistency is the product; pass^k scores collapse on repeated identical tickets
Broad research sweep across dozens of sourcesMulti-agent, read-only subagentsParallelizable and read-heavy: the profile where Anthropic measured a 90.2% lift
Code changes in one shared codebaseOne single-threaded agentParallel writers make conflicting implicit decisions; Cognition’s original failure mode
Reviewing finished work (code, docs, contracts)Generator-verifier pairA clean-context reviewer catches subtle issues; Cognition measured ~2 bugs per PR, ~58% severe
Huge refactor with truly independent modulesManager + child agents, with verificationMap-reduce-and-manage works when units are independent and checkable
Fixed multi-step document pipelineDeterministic workflow, minimal AIAnthropic’s guidance: workflows for well-defined tasks where predictability matters

One caveat on those wins: the Composio Golden Eval in July 2026 (47 real business-app scenarios, where Claude Cowork on the Fable 5 model passed all 47 and ChatGPT Work passed 45) tested finished products, not architectures you assemble. Those scores come from third-party coverage, so treat them as directional. The instructive detail: ChatGPT Work’s two losses were exact-number miscounts (95 breached tickets instead of 3; 186 users instead of 181). More agents wouldn’t have fixed either; stricter verification might have.

What failure modes should you price in before adding agents?

Three costs recur across every credible source, and none are hypothetical.

Context-sharing losses. Subagents act on summaries, not full histories. Cognition’s remedy is blunt (“share full agent traces, not just individual messages”) but sharing full traces with every worker multiplies token cost fast. Manager agents, per Yan’s 2026 follow-up, still “default to over-prescription” and assume they share state with their children.

Error amplification. Agents inherit and compound each other’s mistakes. Google measured it directly: independent architectures amplified errors by up to 17.2× versus 4.4× for centralized designs, and retries across multiple agents can pile load onto a struggling system.

Coordination cost. The 15× token multiplier is the headline, but latency matters too: a review loop can cycle through multiple rounds before anyone ships. And there’s a people cost: the MAST taxonomy found failures cluster in specification and verification: writing precise briefs and building real checks: exactly the discipline teams skip when they’re excited to spawn agents. The docs don’t give a universal rule. If you can’t say what each added agent buys you in a measurable eval, you’re paying the coordination tax for nothing.

The decision procedure to follow

Work down this list; most people should stop at step 3.

  1. Classify the task’s structure. Parallelizable and read-heavy (research, multi-doc review)? Sequential and write-heavy (coding, drafting, anything where later steps depend on earlier ones)? Google’s data says this one property predicts whether a team helps or hurts.
  2. Build the dumbest thing that could work first. A script, a scheduled automation, or one agent with a handful of good tools. Anthropic’s advice still holds: “optimizing single LLM calls with retrieval and in-context examples is usually enough.”
  3. Hit a wall? Name it precisely. Context overflow, speed, quality, or scope. “It feels slow” is not a wall; “the agent can’t read 40 documents without losing the question” is.
  4. Context overflow or speed → read-only subagents. Offload gathering to subagents in fresh contexts: up to 20 concurrent in the Claude Agent SDK, each returning a summary. Three to five in parallel was Anthropic’s research sweet spot.
  5. Quality problems → add a clean-context reviewer. One agent writes; a second reviews with no shared history, bridged so it understands real user intent. This is the pattern Cognition found working even for tightly coupled work.
  6. Only now consider orchestrator-workers. Keep every write single-threaded, use centralized coordination (4.4× error amplification beats 17.2×), and prefer managed harnesses over hand-rolled plumbing.
  7. Cap the spend and the blast radius. Set budget limits (maxBudgetUsd), limit nesting, restrict subagent tools, and put a human checkpoint before anything irreversible.
  8. Evaluate with repeated trials, then compare against your single agent. Run the same eval pass^k-style (same task, multiple runs, counting only full successes) because one lucky run is how multi-agent projects get approved and then disappoint. If the team can’t beat the single agent on identical evals, kill it without sentiment.

What to do next

No code? Try ChatGPT Work or Claude Cowork on your messiest multi-step task and judge the output, not the architecture. The agent count is their problem, not yours.

If you do write code: start with one agent in the Claude Agent SDK or OpenAI’s Agents API, add read-only subagents when context or speed binds you, and treat generator-verifier review as the first “team” worth building. At enterprise scale, budget for orchestration infrastructure: the Capgemini data suggests that’s where deployments stall. Whatever you build, evaluate it the boring way: same task, repeated runs, counted honestly.

Pricing, betas, and model names all shifted during 2026: re-check the primary pages before committing budget, and treat anything with legal or financial consequences as a case for professional review.

FAQ

What is a multi-agent system in AI?

AI software where several independent agents (each with its own context window, model calls, and tools) work on parts of one job. A lead agent (orchestrator) breaks the task down, hands subtasks to workers, and combines their results. A single-agent setup runs the whole job in one continuous conversation.

Is one AI agent better than a team of agents?

For most tasks, yes. Google’s 2025 agent scaling study found every multi-agent variant degraded performance 39-70% versus a single agent on sequential planning tasks. Multi-agent only won clearly on parallelizable, read-heavy jobs, where centralized coordination improved results by about 81%. Choose one agent until you measure a wall.

How does a multi-agent system work?

The common design is orchestrator-worker: a lead agent decomposes the request and spawns worker subagents, each running in a fresh context with its own tools. Anthropic’s research system used a Claude Opus 4 lead with three to five Claude Sonnet 4 subagents in parallel, then merged their findings.

How much does a multi-agent system cost?

Expect roughly 15x the token usage of a standard chat, per Anthropic’s June 2025 measurements; agents in general use about 4x. Costs multiply because each subagent makes its own API calls and can spawn more. The Claude Agent SDK offers budget caps like maxBudgetUsd; OpenAI’s Agents API bills tokens and tools only.

What are the main alternatives to a multi-agent system?

In order of simplicity: deterministic scripts and scheduled automations; fixed workflows where an LLM handles steps along predefined code paths; and a single agent with retrieval and good tools. Anthropic’s guidance says optimizing single LLM calls with retrieval and in-context examples is usually enough; workflows fit predictable tasks.

Are multi-agent systems worth it for beginners?

No. Beginners do better with products that hide the architecture, such as ChatGPT Work or Claude Cowork, which decompose tasks internally. If you’re learning to build, start with one agent and a few tools, then add subagents only when a measured problem demands them.

What are the main failure modes of multi-agent systems?

Three documented buckets from Cognition and the MAST research taxonomy: context-sharing losses (subagents act on summaries and make conflicting implicit decisions), inter-agent misalignment (miscommunication, duplicate or conflicting actions), and weak task verification. Google measured error amplification up to 17.2x for independent architectures, and coding tasks suffer because they need shared context.

Can multi-agent systems be used commercially?

Yes. Managed offerings like Anthropic’s Claude Managed Agents (public beta since April 2026) and OpenAI’s Agents API (public beta since September 2026) are commercial products billed by usage. Open-source frameworks such as LangGraph and the Microsoft Agent Framework are licensed for commercial use, but terms vary by project, so check each one.

How can I get better results when using multiple agents?

Keep every write action in one single-threaded agent and let extra agents contribute intelligence rather than actions: the pattern Cognition found working in April 2026. Use clean-context reviewers, restrict subagents to read-only tools where possible, share full traces rather than thin summaries, cap spending, and evaluate with repeated trials.

What should I build first: one agent or a team?

One agent, with deterministic scripts doing anything predictable. Measure where it fails: context overflow, speed, or verification quality. Then escalate: read-only subagents for gathering, a reviewer agent for checking, and only then a managed orchestrator-worker setup with single-threaded writes and a budget cap.

Sources

Weekly digest

Get our weekly AI digest

The latest AI tools, prompts, and insights — short, useful, every week.

No spam. Unsubscribe anytime.

AIUnpacker Editorial

Articles are written for a specific question. Sponsored work is labeled.