Anthropic Warns: Ditch Subagents for a Single Loop with Skills

Anthropic's article Building agents: When to fold subagents into your main agent loop challenges the popular pattern of a router dispatching to many expert subagents (order, logistics, refund, etc.). The author notes this architecture often replicates the company's org chart — Conway's law in the agent era — with each team owning a subagent, stuffing a line into the system prompt, and testing only its own slice.

Side-by-side comparison

Anthropic contrasts two designs:

Left (common in enterprises): five-layer stack — intent classifier → fixed multi-step reasoning pipeline → user-segmentation buckets → per-segment recommendation branches → top-level multi-agent scheduler.

Right (recommended): one loop — a clear system prompt, 4–5 thin data tools, and hard output guardrails.

In multiple enterprise deployments, single-agent + skills beat both "one big prompt" and "subagent" designs on quality while lowering per-task cost and latency. One customer measured ~2× speedup. A real case: a customer-facing agent with a dozen expert subagents suffered inconsistent brand tone and latency that hurt UX.

Five pitfalls of the subagent approach

Context management: which facts pass between agents? Details get lost in handoffs.

Subagent sprawl: every team publishes its own; hundreds overlap, lack standards, and have no clear owner.

Frankenprompt: each team adds a rule to the system prompt; rules clash, tone fragments.

Siloed evaluation: each team optimizes its sub-task score; no one owns end-to-end quality; leadership gets diluted local metrics.

Latency: more nesting = more model calls = slower.

The author relates to the Frankenprompt problem: Anthropic's own context-engineering post noted Claude Code's system prompt said "write docs appropriately," a skill said "don't add comments," and the user said "do as usual" — three conflicting instructions in one context.

A vivid analogy: splitting by problem type plays telephone — one writes code, another writes tests, another reviews; each handoff loses context. The correct split is by context : the implementer writes tests too because the context is already in their head; only an independent verifier that just runs tests and reports results deserves its own context.

Why folding back works now

The key enabler is progressive disclosure :

Context via skills: agent sees a one-line skill summary; full skill loads on demand.

Tools via tool search: tool definitions lazy-load when needed.

Three reasons this is newly viable:

Shared context yields better answers. One agent seeing all raw intermediate results stitches them together better than a chain of subagents returning lossy summaries.

Progressive disclosure solves context bloat. The old excuse — "one prompt would be too long" — no longer holds. Anthropic cut the Claude Code system prompt for Claude 5-series models by over 80% with no measurable loss on coding benchmarks, partly by moving code-review and verification into on-demand skills and tools.

Models got stronger. From Opus 4.5 onward, a single loop handles far more than most teams expect. Opus 5.5 and Fable 5.1 have non-disableable thinking, self-report progress, and self-check work, making parts of the framework layer redundant. Simpler loops also migrate to next-gen models more easily; rigid multi-agent structures often block new model capabilities.

Target single-loop architecture

One model, one context window, running an open-ended tool loop; hard limits (max turns, cost budget, write gates) enforced by the framework.

Each turn the model emits a batch of tool calls; framework executes them in parallel and returns raw results to the same model, which decides next step: more tools, ask user, or answer.

Stop on answer or budget exhaustion; optional targeted checker/verifier after answer.

Model writes its own plan in turn 1 and revises it as results arrive — unlike scheduler+expert where planner and executor are separate.

Procedures and domain playbooks go into skills ; hard constraints (validations, approval gates) and mid-conversation needs (e.g., memory lookup) go into tools .

Cheap, almost-always-relevant tasks (entity extraction) and purely mechanical work (request assembly, stream parsing) stay in code, wrapped as tools.

One-liner: give decisions to the model, give boundaries to the framework.

Three-step migration (plus step 0)

Step 0: Evaluate first. Even 10 golden cases suffice. Central team owns end-to-end eval; each team owns small skill-level evals. With a router, measure routing accuracy; after folding, measure correct skill/tool loading.

Step 1: Merge frequently co-executed subagents. If production traffic shows expert A almost always followed by expert B, they are tightly coupled — merge into one domain agent.

Step 2: Call subagents as tools. Don't rewrite; main agent invokes subagent as a tool, retains user dialogue, unifies response format, validates subagent conclusions with real data. Full handoff only when subagent must talk to user directly. This is transitional — each expert still has its own prompt, team, eval, and each call adds a nested model loop and lossy summary.

