Ask a company to build an AI agent and, sooner or later, it builds an org chart. A router at the front, a planner behind it, a specialist agent for every team, and an orchestrator on top to keep them all in line. This week Anthropic said, politely, that a lot of these designs are doing work the model no longer needs done for it.
I have argued for small agent teams myself, so I read the guidance closely. Here is what it says, where I agree, where I still keep a split, and how I would decide for your own build.
What Anthropic said
On 22 October Anthropic's Applied AI team published a Claude Platform guide on when to fold subagents into your main agent loop. Across several enterprise deployments it compared, "a single agent with skills frequently outperformed both the one-prompt-for-everything design and the subagent design on quality, and often at a lower cost and latency per task." One customer that tested its multi-agent harness against a single agent loop saw a roughly 2x faster runtime.
The diagnosis will sound familiar to anyone who has worked in a large company. Each team ships its own subagent, so the architecture becomes "a copy of their org chart". The guide names the failure modes: subagent sprawl with no clear owner, the "Frankenprompt" where every team adds a sentence until the rules conflict, local evals that each team tunes for its own subtask, and a "telephone game" in which every handoff loses detail. MODEL summed it up neatly: AI agents reinvented middle management, and Anthropic is recommending a reorg.
The suggested design is one model and one context window running a tool loop, with turn and cost budgets and write gates set in the harness. Team know-how moves into skills that load only when needed. Actions and hard rules, such as validation, approval gates and per-user permissions, move into tools. Anthropic says it cut Claude Code's system prompt for more advanced models by over 80%, partly by loading skills and tools this way, and it warns that tool choice tends to degrade once you pass 30 to 50 tool definitions. It also released a migration kit on GitHub that walks a team through building a baseline eval and folding subagents in one at a time.
Subagents are not dead
The guide is careful here. It still recommends subagents in three cases: when a single loop measurably degrades from context bloat, when tasks need to run in parallel in fresh context windows that can be thrown away afterwards, and when one agent struggles to pick the right tools or has conflicting instructions. It also says subagents are effective at verification, parallel work and modular permissioning.
That last point is why the agent on my own site is still a small team. As I describe in the field report on the AI agents behind this website, a coordinator delegates to four specialists, each with only the tools it needs, running in parallel. In my design rules for agents inside real systems I put it simply: a specialist that cannot send an email cannot be tricked into sending one. Anthropic's answer is that the same separation can live in the tools instead: each tool checks what the calling user may see or do and returns a plain refusal. Both approaches put the limit outside the prompt, which is the part that matters.
The most useful warning in the guide
The best detail is a small one. When Anthropic tested folding on a sample support agent, latency dropped, but a process that had been passing broke: the main agent held the order lookup tool and answered on its own instead of asking the shipping specialist for the delivery date. The break showed up in only one run out of two.
That is how merges tend to go wrong: the final score barely moves, one important path quietly fails, and a single test run misses it. The fix is not clever. Write an eval task for every chain of agents that runs together in production and every rule the agent must not break, then run each task more than once.
How I would decide for your business
Most small businesses do not need an org chart of agents. A booking assistant, a document chaser or a lead qualifier usually works best as one agent with a clear prompt, a handful of tools grouped by what the user wants to do, and firm guardrails. Anthropic's own feedback on many proposed designs is that one clear system prompt, 4 to 5 thin data tools and firm output guardrails would cover most of the use case.
I would keep a separate agent where the job genuinely differs in risk or context: live research of untrusted web pages, long parallel tasks, or anything that should never hold a tool that writes. That is how I scope AI agent and connector projects. Not every step needs a model loop at all. As I wrote about the small decisions inside a workflow, routing and classification can often be a fast, cheap call rather than another agent.
A short checklist before you add another agent
- Is there a reason in the three cases? Context bloat you have measured, parallel disposable work, or tool confusion. "Another team owns it" is not one of them.
- Do you have a baseline eval? Even 10 golden examples, run more than once, before you change anything.
- Where do the hard rules live? Approvals, permissions and validation belong in tools or the harness, not in a sentence in the prompt.
- How many tools does the model see? Group them by user intent, not one per API endpoint.
- Who owns the system prompt? One small team, vetting every new tool, skill and eval.
- Can you change one thing at a time? Fold one subagent, compare which tasks flipped, keep it only if it scores better.
The principle Anthropic ends on is the one I would hold onto as models keep changing: measure, change one thing at a time, and keep what holds up. The architecture is less important than having the evals to prove it works.
You can see what a focused agent looks like on my live demos of working sample agents. If you are planning an agent, or untangling one that has grown too many layers, book a call with me and we will work out what really needs to be a separate agent and what should just be a tool.
Mubashir HussainForward deployed engineer