Claude Blog: When building Agents, when to fold sub-agents into the main loop; progressive disclosure of Skills is often better than multi-expert orchestration

[Claude Blog Share] When to fold sub-agents into the main loop when building Agents: Skills progressive disclosure is often better than multi-expert orchestration

The common enterprise pattern of "one sub-agent per team + a top-level orchestrator" often mirrors the org chart, bringing context loss, latency, and Frankenprompts; on the Claude Platform, one main loop + on-demand loading of Skills/tools often delivers better quality, lower cost, and lower latency across multiple internal comparisons; sub-agents are reserved only for scenarios where they are truly necessary, such as parallelism, context bloat, or tool/instruction conflicts. https://t.co/XMkmZM4AlA

# The problem: typical failure modes when large organizations build Agents

When multiple product capabilities need to enter the same customer entry point, each team first builds its own Agent, and then the platform adds an orchestration layer (orchestrator–subagent, or treating sub-agents as MCP tools). It looks like a clear division of labor, but in practice you immediately run into: · Context management: details get lost in back-and-forth across Agents · Sub-agent bloat: overlapping, no unified standards, no clear owner · Frankenprompt: everyone adds a sentence to the system prompt → conflicting rules, inconsistent tone · Local evals: each optimizes a subtask, no one maintains end-to-end, leadership sees diluted scores · Latency: one customer compared a multi-Agent harness vs a single loop, and the latter was about 2× faster

Another common design path: intent classification → fixed multi-step reasoning → user segmentation buckets → branched recommendations → then an orchestration layer on top—feedback is often: the model no longer needs this much scaffolding; one clear system prompt + four or five lean data tools + hard output guardrails is enough to cover most scenarios.

# When sub-agents are still needed

· The single loop shows measurable performance degradation due to context bloat · Multiple tasks need to run in parallel, using fresh context windows that are discarded after use · A single Agent cannot choose tools well, or instructions in the system prompt conflict with each other

Scenarios such as Frontier research, verification, and modular permissions still apply; Anthropic's own multi-Agent research system also uses them. But "one sub-agent per problem type/per team" is often Conway's Law, not a capability ceiling.

# A better default: main loop + progressive disclosure

Use Skills to progressively disclose context and tool search to progressively disclose tools: see a short description first, load fully only when needed. Three reasons:

1. Shared context answers better: in long-horizon tasks, results from earlier steps stay in the same window, which connects better than summaries sent back by sub-agents. 2. Prevents context bloat: no need to stuff everything into an ultra-long system prompt—which was also the main reason for splitting out sub-agents before; Claude Code cut the system prompt by 80%+ for stronger models (including cuts related to Skills/tool progressive disclosure). 3. Stronger models: since Opus 4.5, a single loop can handle far more than most teams expect; newer models report their own progress and self-check, making some harnesses redundant. Rigid multi-Agent structures often instead prevent new models from doing more work; a simpler loop also makes model migration easier.

Target shape: · One model, one context window, an open-ended tool loop; the harness sets turn/cost budgets and write gates · Each turn the model can call tools in batches, the harness executes them in parallel, and raw results return to the same model · The model that writes the plan is also the model that executes it, and can change the plan mid-course · Ordering and domain workflows go into Skills; hard constraints such as validation/approval/memory lookup go into tools; cheap steps that are almost always relevant can still be preloaded in code

End-to-end quality and the system prompt should be overseen by a small, centralized team; new tools and evals should be vetted before launch. If you go multi-Agent, start from the simplest working pattern and split by context boundaries (independent research paths, clean-interface components, black-box verification), and split less by problem type; the latter is like a game of telephone, losing fidelity with each hop.

# How to fold them in (migration path)

1. Task-completion evals: one central end-to-end set + a small set per Skill; even 10 golden examples to start. During orchestration, watch routing accuracy; after folding in, watch whether the right Skill is loaded/the right tool is called. For internal systems that are hard to replay, use key-event timestamps for targeted replay.

2. Merge domain Agents: first build small end-to-end evals; prioritize merging pairs that "produce chained outputs, use the same data, and are often debugged together."

3. Sub-agents as tools: the main Agent keeps talking to the user, and sub-agents only act as tools returning structured conclusions; do a full handoff only when a sub-agent must speak directly to the user. This is still lossy: separate prompts/owners/evals, lossy summaries, nested loops adding latency—suitable as a baseline before folding in.

4. Fold into Skills + MCP tools: fold one at a time, comparing with and without the sub-agent; look at which tasks flip, not just the total score. Example: after folding in, latency dropped, but the main Agent answered on its own using the order-query tool and no longer asked the logistics specialist for the delivery date—a flow that previously passed was broken. Before changing, make sure evals cover every Agent chain and every unbreakable rule in production, and run each task multiple times (the above break appeared only 1 out of 2 runs).

# How multiple teams co-maintain one Agent

Ownership shifts from "each team maintains an Agent" to "maintaining Skills/tools"; a small central team guards the system prompt and end-to-end quality.

· MCP tools: actions, real-time data, fixed-shape results; group tools by user intent, not one tool per API (tool selection tends to degrade once tool definitions in the system prompt exceed about 30–50); tool search + lazy loading; put preconditions and permissions inside the tool checks and return readable rejections. · Skills: capture "how the team does the work"—steps, rules, and judgment; use /skill-creator and /skill-doctor to build, audit, and prune; each team's DRI ensures Skills take shape, do not overlap, and come with evals. · Knowledge base: policies/metrics/specs that are only occasionally needed go into search or reference files inside Skills; avoid hard-pasting code retrieval results into the prompt.

# Supporting tools

Migration kit strings together guided workflows (you can try on mocks first): /claude-api build-eval, prompt-audit, hillclimb, cost-optimize. Principle: measure → change one thing at a time → keep only what sticks. No need to do it all at once; small end-to-end evals → fold one in → keep the sub-agent only if the folded version is worse → repeat.