Step 3: Fold into skills and tools. One at a time: prompt → skill, API → MCP tool . Run eval before/after each fold to decide keep/discard.

Hard lesson: In a support-agent test, folding one subagent into another cut latency but broke a previously passing flow: the main agent, now holding an order-query tool, answered itself instead of asking the logistics expert for delivery date. Worse, the failure appeared in only 1 of 2 runs . Hence: eval must cover every production agent chain and every inviolable rule, and each task must run more than once . Look not just at aggregate score but at which tasks flipped — advice applicable to any agent project.

When subagents still belong

Anthropic's own multi-agent research system (lead researcher + parallel subagents) exemplifies valid cases. Keep a subagent if any condition holds:

Single loop shows measurable degradation from context bloat .

Multiple tasks need parallel execution, each with a clean context window, discarded after completion.

Single agent picks wrong tools or system prompt has conflicting instructions .

Anthropic's When to use multi-agent systems notes multi-agent typically costs 3–10× tokens ; parallelism buys coverage, not speed . The research-system post cites ~ 15× tokens vs. regular chat. Good subagents share: minimal context in, compact result out — independent research directions, clean-box components, black-box verifiers.

Multi-team ownership model

Teams no longer own agents; they own skills and tools. A small central team owns the system prompt and end-to-end quality; every new skill, tool, or eval passes through them.

MCP tools — Execute actions, read live data, return fixed-format results. Group by user intent, not one tool per API; >30–50 tool definitions degrades selection quality — use tool search for lazy loading.

Skills — How the team works: steps, rules, judgment criteria. Each team designates an owner, ships with evals, prevents skill sprawl.

Knowledge base — Occasionally used reference: policies, metric definitions, product specs. Behind a search tool or as skill reference files; don't stuff retrieved chunks into prompt via code.

Clever detail: preconditions and permissions live inside tools. If tool Y depends on X's output, Y checks and returns a model-readable instruction if missing. Permissions likewise: tool checks current user's access and returns explicit refusal if denied. One loop serves all permission levels — no per-role agents needed.

Official migration toolkit: single-agent-loop-kit

Open-source https://github.com/anthropics/single-agent-loop-kit — a Claude Code skill that walks "measure → merge → fold". Includes a support-desk mock: one router + six subagents with known correct answers.

Free offline smoke test (no API key):

cd single-agent-loop-kit/examples/support-desk
KIT_MODEL=fake python3 evals/run_eval.py --variant smoke

Produces 19 lines; fake model follows keyword rules so no scoring — real scores need true model per RUNBOOK.

Adopt in your repo:

git clone https://github.com/anthropics/single-agent-loop-kit
cp -r single-agent-loop-kit/skill <your repo>/.claude/skills/single-agent-loop

Then in your agent repo open Claude Code and say Run the single-agent-loop skill. It audits, labels each subagent fold, merge, call-as-tool, keep ; you correct, then fold one at a time, each change backed by eval comparison.

Practical design choices:

Pauses at four gates: post-audit, before any paid run, post-baseline, post-each-change; shows token estimate before paid runs.

Works without evals — asks for a safe test endpoint and some real requests to draft ~10 tasks.

Reads your orchestration code, framework-agnostic; notes stored in repo's single-loop/ directory.

Leverages existing Claude commands: /claude-api build-eval, hillclimb, prompt-audit, cost-optimize, /skill-creator, /skill-doctor.

Stated limitations (from README):

Reference implementation, not maintained, no contributions accepted — fork if you use it.

Real-model runs only twice on the example, one person, one model ; merge, maintain, from-scratch eval, and non-example systems untested on real models.

Skill wording changed after those two runs; new wording not fully re-validated.

The author appreciates this honesty over "one-click migration, 2× results" hype.

Summary

The article's value isn't just "single loop beats multi-agent" but the repeated method: measure, change one thing at a time, keep what survives scrutiny .

No subagents yet: don't split prematurely; start with one loop, add tools/skills as tests demand.

Already have many subagents: build a small end-to-end eval, start merging the most-called, tightest-coupled pair, then fold one by one.

Subagents doing parallel research, black-box verification, or reading huge context to return tiny conclusions: keep them — they earn their context.

Agent architecture evolution feels like scaffolding removal : each model advance lets you delete a framework piece. Today's carefully designed router, pipeline, segmentation may become tomorrow's wall blocking the new model. So instead of asking "do we need another expert here?" ask first: "Is this layer doing work the model already knows how to do?"