Español

Your Subagent Didn't Vanish

Your helper agent finished, reported back, and you immediately have a follow-up question. The common move is to spawn a fresh one and explain the whole situation again. It's also unnecessary, and it's built on a belief about how subagents work that isn't true.

Finished is not gone

A completed subagent can be resumed, and a resumed subagent retains its full conversation history — all previous tool calls, their results, and its reasoning. It picks up where it stopped rather than starting fresh.

The transcripts are real files that persist independently of the main conversation, which is why this works across restarts: you can resume a subagent after restarting by resuming the same session. They live under ~/.claude/projects/{project}/{sessionId}/subagents/.

There is one detail that explains the confusion. Each subagent invocation creates a new instance rather than continuing an earlier one. So if you ask for the same subagent type again, you correctly get a blank one. Resuming is a different action from invoking, and that distinction is the whole trick.

How to actually resume one

You ask for it by name, in ordinary language. Messaging a completed subagent auto-resumes it in the background, with no new invocation:

Use the code-reviewer subagent to review the auth module
[it completes]

Continue that code review, now covering the authorization logic
[the same subagent resumes, with everything it already knew]

This also applies to subagents that were stopped mid-task, and a resumed subagent treats messages from whoever launched it as normal task direction — including mid-task course corrections. In the interactive UI you can open a subagent's transcript from the task panel and send follow-ups there.

This is the real reason to name them

A name is what makes a subagent addressable: it can be messaged or resumed by name after it finishes. Naming also puts it on a sibling roster — a listing of the other named agents in the session, each a valid target — so agents can coordinate with each other rather than everything routing through the main thread.

So naming isn't cosmetic bookkeeping for your own benefit. It's the handle that turns a one-shot helper into something you can come back to.

Why bother, in plain cost terms

Compare the two paths for a follow-up question. A fresh subagent starts with an empty context, re-reads the same files, and re-derives the same understanding before it can answer — and it never sees your conversation, so whatever it concluded last time is gone. Resuming skips all of that.

There's a related option when the follow-up genuinely needs your context rather than the helper's: forking. A fork inherits the entire conversation and shares the parent's prompt cache, which makes it cheaper than a fresh subagent that has to build its own. Between resuming and forking, spawning a blank agent to re-explain things is rarely the right answer.

The takeaway

Stop re-hiring the agent you already trained. A finished subagent still has its transcript on disk, messaging it by name wakes it up in the background with everything it knew, and the only reason people don't do this is a belief that it disappeared when it reported back.