More agents isn't always better: folding specialist subagents into one loop often raised quality and cut latency

A reverse pattern is appearing in enterprise agent architecture: routers, planners and domain subagents get merged into one main agent loop instead of adding another orchestration layer. The familiar design stacked an intent classifier, a fixed multi-step reasoning pipeline, user-segment buckets, separate recommendation branches and a multi-agent orchestrator on top; some enterprises also let each team build its own subagent, so the architecture copied the org chart. Across comparisons in several enterprise deployments, a single agent with skills frequently outperformed both the one-prompt-for-everything design and the subagent design on quality, often at lower cost and latency per task; one company found its dozen specialist subagents made a consistent on-brand experience hard to maintain and added latency that hurt the user experience.

The design runs one model in one context window through an open-ended tool loop, with the model writing its plan and revising it as results arrive. Previously a code step rewrote the plan from a catalog of rules, ordering and domain procedure sat in the orchestration layer, and hard validation and approval gates sat outside it. Each turn the model emits a batch of tool calls that the harness runs in parallel and returns raw to the same model, which decides the next step; ordering and domain procedure move into skills, while validation, approval gates and memory lookups move into tools, and the loop stops when the model answers or hits a budget.

Migration proceeds in stages: build task-completion evals first, then fold subagents one at a time into skills plus tools and compare before and after. Previously each team added evals optimized for its own subtask, nobody owned the whole set, and leadership decided on watered-down, overly localized scores. One central team should own an end-to-end eval set, with smaller sets shipped alongside each skill, and even 10 golden examples are enough to start; on a sample support agent, folding one subagent lowered latency but broke a process that had been passing, and the break showed up in only one run out of two.

The scope is enterprise agents built on Claude Platform, especially production systems that already have an orchestrator and specialist subagents; the migration path is to build a small end-to-end eval first, then fold subagents in one at a time, keeping one as a subagent only if the folded version scores worse. Subagents are explicitly kept in three cases: a single loop hits measurable performance degradation from context bloat, multiple tasks need parallel fresh context windows that can be discarded once done, or a single agent struggles to select tools or faces conflicting instructions in the system prompt.

The conclusions come from comparisons across several enterprise deployments and one sample support agent, not a controlled large-scale benchmark; folding a subagent can break a previously passing process, and such breaks may not appear on every run. The single-loop design demands careful management of the system prompt, skill and tool descriptions, context and memory, and the text notes that model capability keeps changing, so best practice shifts with it.