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.
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:
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.
Skills and tools answer different questions. Anthropic's article is explicit:
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.
Anthropic keeps subagents on the table when:
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 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 |
Use this before you add another subagent — or when Anthropic's migration story lands on your roadmap: 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.
You do not rewrite the fleet in a weekend. Anthropic's staged path:
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?
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. 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.
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.
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.
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.