Anthropic: Over-Splitting Sub-Agents Adds Latency — Four Consolidation Patterns

Cost of Handoff

Anthropic observed in multiple enterprise deployments that splitting agents by business domain — each team maintaining its own agent, orchestrated by a platform layer — often slows responses. A user request may pass through several specialist agents. Each handoff requires the main agent to restate context (user conditions, prior data, failed attempts) and the specialist to summarize results. Restating background, generating summaries, and waiting for results all add to user-visible latency. When two specialists query the same data sequentially, this overhead compounds.

This mirrors the multi-agent information flow issue (https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==∣=2650409075&idx=1&sn=db2e8d2646f7498d94412ecda2179ef2&scene=21#wechat_redirect): teams can maintain knowledge separately, but execution may need shared context. Anthropic suggests identifying such coupled pairs from invocation logs and merging them — a step the open-source single-agent-loop-kit calls merge. Business rules stay, but intermediate data flows directly, eliminating re-explanation and summary passing.

Handoffs also consume tokens. In Anthropic's January tests, multi-agent systems used 3–10× the tokens of a single agent for the same task, including repeated context passing, coordination, and summarization. While the January and October articles lack full public benchmarks, Anthropic has long advocated splitting by required context rather than organizational boundaries. The October piece adds that modern models can now plan and call tools themselves, creating room to merge previously separate steps.

Figure 1 | Top: writing, testing, review split across three agents. Bottom: one agent writes code and tests, a verifier runs tests. Writing tests needs implementation understanding; running tests only returns results. Source: Anthropic.

Main Loop Takes Over

When two specialists merge, where do their business procedures go? Anthropic extracts the steps, rules, and judgment methods from specialist prompts into Skills , and moves data queries, API calls, and operations to tools. The toolkit calls this fold.

Before: Main agent delegates to specialist → specialist reads its prompt, calls tools, returns answer. After: Main agent loads the relevant Skill, follows its business steps, calls tools directly. Business teams still maintain the steps and rules, but no extra model loop runs per business function.

Raw tool results enter the main agent's context. The model then decides next steps: query more if information is insufficient, ask user for missing conditions, or finish if ready. If a query result overturns a prior judgment, the model can revise its plan on the spot without handing off to another planning agent.

Won't the prompt grow too large? The Claude Code team uses on-demand loading . Anthropic internally uses hundreds of Skills; at session start, Claude Code receives only skill names and short descriptions. The model reads the full SKILL.md only when it judges a skill relevant; referenced scripts and reference files are also loaded lazily. This progressive disclosure means the system's total capabilities differ from what occupies the current context. In a customer-service setting, the main agent loads delivery rules for a shipping query, and only loads the refund flow when the user asks about refunds.

Tools follow a similar pattern. With ~20 tools, the model must discriminate among many options each step. Tool Search first finds relevant tools, then loads their invocation specs. Volatile data (orders, inventory) is fetched at call time. Permission checks remain inside tools — e.g., an order-query tool verifies the current user's access before returning data — so one agent can serve users with different permissions.

This aligns with earlier discussions of Graph (https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==∣=2650409948&idx=1&sn=cfe8a886980e4377bcf5dfaea6369ed2&scene=21#wechat_redirect), Harness (https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==∣=2650410721&idx=1&sn=3383bfdac19b842f78da869479d8bd7b&scene=21#wechat_redirect): stable workflow dependencies go into Graph, the model decides next steps in the Loop based on query results, and Harness executes tools, records results, and enforces budgets and write controls. Even with a single agent, programmatic constraints (authorization before query, retry on timeout, fail after max retries) remain. Reducing agents does not remove business processes or programmatic checks.

Independent Context

On-demand loading solves the initial context size problem, but a task may still pull in large amounts of material. When users ask about Claude Code configuration, a Claude Code Guide sub-agent searches docs and returns the answer. The pages it browsed and intermediate search results stay in its own context. The main agent receives only the answer and continues the conversation without carrying the entire document set.

Anthropic calls this invocation style as-tool: the main agent delegates a task, the sub-agent works in its own context, returns a result; the main agent still conducts the ongoing user dialogue, decides next steps, and composes the final reply.

Figure 2 | Left to right: merge context-sharing specialists; keep sub-agent but call as tool; convert specialist prompt to Skills and API calls to tools. Each changes different handoff relationships. Source: Anthropic.

Simon Willison's sub-agent guide also lists these uses: exploring codebases, handling verbose test output, independent debugging. Isolating such work in a fresh context reduces interference with the main task.

However, the main agent still receives a summarized result. If the sub-agent omits the basis for its conclusions or unresolved uncertainties, the main agent may treat unconfirmed judgments as facts. The clarity of the delegation — whether inputs, completion criteria, and expected outputs are specified — affects outcomes.

What difference does it make to give the same Skill to the main agent vs. a sub-agent? Microsoft Research's Subagents vs Agent Skills (https://mp.weixin.qq.com/s?__biz=MzAwNjQwNzU2NQ==∣=2650409171&idx=1&sn=f1205a72f8219032770c1144307d1efa&scene=21#wechat_redirect) compared both on 64 programmatic skills from SkillsBench's 87 tasks. When skills lacked complete steps or clear I/O, loading directly into the main agent performed equally or better. After completing those specifications, sub-agents achieved better results. Strong models reduced peak context usage in over 80% of tasks, but inter-agent communication increased total token consumption.

Frequent reliance on the ongoing conversation increases handoff burden; tasks that can be specified independently and require reading large volumes benefit from an isolated context.

Some sub-agents must directly ask users questions and continue based on answers. Anthropic recommends full handoff in these cases — the sub-agent takes over that conversation segment. OpenAI Agents SDK distinguishes the same two modes: tool call returns to main agent; handoff transfers subsequent dialogue to the receiving agent.

The toolkit classifies sub-agents that must conduct multi-turn user dialogue themselves, or are controlled by external organizations and cannot be refactored, as keep — they remain as-is.

Parallelism and Coordination

Another reason to keep sub-agents: can parallel execution reduce user wait time? Anthropic's Research system works this way: the main agent decomposes a research question, multiple sub-agents search different directions, then results are synthesized. In their published eval, multi-agent research quality improved 90.2% over single-agent (quality measured, speed gains separate). They also report multi-agent token usage ~15× normal chat (baseline differs from the earlier single-agent comparison).

Independent search paths can proceed concurrently and merge at the end. Code modification introduces a different problem: multiple agents editing the same file or sharing a runtime environment. One agent's edit may leave another working on stale state.

A dynamic concurrency study across Codex, Claude Code, and Kimi Code (354 tasks, 2,124 executions) found concurrent mode consumed 1.41–3.31× the tokens of sequential mode, with no consistent success-rate improvement. Among 366 cases where both modes succeeded, concurrent was faster in 27.9%, and at least 20% faster in 12.6%. In annotated failures, shared state, result merging, and concurrent writes were prominent issues.

Time saved by starting together may be lost to waiting, merge conflicts, and re-verification.

Cognition's software-engineering agents often use a pattern where one main agent modifies code while other agents review and suggest fixes. Reviewers operate in fresh contexts to find issues; the main agent applies changes, reducing conflicts from simultaneous writes.

Search results can be merged at the end, but interdependent code changes require coordination during execution. The net time savings from parallelism depend on how much subsequent coordination overhead it introduces.

Omissions After Merging

Beyond enterprise observations, Anthropic tested merging on a customer-service example. After folding one sub-agent into another, responses were faster, but a previously passing flow failed. The main agent, now holding the order-query tool, answered without confirming the delivery date with the delivery specialist. The system skipped the date-check step.

This regression appeared in only one of two runs. A single run or average latency alone would miss it.

The toolkit's validation is still limited. As of October 28, the repository logs only two real-model runs from the same customer-service example and model: one fold run on 12 tasks, one as-tool run on 17 tasks. merge steps, the final single-loop version, and other real business systems lack full execution records.

Anthropic's migration method therefore compares task results before and after each change. The existing system runs a set of real requests; after each sub-agent adjustment, the same task set runs again, comparing completion, latency, model calls, tokens, and cost. This reveals both aggregate changes and specific requests that succeeded before but fail after.

If the delivery specialist were further converted to a Skill and tool, the execution trace would shift: previously main agent → delivery specialist; now main agent reads delivery rules, calls tool, obtains delivery date. Both may produce the same final sentence, but the trace shows whether the intermediate work actually occurred.

This explains why Anthropic recommends separating two evaluation layers. Business teams maintain their Skills, tools, and unit tests; a small team owns the system prompt and end-to-end evaluation. An order tool returning data and a delivery tool returning a date only prove each works in isolation. End-to-end evaluation covers the full request-to-reply path and can catch cases where each tool works but the overall chain misses a step.

For that customer request, both before and after merging, a confirmed delivery date is required. The handoff can be removed, but the date-check step must still execute.

References

Anthropic, Building agents: When to fold subagents into your main agent loop (https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop)

Anthropic, Building multi-agent systems: When and how to use them (https://claude.com/resources/articles/building-multi-agent-systems-when-and-how-to-use-them)

Anthropic, Single Agent Loop Kit (https://github.com/anthropics/single-agent-loop-kit)

Anthropic, How we built our multi-agent research system (https://www.anthropic.com/engineering/multi-agent-research-system)

Thariq Shihipar, Lessons from building Claude Code: How we use skills (https://claude.dev/blog/lessons-from-building-claude-code-how-we-use-skills/)

Thariq Shihipar, Seeing like an agent: how we design tools in Claude Code (https://claude.dev/blog/seeing-like-an-agent/)

Anthropic, Effective context engineering for AI agents (https://www.anthropic.com/research/effective-context-engineering-for-ai-agents)

Anthropic, Tool Search Tool (https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool)

Microsoft Research, Subagents vs Agent Skills: Executing Reusable Knowledge for Long-Horizon Agentic Tasks (https://www.microsoft.com/en-us/research/publication/subagents-vs-agent-skills-executing-reusable-knowledge-for-long-horizon-agentic-tasks/)

Han Li et al., When Sub-Agents Work in Parallel: The Promises and Pitfalls of Dynamic Concurrency in Long-Horizon Coding Tasks (https://arxiv.org/abs/2610.10263)

Cognition, Multi-Agents: What's Actually Working (https://cognition.com/blog/multi-agents-working)

Cognition, Don't Build Multi-Agents (https://cognition.com/blog/dont-build-multi-agents)

Simon Willison, Claude Skills are awesome, maybe a bigger deal than MCP (https://simonwillison.net/2025/Oct/16/claude-skills/)

Simon Willison, Subagents (https://simonwillison.net/guides/agentic-engineering-patterns/subagents/)

OpenAI Agents SDK, Agent orchestration (https://openai.github.io/openai-agents-python/multi_agent/)