Don't Draw Agent Architecture as an Org Chart: Task-Level Evals Decide Whether Subagents Survive
This strips the default assumption that any non-trivial Agent needs subagents, and replaces it with a concrete, measurable workflow: single loop first, Eval to decide, fold one at a time. Teams burning latency and context on elaborate orchestration diagrams can cut runtime roughly in half and stop paying the telephone tax, as long as they're willing to instrument real user tasks and run them twice.
A new industry retrospective from Anthropic's applied AI team takes aim at a common failure mode: companies building Agent systems by mirroring their own org charts, hanging a dedicated subagent over every department. In practice, users' questions cut across these boundaries, so requests get shuttled between subagents, losing context at every handoff, accumulating latency, and producing fragmented output. The case study cited runs roughly 2x faster after collapsing a multi-agent setup into a single loop.
The article reframes the default: don't split subagents without a measurable reason. Subagents buy context isolation, parallelism, and permission boundaries, but they cost a "telephone tax" of summary compression and extra model rounds. Only three conditions justify keeping them: context bloat with measured degradation, tasks that must run truly in parallel with disposable windows, or tool selection degrading past 30–50 resident tool definitions. Most existing subagents, the retrospective argues, were built as crutches for older models that couldn't hold long instructions — a need that newer models (Opus 4.5 and later) have largely removed.
For teams that already run dozens of subagents, the path is measured and incremental: write an end-to-end Eval (even 10 golden questions is enough), merge pairs that are always called together, fold one subagent at a time, and run each test at least twice because single runs are flaky. Hard preconditions should live in tool code, not in prose prompts. The goal is to move business teams from maintaining "people" (subagents) to maintaining "skills and tools" (MCP tools and skill files), with a small central team owning the master prompt and end-to-end evaluation.
The telephone game is the structural cost of subagents: every handoff compresses detail, and the compression loss is cumulative and irreversible — the main model can never recover a fact lost in a summary.
Many production subagents are not a design choice but a historical artifact — they exist to prop up models that could no longer handle long, self-supervised work. Model upgrades turn these crutches into liabilities.
The 30–50 tool threshold is a useful rule of thumb because it reflects a real cognitive limit: the model's ability to pick the right tool degrades past that point, and the fix is to merge by user intent, not to add more orchestration.
"Faster is not better" is the sharpest operational warning: a merged agent that checks the order tool may answer from gut feeling and skip a verification step that previously lived in a handoff, silently changing the outcome.
Running each exam question twice is a practical necessity, not paranoia, because model output is variable and a single pass can mask a real regression.
The shift from subagents to skills and tools redraws team boundaries: business groups own capability modules and local Evals, a central team owns the master prompt and end-to-end quality, which turns architecture into a maintainable governance model.
First measure task completion rate, then split.