# Should you build one agent loop or a team of subagents?

Date: 2026-10-23 · Author: Robert Scales · https://guidetoartificialintelligence.com/en/learn/one-agent-loop-or-subagents/

**Answer:** Anthropic's October 22, 2026 guide argues that many company agents built as a router plus specialist subagents do better as one agent loop that loads skills and tools only when needed, and it ships an open-source kit to make the move one measured step at a time. Subagents still make sense for parallel work in fresh context, independent checking, or when one loop measurably degrades, and the evidence so far is Anthropic's own reports and two small recorded runs.

On October 22, 2026, Anthropic published a guide for companies building agents on its platform: [“Building agents: When to fold subagents into your main agent loop”](https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop). Its message is that many agents were built with more moving parts than today's models need. Instead of a front-door router that hands each request to one of a dozen specialist agents, Anthropic suggests one agent, in one conversation, that pulls in the instructions and tools it needs as it goes. A companion repository, the [single agent loop kit](https://github.com/anthropics/single-agent-loop-kit), walks a team through that change and measures each step.

This is a design question every agent builder faces, so it is worth separating what the guide argues, what evidence it offers, and where other experienced builders and Anthropic's own earlier work point the other way.

## The two designs in plain words

An **agent loop** is a model working in cycles: it reads the situation, calls tools (search, a database, a calculator), looks at the results and decides the next step, until it answers or runs out of budget.

A **subagent** is a second agent the main one hands a job to. It has its own instructions, its own tools and its own **context window**, the working memory a model carries through a task. When it finishes, it sends back a summary. A common company design puts an **orchestrator** or router on top and a set of specialist subagents underneath: one for orders, one for shipping, one for returns.

The design the guide favors is a **single agent loop with progressive disclosure**. The one agent sees only short descriptions of its **skills** (folders of instructions for how a team does a kind of work) and its tools. It loads the full skill or tool definition only when a task calls for it, so the starting prompt stays short even when the agent covers many areas.

## What the guide argues

Anthropic says its Applied AI team compared designs across several enterprise deployments, and that a single agent with skills often beat both a giant all-in-one prompt and the subagent design on answer quality, frequently with lower cost and waiting time per task. It gives three reasons:

1. **Shared context gives better answers.** An agent that saw every earlier step can connect them. Subagents hand back summaries, and each handoff loses detail.
2. **Progressive disclosure removes the old reason to split.** Teams split work across subagents largely because one prompt could not hold everything. Loading on demand fixes that. Anthropic says it cut Claude Code's system prompt for its more advanced models by over 80%, partly this way.
3. **Models can now manage more.** Anthropic says that from Claude Opus 4.5 on, models handle far more in one loop than most teams expected, and that rigid multi-agent structures often stopped newer models from doing more of the work.

It also names the ways big organizations go wrong when each team builds its own agent: context lost between agents, hundreds of overlapping subagents nobody owns, a shared system prompt where every team added a rule until they conflict, and narrow tests that each team tunes for its own piece. The guide puts it as the architecture becoming a copy of the org chart. One customer, it says, measured a single loop running roughly twice as fast as its multi-agent version.

## When subagents still win

The guide is explicit that subagents keep their place. It recommends them when:

- one loop shows **measurable** decline because its context has grown too large;
- several tasks should run **in parallel**, each in a fresh context that can be thrown away afterward;
- one agent **struggles to pick the right tool**, or its instructions conflict.

