h t t p s : / / c l a u d e . c o m / r e s o u r c e s / a r t i c l e s / b u i l d i n g - a g e n t s - w h e n - t o - f o l d - s u b a g e n t s - i n t o - y o u r - m a i n - a g e n t - l o o p

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

Type: types/ingest-report.md

Classification

This is a practitioner report. It gives deployment guidance drawn from customer engagements, with anecdotal and unpublished comparative results. It is not a controlled study. It is also partly a product article: it promotes Anthropic's migration kit, /claude-api skills and tool search. Author: Diane Sarkis, Anthropic Applied AI team, published on claude.com on 2026-10-22. The author has direct exposure to many enterprise deployments, but also a vendor interest in the recommended platform features.

Summary

The article argues that many enterprise agents built as an orchestrator over team-owned subagents work better as one agent loop. In that loop, skills disclose context progressively and tool search defers tool loading. It gives three reasons. Shared context lets the agent connect earlier steps instead of reading lossy subagent summaries. Progressive disclosure removes context bloat, which the article calls the main reason teams split work. More capable models make harness structure such as intent classifiers, fixed pipelines and plan-rewriting code redundant. Subagents stay justified in three cases: measured degradation from context bloat, parallel work in disposable fresh windows, and tool-selection or instruction conflicts. When splitting, the article says to divide by context and return compact results, not to divide by problem type. Splitting by problem type creates a "telephone game." It names organizational failure modes: the architecture copies the org chart (Conway's law), subagents sprawl, every team adds rules to the system prompt (the "Frankenprompt"), and evals are local to subtasks. Its remedy is one small central team that owns the system prompt and end-to-end evals, while domain teams own skills and tools. The migration method is to build task-completion evals, fold one subagent at a time, inspect which tasks flipped, and run each task more than once. The supporting evidence is a vendor summary: "several enterprise deployments," one customer's roughly 2x faster runtime, and one sample support agent where folding broke a chain in one of two runs.

Quotes

No source quotes have been retained yet.

Connections Found

The source has three roles in the KB. It is a counterpoint, practitioner evidence for an existing cluster, and the origin of one candidate mechanism.

As a counterpoint, it pushes against LLM context is composed without scoping on the axis of flat versus bounded invocation, but less than its framing suggests. That note calls sub-agents "the canonical architectural move" for enforcing scope, and it already states the trade the source rediscovers: flat pays the volume and complexity cost and risks contamination, bounded trades an interface cost for isolation. The source treats context bloat as the one reason to split and offers progressive disclosure as the cure. The KB separates volume, interference and complexity as distinct pressures. Skills loaded on demand reduce volume only; they do not isolate, so they cannot address contamination or compositional depth, which is what the scoping note's claim is about. The source's three keep-a-subagent conditions each already have a KB mechanism: measured degradation is the per-fork ceiling in feasibility is the heaviest fork's net load; parallel work in disposable fresh windows is the batched select/call form of the bounded-context orchestration model; tool or instruction conflicts are the claim of subtasks that need different tools force loop exposure, which already notes that sub-agents win over in-place tool mutation. The source's value here is practitioner confirmation of the trade-off and a stated boundary, not a correction.

As evidence, it supports the context-efficiency and decomposition cluster. Its split rule depends on measured context-bloat degradation and cost or latency. That is the feasibility face and the cost face of context efficiency is the central design concern. It also applies feasibility is the heaviest fork's net load: fold when progressive disclosure keeps the single loop under the ceiling. Its merge rule ("chain on each other's output, touch the same data, or are often called together") and its telephone-game warning are practitioner versions of two rules in decomposition heuristics for bounded-context scheduling: delay co-loading until interactions justify it, and do not compress away needed interfaces. The source is also a production account of relaxing under codification and relaxing navigate the bitter lesson boundary. It removes classifiers, pipelines and plan rewriters, but keeps budgets, write gates, validation and approval checks in code. Moving ordering and procedure into skills while keeping hard limits in tools matches the process-versus-outcome signal in operational signals that a component is a relaxing candidate. The flipped-task finding supports that note's preference for end-to-end tests when relaxing.

For comparison, its target loop moves the scheduler into the model ("the model that writes the plan is also the one carrying it out"). It offers intermediate forms: subagents called as tools with a shared response schema, full handoff only when a subagent must talk to the user, and skills plus tools. These are concrete points in agent orchestration occupies a multi-dimensional design space. It turns subagent prompts into skills and keeps their routing but drops their context isolation, which is one of the execution-policy options in skills are instructions plus routing and execution policy. Among sources, it agrees with Voooooogel that fixed orchestration dissolves as models improve. It adds vendor-side reports where Voooooogel only made a prediction. It is a practitioner counterpart to the controlled conditions in towards a science of scaling agent systems. With Scaling Managed Agents, it shares the claim that harness assumptions go stale. Managed Agents keeps an interface decomposition, while this source collapses agent decomposition into one loop. Claude Code dynamic workflows shows the same vendor shipping model-authored orchestration over sub-agents for Claude Code. The advice here is scoped to Platform agents serving customers.

The candidate new mechanism is organizational: some agent structure is codified for ownership reasons, not task reasons. No KB note covers this.

Extractable Value

  1. Ownership-driven decomposition as a mechanism -- Conway's law, subagent sprawl, the Frankenprompt and localized evals suggest that some agent boundaries track team ownership, not task structure. Such boundaries resist relaxing because no single owner can measure the end-to-end effect. The proposed fix assigns ownership along a boundary that can be relaxed: a central team owns the prompt and end-to-end evals, and domain teams own skills and tools. This has reach for Commonplace's own split between instruction authors and the KB-wide gates, but rests on one source. Keep it in the log until an independent source shows the same mechanism. [experiment]
  2. Practitioner stopping condition for decomposition -- The three keep-a-subagent conditions, together with the fold-one-at-a-time method, are a practitioner answer to the open question in decomposition-heuristics-for-bounded-context-scheduling about how to detect when decomposition overhead exceeds its benefit. The KB already holds each condition as a separate mechanism (see Connections Found); the source adds a deployment-level rule that joins them. It does not bound the scoping note's claim, which concerns enforced isolation rather than volume. [quick-win]
  3. Fold-one-at-a-time evaluation method -- Fold one component, compare with and without it, inspect which tasks flipped and not only the aggregate score, include one task per production chain and per hard rule, and repeat runs because a break appeared in one of two runs. This is a concrete relaxing test protocol that supports operational-signals-that-a-component-is-a-relaxing-candidate. It can be reused when Commonplace considers dropping a forked skill or gate. [quick-win]
  4. Divide by context, not by problem type -- Give a subagent work that needs little from the rest of the system and have it return a compact result. Merge specialists that chain, share data or co-occur. This is practitioner support for two decomposition heuristics. It applies to any decomposition this KB designs, inside the article's enterprise-agent setting. [just-a-reference]
  5. What stays codified after relaxing -- Budgets, write gates, validation and approval preconditions, per-user permissions as tool-side refusals the model can read, and cheap always-relevant loading such as entity resolution stay in code. Procedure moves to skills. This is a worked example of where codification survives inside a relaxed loop. [just-a-reference]
  6. Tool-count degradation threshold -- The article reports that tool choice tends to degrade beyond 30-50 tool definitions in the system prompt and recommends tools grouped by user intent plus deferred tool search. This is an unsourced vendor heuristic and is useful only as a reference point. [just-a-reference]

Limitations (our opinion)

The evidence is not visible. The "comparisons across several enterprise deployments" are summarized but not published: no tasks, baselines, sample sizes or metrics. The 2x runtime figure comes from one customer, and the flipped-task example comes from one sample agent run twice. Survivorship bias is likely, because the article reports deployments that benefited from folding and gives no rate of folds that were reverted.

The vendor has an interest in the framing. The recommended remedies are Anthropic platform features (skills, tool search, task budgets, /claude-api skills, the migration kit). The claim that newer models make harness structure redundant is also an interest-aligned claim about Anthropic's own models.

The comparison does not isolate one design choice. "Single agent with skills" versus "subagent design" changes several things at once: context sharing, scheduler placement, prompt ownership, tool loading and often the eval regime. The reported gains cannot be attributed to shared context specifically rather than, for example, removing a stale router or consolidating a conflicting prompt. The three keep-a-subagent conditions are stated as rules of thumb, not tested boundaries.

The scope is customer-facing enterprise agents built on Claude Platform, often with a coherent voice requirement. The advice does not directly transfer to long-horizon research or KB-maintenance agents where the review set exceeds one window. It also does not transfer to independent verification, which the article itself still assigns to subagents. Read the tension with LLM context is composed without scoping as a scope question, not a refutation. The source's own "shared context produces better answers" mechanism is asserted, not demonstrated against contamination costs.

The model-capability claim is time-bound. It names specific model generations, and the article itself says guidance changes as models evolve.

Add one sentence under the open question in decomposition heuristics for bounded-context scheduling about detecting the stopping condition for recursive decomposition. Cite this ingest as a practitioner answer: split only on measured degradation, disposable parallel work or tool and instruction conflicts, and test each fold by comparing with and without it and inspecting which tasks flipped. Do not revise LLM context is composed without scoping; its flat-versus-bounded paragraph already states the trade-off this source reports.