By Tsuky 
Enterprise AI applications increasingly resemble organizations composed of specialist workers.
A customer service system might contain one agent for classifying requests, another for billing, a third for shipping and another for drafting responses.
An orchestrator decides which specialist should handle each step.
The design appears intuitive because it resembles the way human teams divide responsibilities.
But the architecture also introduces problems that may not be visible in a demonstration.
Every handoff can add latency, cost and the risk of losing information.
Anthropic has published new guidance challenging the assumption that more specialized agents necessarily produce better systems.
Its central argument is not that subagents are obsolete.
It is that every subagent should justify its existence through measurable benefits.
When an agent architecture becomes an organizational chart
The article, written by Diane Sarkis, draws on observations from Anthropic's Applied AI team during enterprise deployments.
Organizations often divide AI systems according to departments or request categories.
A billing specialist handles payments, a shipping specialist handles deliveries and a troubleshooting specialist handles technical problems.
A central router decides which component receives each request.
This arrangement can simplify team ownership, but it may also reproduce the complexities of a human organization inside the software.
Different teams maintain different prompts, tools and evaluation criteria.
As the architecture grows, no single team necessarily takes responsibility for the complete user experience.
Anthropic connects this tendency to Conway's law, the observation that software systems often reflect the communication structures of the organizations building them.
An arrangement that makes sense for internal teams is not always the best arrangement for an AI model.
Every handoff can lose important context
Consider an application handling a delivery complaint.
One agent reads the request and identifies the order.
It sends a summary to a shipping specialist, which retrieves tracking information.
Another agent receives the result and prepares the response.
At every transition, information from the original conversation may be omitted.
A detail that seemed unimportant to the first agent could become essential to the next.
Anthropic compares this process to a telephone game in which details degrade as information passes between participants.
The problem is particularly serious when tasks depend closely on one another.
An agent that develops a plan understands why it made certain decisions.
Another agent receiving only the plan's summary may not have enough context to adjust it.
Keeping related work inside one execution loop can help preserve those connections.
One enterprise example ran approximately twice as fast
Anthropic cites observations from enterprise deployments to support its argument.
One company had built a customer-facing system with roughly a dozen specialist subagents.
The arrangement made it difficult to maintain a consistent brand voice and introduced undesirable latency.
In another example, comparing a multi-agent architecture with a single agent loop resulted in approximately twice the execution speed for the latter.
That finding is interesting but limited.
It is a customer observation reported by Anthropic, not an independent benchmark demonstrating that every AI application becomes twice as fast when subagents are removed.
Performance depends on the number of avoided model calls, the nature of the work and the overhead of coordination.
Systems that benefit from genuine parallel execution may produce very different results.
The proposed alternative is one agent with on-demand skills
Anthropic recommends considering a main agent loop as the foundation.
The agent receives an objective, creates a plan, calls tools, examines the results and continues until it produces an answer or reaches an execution limit.
The important change concerns how specialist knowledge is made available.
Instead of creating a separate agent for each business function, developers can package specialized procedures and instructions into skills.
A skill contains rules, processes and domain knowledge needed for particular work.
Its complete contents do not need to be loaded into the model's context at the beginning of every task.
The agent can initially see short descriptions and load more detailed instructions only when required.
Anthropic calls this progressive disclosure.
The same principle can apply to tools, which can be discovered and loaded according to the task.
The aim is to retain a shared reasoning process without filling the context window with hundreds of irrelevant instructions and functions.
Anthropic reports cutting Claude Code's system prompt by more than 80%
Anthropic points to changes made to Claude Code as an example.
The company says it reduced the system prompt for advanced models by more than 80%, partly by moving instructions into resources loaded progressively.
This does not mean that Claude Code automatically uses 80% fewer tokens for every task.
The system prompt is only one component of the context consumed during execution.
Retrieved documents, tool results, conversation history and generated outputs also contribute to usage.
The main benefit is avoiding the need to load rules that have no relevance to the current task.
The approach is becoming more practical as newer models handle more planning and tool-selection decisions themselves.
Some responsibilities previously assigned to dedicated routers and planners can move into the main loop.
Why shared context can improve answer quality
The quality of an agent's work rarely depends on a single operation.
An incident analysis may reveal unexpected information during investigation.
That information can change the original diagnosis and require further checks.
In a highly segmented architecture, the planning agent may have completed its work before another specialist discovers an important fact.
The system then needs additional handoffs or orchestration to update the plan.
With a single loop, the same agent retains the broader context of the investigation and its previous decisions.
It can adapt its strategy as new evidence appears.
Anthropic says several enterprise comparisons showed a main agent with skills outperforming certain multi-agent designs.
However, shared context creates its own challenge.
A context window can become too large, causing performance or efficiency problems.
Managing what stays in context therefore remains essential to the proposed architecture.
Subagents still matter for parallel work
Anthropic explicitly identifies situations where separate agents remain useful.
The first is parallel research.
Several independent sources or tasks can be examined simultaneously by different agents.
Their findings can then be returned as concise results to the coordinator.
The second is independent verification.
An agent writing code and another agent running tests may not need the same context.
A verifier that simply executes tests and reports the result can benefit from isolation.
A third reason is measurable performance degradation in a single loop.
If the main agent's context becomes too large or its instructions conflict, separate contexts may improve reliability.
Subagents can also support modular access controls and isolated execution environments.
The point is to validate their contribution through evaluation rather than add them by default.
Simpler orchestration does not eliminate security requirements
Using fewer agents can make permissions easier to manage, but it does not automatically make a system secure.
A main agent connected to many tools still requires technical safeguards.
Anthropic recommends keeping critical restrictions in the execution infrastructure.
These can include cost budgets, maximum step counts and approval requirements for sensitive actions.
Such controls should not rely exclusively on instructions given to the model.
If an action modifies data or initiates an important operation, the surrounding software can require authorization.
In a multi-user enterprise application, tools must also enforce each user's permissions.
A shared agent loop must not become a way to bypass account or data boundaries.
The proposed simplification concerns reasoning and orchestration, not the removal of access controls.
Fragmented evaluations can conceal failures
Anthropic identifies another problem with systems built by multiple teams.
Each group typically develops evaluations for its own specialist agent.
The order specialist measures order lookup accuracy. The shipping specialist evaluates tracking information. The returns specialist checks refund procedures.
High scores on these individual tasks do not guarantee the complete application resolves the user's problem.
A failure during a handoff may not appear in any specialist's isolated evaluation.
Anthropic therefore recommends shared end-to-end tests.
These should measure whether the entire system completes realistic user tasks.
Specialist tests remain useful, but they cannot replace the overall measure of success.
A small central team should maintain responsibility for the main system prompt and common quality standards.
Domain teams can continue maintaining their own skills and tools without continually expanding the shared prompt.
A public GitHub kit supports gradual migration
Anthropic has also published single-agent-loop-kit, a repository available through its official GitHub organization.
The reference project contains scripts, examples and guidance for examining an existing architecture.
The process starts with an inventory of subagents and how they interact.
Developers then establish baseline measurements for completed tasks, latency, model calls, token usage and cost.
The kit helps identify which agents could be merged, replaced by skills or exposed as tools.
Every change is followed by another evaluation.
If removing a subagent reduces performance, Anthropic advises keeping it or reconsidering the migration.
The repository includes a support-desk example with multiple specialists and a reference single-agent loop.
Importantly, the kit is guidance and sample code rather than a service that automatically converts every application into an optimal architecture.
Its README states that it is an unmaintained reference implementation provided without a guarantee of future support.
The migration kit is not universal proof
Anthropic has published example runs showing how parts of the kit behave in a demonstration environment.
However, the repository also documents limitations in the testing completed so far.
Certain steps have not been exercised using real models, and the kit has not been evaluated on arbitrary production systems.
Those limitations matter when interpreting its significance.
The kit provides a method for comparing architectures.
It does not establish that single-agent loops are universally superior.
Its most useful contribution may be encouraging teams to measure the effects of their architectural decisions.
An organization might discover that two specialists should be combined while a third remains valuable for independent verification.
The resulting architecture can be a simpler main loop supported by a few genuinely necessary specialists.
Why Anthropic is revisiting the question now
Improvements in AI models are part of the explanation.
Anthropic argues that newer models can manage longer tasks and make better tool-selection and planning decisions.
Architectures originally designed to compensate for limitations of older models may now be unnecessarily rigid.
Some work previously assigned to separate classifiers or planners can be handled directly by the main model.
This does not make the surrounding software irrelevant.
Access controls, data handling, execution limits and security checks remain essential.
The shift concerns where decision-making logic should live.
Should developers encode every step into a predetermined orchestration pipeline, or allow a capable main agent to adapt its plan?
The appropriate answer depends on model capabilities, task requirements and how predictable execution needs to be.
The recommendation is to measure before adding complexity
The October 22 guidance is not an announcement that Anthropic is abandoning subagents.
The company continues to document and support multi-agent features within Claude Platform.
Instead, it is challenging the assumption that every business function needs its own autonomous specialist.
The recommended process is pragmatic: measure the existing system, simplify one component at a time and retain the separations that deliver a demonstrated benefit.
For enterprises, the implications extend beyond a few seconds of latency.
Simpler architectures may be easier to maintain, evaluate and upgrade as models evolve.
But excessive simplification can also sacrifice parallelism or useful isolation.
Anthropic's conclusion is less dramatic than a new model announcement but potentially important for production AI systems.
More agents do not necessarily mean better agents. The number of components should follow the work the system needs to accomplish, not the complexity developers are able to build.