Claude Code Subagents: Forking Instead of Delegating
When a task grows too large to comfortably handle inside a single conversation, two mechanisms exist to offload it: spawning a fresh agent, or forking the agent already running. They look similar on the surface (both run in the background, both return a result), but they solve different problems, and mixing them up costs time rebuilding context that already existed.
The problem delegation doesn't solve#
A fresh agent starts from zero: no history of the current conversation, no decisions already made, no files already read. Handing it a task means re-explaining everything in the prompt: what you're trying to do, what's already been tried, why. On a genuinely independent task (look up a package, summarize an external doc), that's not a problem: the fresh agent needs nothing but the question. On a task that extends work already underway, every re-explanation is time spent rebuilding what the conversation already knew.
The fork: inheriting context instead of rebuilding it#
A fork starts from the opposite premise: it inherits the entire conversation up to the point it's launched, files already read, decisions already made, reasoning already done. The prompt you give it stops being a situation briefing and becomes a directive: what to do next, not what happened before.
fresh agent : empty context -> re-explain everything first
fork : inherited context -> pick up where the thread left off
Why fork instead of just continuing in the main conversation#
If a fork already inherits everything, the question becomes: why not just continue in the main conversation? The answer comes down to what an exploratory task produces: dozens of tool calls, file reads that only rule out one path, intermediate results that never need to be revisited once the synthesis is done. Doing that exploration in the main conversation fills it with noise that stops being useful afterward. Doing it in a fork isolates that noise: only the final result comes back, the intermediate reasoning stays in the background task.
A concrete example#
Comparing two architectural approaches on the same repo is a typical exploratory task: a lot of file reading, little of it worth keeping in the end. Launching a fork for that exploration, getting a verdict back in a few sentences, and keeping the main conversation focused on the decision rather than the path that led to it: that's exactly the kind of task where forking changes things. Asking the same question of a fresh agent would mean re-explaining the repo, the exact question, and the context behind the decision, before even starting to look for the answer.
What it doesn't replace#
A fork isn't free: it runs as a background task with its own token budget, and it doesn't replace a fresh agent when the task is genuinely unrelated to the current thread. Launching a fork for a question that has nothing to do with the ongoing conversation just means dragging along a whole history that serves no purpose. The deciding factor isn't the size of the task, it's how much it depends on context already accumulated: dependent, fork it; independent, start fresh.
