Subagents return conclusions, not the reasoning behind them

A subagent hands back its summary, not the intermediate reasoning that produced it — so fanning one feature across several subagents throws away the understanding you were paying them to build.

You have a feature to build. The instinct, once you have used subagents at all, is to split it: one to work out the data model, one to write the migration, one to update the callers, one to fix the tests. Four contexts, four times the room, none of them polluting yours.

Then the third one comes back with a patch that contradicts the second one's assumptions, and you cannot tell why, because the reasoning that produced it is gone.

What actually comes back

This is not a subtlety — it is the documented mechanism. A subagent works in its own context window and returns only its final text response, plus a small metadata trailer. The context-window walkthrough puts numbers on it: a research subagent reads 6,100 tokens of files, you receive 420 tokens of result. That ratio is the whole point when the work is log processing. It is the whole problem when the work is understanding.

So the split is not really "big task vs small task". It is:

Question about the work	Delegate it	Keep it in the main session
What do you need afterwards?	The conclusion	The reasoning that reached it
Does the next step depend on how this one thought?	No	Yes
Would you re-explain the same background to each worker?	No	Yes, repeatedly
Is the output verbose and disposable?	Yes — logs, test runs, search results	No — design decisions, invariants
Does it need back-and-forth with you?	No	Yes

The official guidance lands in the same place from a neutral angle: use the main conversation when the task needs iterative refinement, or when multiple phases share significant context, such as planning, implementation, and testing. A feature is exactly that — phases sharing context. Splitting it across workers means each one rediscovers the shared part, badly, and then discards its notes.

The half-fix that is worth knowing

The usual objection — "a subagent starts blind, that's the real cost" — has a direct answer. A fork is a subagent that inherits the entire conversation so far: same message history, same system prompt, same tools. Start one with /subtask:

text

/subtask draft unit tests for the parser changes so far

Mind the name if you are working from older notes. /subtask "requires Claude Code v2.1.212 or later; on v2.1.161 through v2.1.211 this command is /fork" — and /fork did not go away, it now does something else: it copies the conversation into a separate background session instead of reporting a result back into this one. Typing the old name from muscle memory gets you a sibling session, not a side task. The one exception is a session with agent view turned off, where /subtask is unavailable and /fork starts the forked subagent after all.

A fork removes the input problem. It does not remove the output problem: the fork's own tool calls still stay out of your conversation and only its final result comes back. So a fork is the right tool when the side task needs your background but you do not need its working. It is still the wrong tool when you need to inherit how it thought.

That asymmetry is the sharpest version of this tip. Isolation of input is optional. Isolation of output is not — it is what a subagent is.

What to do instead of fanning out

Plan in the main session and argue with the plan there, where every objection stays in context.
Delegate the research that precedes the plan, not the decisions inside it.
If context is genuinely the constraint, prefer compaction or a deliberate handoff document over shredding one coherent task into four incoherent ones.
When you do fan out, fan out along boundaries that are actually independent — separate modules, separate files in a mechanical migration — not along the phases of one feature.

What is unverified here

The mechanism is documented and not in dispute: only the summary returns. The prescription — that fanning a feature across subagents costs more than it saves — is a practitioner's judgement from a community tips post, with no threshold attached and no measurement behind it. Nothing in the docs makes that negative claim, and nothing contradicts it either; the bundled /batch skill happily splits a change across 5 to 30 subagents, which suggests the boundary matters far more than the count.

What would settle it is a paired run rather than an argument. Same repo, same feature, two fresh sessions:

bash

claude -p "research how session timeouts work here, then implement the fix" \
  --output-format json > main-session.json

claude -p "use separate subagents to research, plan, and implement the session timeout fix" \
  --output-format json > delegated.json

Then compare the two diffs for contradicted assumptions, and compare the cost and duration fields. Run it on a task whose right answer you already know, or you are grading vibes. Until someone does that, treat this as a well-argued default, not a measured result.

Checkpoint

For the task in front of you right now: afterwards, do you need its conclusion or the reasoning that produced it?
Show answerAnswer
Only you can answer for your own task, and that single question is the whole decision. A subagent works in its own context window and returns only its final text response plus a small metadata trailer, so anything you wanted to watch it think is gone — the walkthrough's ratio of 6,100 tokens of files read to 420 tokens returned is the point when the output is verbose and disposable, and the problem when the output is a design decision or an invariant the next step depends on. If the phases share significant context — planning, implementation, testing — the official guidance already points you at the main conversation.
What does a fork give you that a plain subagent does not, and what does it still not give you?
Show answerAnswer
A fork inherits the entire conversation so far — same message history, same system prompt, same tools — so it starts with your background instead of blind; you start one with /subtask. What it still does not give you is its working: the fork's own tool calls stay out of your conversation and only its final result comes back. Isolation of input is optional; isolation of output is what a subagent is. Mind the name if you are working from older notes — /subtask requires v2.1.212 or later, on v2.1.161 through v2.1.211 the command is /fork, and /fork today copies the conversation into a separate background session instead of reporting back.
Name one case where losing the intermediate reasoning is the reason you delegated.
Show answerAnswer
Adversarial review is the cleanest one: a reviewer in a fresh context sees only the diff and the criteria, not the reasoning that produced the change, which is precisely why it can grade work the implementer cannot grade itself. The verbose-and-disposable cases qualify too — run the suite and report only the failures, read the vendor's API docs and give me the pagination rules, grep 40k lines of production log for one trace id — where a short summary is genuinely all you wanted. Both wanting the reasoning back and wanting it kept out are legitimate; the instruction is to decide which one this task needs before you spawn anything.