Subagent responsibilities and limits

Treat a subagent as a boundary around context, not as extra capacity, with one documented exception. For an ordinary subagent it starts with a fresh, isolated context window, and only its final summary returns to the delegating conversation, so verbose intermediate output stays behind.¹ The exception is a "fork" subagent, which inherits the parent conversation entirely, system prompt, tools, model, full history, and so loses the documented context-isolation benefit.¹ Anthropic's own guidance frames delegation to an ordinary subagent primarily as a context-budget move, sending the reading somewhere else so file contents land in the subagent's window rather than yours.²

What an ordinary subagent receives is documented, and it is less than the parent holds: its own system prompt, the delegation message, the CLAUDE.md hierarchy and a git status snapshot, with the built-in Explore and Plan agents skipping the last two.¹

What it cannot do is documented too. A fixed filter removes a set of tools from every subagent, including the one that asks the user a question, so it cannot pause mid-run to ask you anything; the brief has to carry the necessary direction and any decision that would otherwise need a user follow-up.¹ It is one-shot unless resumed by its returned agent ID; Explore and Plan return no ID at all.¹ Spawn depth is capped at three layers by default, concurrency at twenty running subagents per session.¹ The documented costs are real but unquantified: a fresh subagent may need time to gather context the main session already had, and every agent description is loaded into the delegating conversation, with a startup warning once the combined descriptions pass 15,000 tokens.¹

The working rule that follows is to delegate work whose output is large and whose result is small. A wide search, a survey of a directory, an investigation that would otherwise read hundreds of files: the delegating conversation keeps the conclusion instead of the transcript.² Write the brief as if the worker cannot ask a follow-up question, because no subagent, a fork included, can ask one during its run.

When this does not hold. No vendor publishes a measurement of whether delegating improves or degrades the outcome against doing the work in the main session. The practice is widely recommended but not measured, and the documented rationale is context management, not results. No source was found stating a per-invocation token or wall-clock cost figure either, and no comparable primitive with stated context, return and tool limits was found at the other vendors, so there is nothing to compare the semantics against. Delegation is a way of spending context deliberately. That is all it is currently known to be.