Building agents: When to fold subagents into your main agent loop

Anthropic's Applied AI team launched a migration kit on Claude Platform to help enterprise engineering teams fold multi-agent setups into a single agent loop. The kit provides a guided workflow to inspect architectures, evaluate alternatives, and test configurations on a mock system before modifying live deployments. According to claude.com's report, folding routers, planners, and domain subagents into one main loop frequently beats multi-agent designs on quality, cost, and latency.

This report details why organizations are replacing nested subagent hierarchies with single-loop architectures driven by progressive disclosure of skills and tools. It examines how multi-agent frameworks created operational bottlenecks, why modern foundation models render external orchestrators obsolete, and where subagents remain technically necessary. The analysis is structured for platform architects and machine learning engineers managing production agent fleets.

Building agents: what actually changed

Enterprise engineering teams previously treated subagent sprawl as the default pattern for complex corporate deployments. Large organizations distributed tasks across separate business units, assigning dedicated subagents to every domain, customer-support segment, and analytical workflow. This structure mirrored internal org charts under Conway's law, with platform teams layering an orchestrator over intent classifiers, fixed multi-step reasoning pipelines, user-segment buckets, and recommendation branches. However, production feedback revealed that modern models no longer require elaborate external harness pipelines to handle straightforward routing and task planning.

In practice, folding domain subagents into a unified loop produced measurable gains in operational performance and user experience. One enterprise operating a customer-facing agent reported that coordinating a dozen specialist subagents created an inconsistent brand voice and added latency. In benchmark evaluations comparing a multi-agent harness directly against a single agent loop, another customer recorded a roughly 2x faster runtime with the consolidated loop. Anthropic demonstrated this shift internally by reducing Claude Code's system prompt by over 80 percent through progressive disclosure of skills and tools.

Building agents: how it works

The recommended single agent architecture runs one foundation model inside a single context window executing an open-ended tool loop. Operational limits, including turn budgets, cost caps, and write gates, are strictly enforced by the surrounding harness rather than by intermediate coordinator agents. On every interaction turn, the model emits a batch of tool calls that the harness executes in parallel before returning raw results directly to the same model. The model then evaluates output to decide the next step, whether issuing another tool batch, requesting clarification, or providing an answer.

Instead of relying on external orchestrator code to parse rules, the model writes its plan directly into context on its initial turn and updates it as tool results return. Domain procedures and ordering logic transition into skills, while hard validation requirements, approval gates, and mid-conversation memory lookups move into tool implementations. The system manages context through progressive disclosure, presenting the agent with concise descriptions of skills and tools through tool search. Full instructions load only when required, preventing context bloat while keeping all historical execution data in one place.

Building agents: why it matters now

Architectural upgrades in foundation models have rendered complex multi-agent scaffolding redundant. Starting with Opus 4.5, models gained the capacity to manage significantly higher reasoning density within a single loop than early designs permitted. Subsequent releases, including Opus 5.5 and Fable 5.1, incorporated mandatory internal reasoning that cannot be disabled, enabling models to continuously narrate progress and verify their own work mid-turn. These built-in reasoning mechanisms eliminate the need for hardcoded planner-critic harnesses, allowing engineering teams to shift operational decision-making out of brittle harness code into the model.

Retaining monolithic multi-agent systems now directly impedes software maintenance and migration to future models. Rigid multi-agent harnesses prevent engineering teams from exploiting the expanded autonomy of newer model generations, requiring manual re-engineering of prompt boundaries across micro-services. Furthermore, passing structured state between multiple subagents triggers an information telephone game where summaries degrade context fidelity at every handoff. Maintaining shared context in one primary window provides the model with complete visibility over prior steps, producing richer analytical connections and coherent outputs without the cumulative token overhead of multiple context windows.

Building agents: who is affected

The architectural shift directly impacts enterprise software organizations where autonomous engineering teams independently deploy specialist subagents without central oversight. When multiple teams contribute disjointed rules to a single interface, systems degrade into a Frankenprompt with conflicting instructions and no consistent brand voice. Furthermore, decentralized teams often ship unvetted, overly localized evaluations optimized exclusively for narrow subtasks. Because no single entity maintains the overall evaluation suite, leadership teams make strategic deployment decisions based on diluted benchmarks that obscure end-to-end degradation across the broader customer experience.

To resolve these organizational failures, companies must assign a small, centralized platform team to govern the global system prompt and end-to-end quality standards. This dedicated team evaluates and vets every new tool definition, skill integration, and evaluation benchmark before staging code for production. Keeping this governing body compact lowers cross-departmental coordination costs and accelerates release velocity. For organizations that still deploy multi-agent setups via the Model Context Protocol or custom orchestrators, migration requires refactoring disparate agent endpoints into clean tool interfaces managed under centralized prompt governance.

Building agents: what to watch

Engineering teams should establish strict criteria for determining when subagents remain technically justified rather than default architecture. Multi-agent designs remain appropriate when an agent experiences measurable performance degradation from extreme context bloat, or when handling parallel workloads requiring disposable context windows that discard after execution. They are also necessary when an agent struggles with tool selection under contradictory instructions. In such scenarios, developers should implement minimal patterns like generator-verifier loops or clean orchestrator-subagent boundaries, isolating components by distinct context requirements to ensure subagents return compact results without telephone game degradation.

Organizations adopting single-loop architectures must monitor system prompt hygiene and context budgeting closely. Progressive disclosure reduces initial prompt payloads, but teams must maintain precise skill descriptions and tool search indices so models retrieve relevant utilities without hallucinating selection criteria. Platform teams should implement rigorous task-completion evals before dismantling existing orchestrators, benchmarking latency, token consumption, and failure rates on mock environments. As model architectures continue to absorb planning and execution duties, simpler agent loops will ensure enterprise harnesses remain adaptable to upcoming foundation models without structural harness overhauls.