Prefer a fresh session over a subagent

You reach for a subagent whenever a task looks big, because subagents get their own context window and that sounds like free headroom. Then the delegated work comes back thin, or two delegates step on the same file, and you spend longer reconciling the result than you would have spent doing it in one place.

The counter-position, from engineers who leaned on delegation hard and then backed off: a subagent is excellent at reading and mediocre at writing. When the delegated task both reads and writes files, you often do better closing the session, running /clear, and starting again with a sharper prompt that carries what you just learned.

The split that actually predicts which one wins

The unifying test is not "is this task big". It is does the delegate need to hold a picture that only you currently have, and will it hand back files rather than findings. If yes, a fresh session with a better prompt beats a delegate every time, because you can write the picture into the prompt but you cannot write it into a summary boundary.

What the docs do and do not say

The docs describe the mechanism this rests on, and never make the comparison.

• sub-agents.md positions subagents around reading: use one "when a side task would flood your main conversation with search results, logs, or file contents you won't reference again". Each runs in its own context window and returns only its summary.
• best-practices.md gives you the fresh-session half independently: "If you've corrected Claude more than twice on the same issue in one session, the context is cluttered with failed approaches. Run /clear and start fresh with a more specific prompt." It states flatly that a clean session with a better prompt almost always outperforms a long session with accumulated corrections.
• worktrees.md is the interesting one. It says subagents can run in their own worktrees "so parallel edits don't conflict", with isolation: worktree in a custom subagent's frontmatter to make that permanent.

That last bullet cuts both ways, and you should know it before you adopt this tip wholesale. The write-conflict problem is real enough that the product shipped a mechanism against it — which corroborates the diagnosis. But it also means the blunt version of this tip ("don't delegate writes") is now out of date: /batch explicitly splits a change across 5 to 30 subagents, each in its own worktree, each opening a pull request. Write-heavy fan-out is a supported path, not a trap, as long as the files are disjoint and the delegates are isolated.

How to use it without over-correcting

1. Delegate the read. "Use subagents to investigate how our auth system handles token refresh" is the canonical good case: unbounded reading, bounded output.
2. Do the write yourself, in a clean session. When you know what to change, /clear, then open with a prompt containing the findings, the constraint, and the acceptance check. The subagent's summary was going to be that prompt anyway — you just skip a lossy hop.
3. Escalate to isolation, not to more delegates. If the write work genuinely is parallel, give each delegate its own worktree or its own session rather than letting several write into one checkout. agent-teams.md is blunt about the failure mode: two teammates editing the same file leads to overwrites, so break the work so each owns a different set of files. Check your version before you lean on the isolation, though: a subagent with isolation: worktree runs its shell commands inside its worktree and errors if the path resolves elsewhere, but sub-agents.md notes that "Before v2.1.203, such a command could run in the main checkout."
4. Treat repeated correction as the signal. Two corrections on the same point means the next move is a fresh session, whether or not a subagent is involved.

What is unverified here

Everything about relative quality is unverified. Nobody has run a controlled comparison of the same write-heavy task delegated versus done in a fresh session, and no such comparison exists in the docs — the docs deliberately make no call on which to reach for. What we have is one credible practitioner report plus a documented mechanism that is consistent with it.

What would settle it: take a throwaway clone of a real repo, run one mechanical multi-file change twice — once as an explicit subagent fan-out, once in a single fresh session with a prompt that already contains the plan — and diff the two resulting patches against a hand-written correct patch. Count files missed, files double-edited, and turns spent. Do that on three or four different changes and the prior stops being a prior.

A second thing worth measuring separately: whether isolation: worktree closes the gap entirely. If it does, the tip narrows to "delegate writes only when you have isolated the delegates", which is a much smaller and more defensible claim than the original.

Checkpoint

• A colleague says "use a subagent, it saves context". For which of their two tasks — mapping every caller of a deprecated API, or renaming that API across the callers — is that advice right, and why?
  ›Show answerAnswer

  Mapping the callers. That is the read-heavy, bounded-output case sub-agents.md positions subagents for: reach for one when a side task would flood your main conversation with search results, logs, or file contents you will not reference again, and only the summary comes back. The rename hands back files rather than findings, and it needs the picture of the change that currently exists only in your head — write that picture into a prompt and do the rename yourself in a fresh session. The docs make no call between the two, though — the read-side positioning is documented; that a fresh session beats a delegate on writes is a practitioner prior nobody has measured. If the renames really are independent across disjoint files, give each delegate its own worktree rather than letting several write into one checkout.

• The docs ship isolation: worktree for subagents. Does that support or undercut the claim that subagents parallelise badly on writes?
  ›Show answerAnswer

  Both, which is why the tip splits the claim in two. It supports the diagnosis: worktrees.md says subagents can run in their own worktrees "so parallel edits don't conflict", and a mechanism does not ship against a problem nobody had. It undercuts the blunt version, "never delegate writes" — with isolation, write-heavy fan-out is a supported path, which is exactly what /batch does across 5 to 30 subagents, each in its own worktree opening its own pull request. What survives is the narrower rule: delegate writes only when the delegates are isolated and the files are disjoint. Check your version before leaning on it, since sub-agents.md notes that before v2.1.203 a shell command in an isolation: worktree subagent could run in the main checkout.

• You have corrected Claude three times on the same import path. Naming a subagent for the remaining work would be the wrong move. What is the right one?
  ›Show answerAnswer

  Run /clear and open again with a more specific prompt that states the correct import path, the constraint, and the acceptance check. best-practices.md treats more than two corrections on one issue as the sign that the context is cluttered with failed approaches, and says flatly that a clean session with a better prompt almost always outperforms a long session carrying them. A subagent does not help because the corrections are the problem, not the size of the context — you would be briefing the delegate out of the same muddled framing.