The kit adds **independent verification** (a checker that has not seen the worker's reasoning) and work that reads far more material than the main agent needs to keep. If you do split, the guide's advice is to divide by context, not by problem type: hand a subagent a self-contained job that depends little on everything else and sends back a short result, such as a separate research path or a component with a clean interface.

Here is how the guide maps the pieces of a typical multi-agent system onto one loop:

| In a router-and-specialists design | In the single loop |
|---|---|
| A planner or code step that builds the plan from a rule catalog | The model writes and revises its own plan in context |
| Each specialist's prompt: steps, rules, judgment calls | A skill, loaded when needed |
| Each specialist's API calls | Tools (often MCP tools), grouped by user intent |
| Hard rules such as approvals and validation | Checks inside the tools, which return a plain refusal the model can read |
| Per-user permissions | Every tool verifies what the current user is allowed to see or change |
| Reference documents | A knowledge base behind a search tool, or files inside a skill |
| Overall limits | Turn and cost budgets and **write gates** (a rule that a change to data needs approval) in the harness, the code around the model |

The loop itself: on every turn the model asks for several tool calls at once, the harness executes them side by side, and the raw results go back to that same model. It stops when the model answers or a budget runs out, and a verifier can check the answer afterward. Two practical limits from the guide: keep tools grouped by user intent, because choosing among more than about 30 to 50 tool definitions tends to get worse, and keep one small central team in charge of the system prompt and the shared tests.

## The migration steps, with a worked example

The guide does not ask for a rewrite. Its sequence:

1. **Build an end-to-end eval first.** An **eval** is an automated test set for an AI system. Ten "golden" examples with known good outcomes is enough to start. While a router exists, also check whether it picked the right subagent; after a fold, check whether the agent picked up the correct skill or tool.
2. **Merge subagents that always run together.** If a large share of traffic is specialist A followed by specialist B, they are a candidate to become one.
3. **Call kept subagents as tools.** The main agent keeps the conversation and gets a structured result back, instead of handing the user over.
4. **Fold one subagent at a time** into a skill plus tools, rerun the same eval, and keep the subagent only when the folded version does worse on that eval.

The worked example in the guide shows why step 4 needs care. In a sample support agent, folding one specialist in made it faster but broke a task that used to pass: the main agent now held the order lookup tool and answered a delivery question itself, without asking the shipping specialist for the actual date. That failure appeared in only one of two runs. So the guide's advice is to look at which individual tasks flipped, not just the total score, to make sure the tests cover each chain of agents that real traffic uses and each rule the agent has to respect, and to run each task more than once.

## What the kit does, and what it has not shown

The kit is a Claude Code skill plus scripts, under the Apache 2.0 license, marked as a reference implementation that is not maintained. It audits a repository and gives each subagent one of four verdicts: fold it in, merge it with another, call it as a tool, or keep it. Then it works through one change at a time, running the eval before and after. It stops for a person at fixed points: after the audit, before any run that costs money (with a token estimate), after the baseline, and after each change. Its scripts find which subagents run together in traces, compare two runs on completion rate, latency, model calls, tokens and cost, and check that the eval covers every production chain of subagents.

It includes a small support-desk example with a router and six subagents, and a free offline smoke test that uses a keyword-based stand-in instead of a real model. That test only proves the plumbing works; it is not scored.

The kit's README is unusually frank about its evidence. Only two runs on a real model are recorded, by one person, on one model, using 12 and then 17 tasks with mostly two repetitions each. The measured results were removed from the published write-ups. Several parts have never met a real model: the merge step, the upkeep step, the completed one-loop version of the example, and any system other than that example, and the skill's wording changed after the last run. One run's own notes say two repetitions were too few to decide, and the person needed 16 more conversations before keeping the change.

## Other views

The case for one loop is not new, and not everyone has drawn the same line.

- **Anthropic's own research agent uses subagents.** In June 2025, Anthropic described its multi-agent research system, where a lead agent starts subagents that search in parallel. On its internal research test, that design beat a single agent by 90.2%, at roughly 15 times the tokens of a chat. It also said tasks where agents share a lot of context, like most coding, fit multi-agent designs poorly. The new guide is consistent with that: research with independent paths is one of the cases where it still recommends subagents.
- **Cognition argued against multi-agent designs in 2025.** In a June 2025 post titled "Don't Build Multi-Agents", Cognition, which makes the coding agent Devin, argued that parallel subagents make conflicting assumptions and that a single-threaded agent with shared context is more reliable. That is close to Anthropic's new position, reached by a competitor more than a year earlier.
- **The evidence is a vendor's.** The guide's quality, cost and speed claims come from Anthropic's comparisons with its own customers, with one approximate figure (twice as fast for one customer) and no published data set. The guide frames them as patterns it has seen, and its closing advice is to measure on your own system rather than adopt a design on faith.

## How do you test the change on your own agent?

Start with the eval, not the architecture. Write ten real requests your agent handles, and for each one write down what a correct outcome is, in terms a script or a strict rubric can check: the right refund amount, the right tool called, no data changed without approval. Include at least one request that crosses two specialists, and one that should be refused. Run the current system on all ten, at least three times each, and save the scores, latency and cost. That is your baseline.

Then pick one subagent: the guide suggests starting with the ones used most, while the kit's example starts with the smallest so the change is easy to watch. Turn its prompt into a skill and its API calls into tools the main agent can call, run the same ten requests three times, and compare task by task. If any task flipped from pass to fail, read that transcript before deciding. Keep the fold only if it holds up, then repeat with the next subagent.

You can use a prompt like this to start the audit:

```prompt
Here is the code (or a description) of my agent: [paste the router, each subagent's prompt and its tools].
For each subagent, tell me:
1. Which other subagents it is usually called with, and whether it needs their results.
2. Whether it does work that benefits from a fresh, separate context (parallel research,
   independent checking, reading lots of material the main agent does not need afterward).
3. Your verdict: fold into a skill plus tools, merge with another subagent, call as a tool,
   or keep as is, with one sentence of reasoning.
Then list the requests I must include in my test set so that a broken handoff would show up.
```

> **Try it:** Pick one handoff in an agent you run, write five test requests that go through it, and run them three times before and three times after folding that subagent in. Note any task that passed once and failed once; that is the kind of break a single run hides.

If you have no subagents yet, the kit's own advice is to start with one loop and add tools and skills only as testing shows you need them. For the split-work side of the question, see [what sub-agents are and when to split work across them](/en/learn/sub-agents-split-work-across-them/) and [how to build a multi-agent workflow](/en/learn/build-multi-agent-workflow/).

## Sources

- Building agents: When to fold subagents into your main agent loop: https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop
- Single agent loop kit (README and example runs): https://github.com/anthropics/single-agent-loop-kit
- How we built our multi-agent research system: https://www.anthropic.com/engineering/multi-agent-research-system
- Don't Build Multi-Agents: https://cognition.ai/blog/dont-build-multi-agents

---

From the Guide to Artificial Intelligence, by Robert Scales, published by Holistic Hybrid Inc. Share and adapt it under CC BY-NC-SA 4.0 (https://creativecommons.org/licenses/by-nc-sa/4.0/): credit the guide, link to https://guidetoartificialintelligence.com/en/learn/one-agent-loop-or-subagents/, no commercial use without permission, and keep the same licence.