Single agent vs multi-agent is a trade-off between one shared context and several isolated ones. For many production setups in late 2026, Anthropic's Applied AI team now recommends defaulting to one agent loop with skills and tools loaded on demand, and keeping a subagent only when evals show it still beats the folded version — or when it truly needs its own context window, parallel runs, or permission isolation. That is the practical answer; the rest of this post is how to decide for your stack.
On 22 October 2026 Anthropic published Building agents: When to fold subagents into your main agent loop, arguing that enterprise agents with routers, planners and a subagent per team often lose quality, voice and speed to handoffs and "Frankenprompt" system prompts. The same week they shipped the single-agent-loop-kit on GitHub (Apache 2.0; README: reference implementation, not maintained, not accepting contributions). THE DECODER summarised the piece on 25 October, including Anthropic's note that one customer saw roughly 2× faster runtime on a single-agent loop than on their multi-agent harness in an internal comparison.
None of that means subagents are dead. It means the bar moved: newer models (Anthropic cites Opus 4.5 onward, plus Opus 5.5 and Fable 5.1) can carry more planning inside one loop, so a lot of harness code and org-chart architecture may be doing work the model no longer needs.
What changed in the single agent vs multi-agent debate
Multi-agent designs looked rational for a long time. Each team ships a specialist subagent; a central orchestrator routes intent; evals live next to each specialist. Conway's law, but for tokens.
Anthropic's write-up lists what that buys you in pain:
- Context loss at every handoff between agents.
- Subagent sprawl — hundreds of overlapping agents with no shared owner.
- Conflicting system prompts when every team adds a sentence.
- Local evals that optimise subtasks but dilute end-to-end quality.
- Latency from nested model loops; the ~2× runtime figure above is one datapoint from their customer comparison, not a guarantee for your workload.
Their counter-pattern is a single agent loop: one model, one context window, batched tool calls per turn, turn and cost budgets in the harness, and the model revising its own plan as tool results arrive — instead of a planner agent handing a lossy summary to a worker agent.
Progressive disclosure is the mechanism: short descriptions of skills and tools in context, full content only when the model selects them. Anthropic says that pattern let them cut Claude Code's system prompt for newer models by over 80%, partly by moving procedure into skills and actions into tools.
A single agent with skills and MCP tools
Skills and tools answer different questions. Anthropic's article is explicit:
- Skills — how a team does work: steps, rules, tone, edge cases. That is what used to sit in a subagent's long system prompt.
- Tools — what the agent can do: fetch live data, write with guardrails, call an API, or temporarily wrap a subagent you have not folded yet.
MCP fits on the tool side when the same integrations must work across hosts (Claude, ChatGPT, Cursor, your product). The model still chooses tools through ordinary function calling; MCP standardises discovery and execution. I wrote the layer cake in MCP vs function calling; the short version is that MCP does not replace tool use — it packages tools for reuse.
Anthropic also warns that tool choice degrades beyond roughly 30–50 tool definitions in the prompt at once. Mitigate with tool search, grouping tools by user intent, and preconditions inside the tool so the model gets a readable refusal.
One open-ended loop, procedure in skills, side effects in tools, and a small central team on the system prompt plus shared end-to-end eval — domain teams ship skills and tools with their own small evals, vetted before merge. Without that ownership, you get skill sprawl instead of subagent sprawl.
When a subagent still earns its place
Anthropic keeps subagents on the table when:
- Context bloat is measurable — the single loop's quality drops as history and tool output accumulate, and trimming or summarising is not enough.
- True parallelism — several heavy tasks need fresh context windows at the same time, then discard them.
- Tool or instruction conflict — one prompt cannot reliably pick among overlapping tools, or teams have written incompatible rules.
They also use subagents for verification, parallel research paths, and modular permissioning in their own multi-agent research system. The guidance is not "never subagent"; it is "stop giving every team a subagent by default."
Even when you keep one, the article prefers calling it as a tool from the main loop so the primary agent keeps the user thread. Full handoff is for when the specialist must talk to the user directly.
Single agent vs multi-agent at a glance
| Single agent loop | Multi-agent (orchestrator + subagents) | |
|---|---|---|
| Context | One window; shared history across steps | Separate windows; summaries passed between agents |
| Instructions | One system prompt + skills loaded on demand | Many prompts; risk of contradiction |
| Latency | One nested loop; parallel tools per turn | Often nested loops per subagent call |
| Parallelism | Parallel tool calls; sequential reasoning | Natural fit for parallel agents |
| Ownership | Central team on prompt + E2E eval | Easy to mirror teams; hard to maintain voice |
| Migration | Fold specialists into skills/tools incrementally | Already sunk cost in many prompts and evals |
| Best when | Most customer-facing and ops agents | Deep research, parallel paths, strict isolation |
Decision checklist: fold or keep?
Use this before you add another subagent — or when Anthropic's migration story lands on your roadmap:
- Does this work need its own context window? Deep research, long independent branches, or contexts you must discard after one task → subagent candidate. Everything else → try a skill first.
- Is the work truly parallel? If tasks must run at the same time with separate token budgets, subagents (or separate loop invocations) still make sense. If work is sequential but owned by different teams, that is not automatically parallel.
- Isolation or compliance handoff? Separate credentials, audit boundaries, or a verifier that must not see draft content → consider a dedicated loop or tool-gated subagent.
- Otherwise, fold it. Turn the subagent prompt into a skill, wire APIs as tools (MCP where reuse matters), run the shared eval, and keep the subagent only if scores drop.
Anthropic's support-desk example in the kit is instructive in the negative direction: folding one subagent lowered latency but broke a process that had been passing — the main agent answered shipping questions without calling the specialist. Their fix is boring and essential: eval tasks for every production chain and every rule that must not break, run more than once per task.
How to migrate one subagent at a time
You do not rewrite the fleet in a weekend. Anthropic's staged path:
- Task-completion evals — shared end-to-end set plus per-skill sets; ten golden tasks beats zero.
- Combine subagents that always run back-to-back on the same data.
- Subagents as tools — baseline on the eval before rewriting.
- Fold — prompt → skill, APIs → tools; compare scores; keep the subagent if the folded version loses.
The single-agent-loop-kit chains eval build, prompt audit, hillclimb and cost-optimize skills. README: reference implementation, not maintained.
Folding does not replace caps, idempotency or replay rules — see durable AI agents. For coding harnesses, Claude Code vs Codex is the parallel "one loop vs delegated queue" question.
Designing an agent architecture and want the eval set, tool boundaries and cost caps settled before you ship?
Costs and latency
Multi-agent setups pay nested model rounds and lossy handoffs — extra latency and input tokens even when the final answer looks fine. A single loop still needs good skill and tool descriptions and tool search; it is not automatic savings.
For build budgets see AI agent development cost; for token spend inside one loop, keeping Claude's token bill under control.
FAQ
What is the difference between a single agent and a multi-agent system?
A single agent is one model in one context window running an open-ended tool loop: it loads skills and tools on demand and keeps intermediate results in the same thread. A multi-agent system adds subagents — separate loops with their own prompts, tools and context — usually coordinated by a router or orchestrator. Multi-agent setups can parallelise work and isolate permissions; they also add handoffs, latency and duplicated instructions unless each subagent earns its place.
When should I use subagents?
Anthropic's guidance (October 2026) keeps subagents when a single loop shows measurable degradation from context bloat, when several tasks must run in parallel with fresh context windows, or when one agent cannot reliably choose tools or follow conflicting instructions in one prompt. If none of those apply, prefer folding specialist prompts into skills and their API calls into tools in the main loop, then compare on the same eval.
Are agent skills the same as MCP tools?
No. Skills hold procedural knowledge — steps, rules and judgment calls that used to live in a subagent's system prompt — and load when the model needs them. MCP tools (or plain function tools) are how the agent acts: read live data, call APIs, enforce permissions, or invoke a subagent you have not folded yet. Anthropic recommends skills for how a team works and tools grouped by user intent for what the agent can do.
How do I migrate from multi-agent to single agent without breaking production?
Build or reuse a shared end-to-end eval, then change one subagent at a time: turn its prompt into a skill and its integrations into tools, run the eval before and after, and keep the subagent only if the folded version scores worse. Anthropic's single-agent-loop-kit chains Claude API skills for evals, prompt audit and hillclimbing; it is Apache 2.0 and labelled a reference implementation that is not maintained.
I'm Joan Comadran, an AI engineer and full-stack developer in Barcelona (industrial engineering background). I write guides like this from vendor docs and shipped agent work — not from a fictional subagent migration on this site. If you want someone to draw the single-loop vs subagent line on a real product, that's what I do.
Originally published on joancomadran.dev. I'm Joan, an AI engineer in Barcelona — work with me.
Top comments (1)
A subagent keeps the big reads out of the parent, but its summary is billed again at each step that follows. Does your checklist weigh the size of that summary?