When to Fork an Agent vs Spawn a Fresh One

There's a decision buried in every multi-agent system that gets almost no discussion relative to how much it determines whether the system works: when you create a new agent to handle a piece of work, does it inherit everything the parent agent already knows, or does it start from nothing?

Developer tools built around the supervisor pattern — Claude Code's own agent primitives are a clean example — expose this as an explicit choice. You can fork an agent, which clones the full conversation context into a new instance that continues in the background, sharing the parent's understanding of what's already happened. Or you can spawn a fresh subagent, which starts with zero memory of the conversation and works from whatever brief you hand it in the prompt. Both are one line of code. They produce wildly different results depending on which one the task actually needs.

What a fork is actually good for

A fork exists for one situation: you need to go do something, but the output of doing it isn't worth carrying forward, only the conclusion is. Think of a fork as delegating a question you already understand the shape of — "go dig through these fifteen files and tell me if this bug is a race condition" — to a version of yourself that already has all the surrounding context loaded, so you don't have to re-explain the project, the prior debugging steps, or why this matters.

The value of a fork is that it inherits your prompt cache along with your context, which makes it cheap to launch relative to its capability, and it can run in the background while you keep working, since its noisy intermediate tool calls — the failed greps, the files that turned out to be irrelevant — never pollute your own context. You get the finding without the archaeology.

The failure mode of using a fork wrong is subtle: if you fork for a task that doesn't actually need your accumulated context, you've just cloned a large, expensive conversation history into a new process for no reason. Forks are cheap because they share the cache, but they're not free, and forking reflexively for every subtask defeats the purpose of decomposition in the first place.

What a fresh subagent is actually good for

A fresh subagent is the right tool when the task is genuinely independent of everything that came before it, and — this is the part people underweight — when you want the independence. A code reviewer subagent that inherited your entire implementation context would review your code the way you'd review your own code: charitably, with all your assumptions intact, missing the same blind spots you have. A fresh agent, briefed only on what to look for, reviews it the way a stranger would. That's not a limitation of statelessness; it's the entire point of it.

This is the same logic behind why a second opinion is only useful if the person giving it doesn't already agree with you. A fresh subagent's lack of context isn't a cost to minimize — for verification, review, and adversarial-check tasks, it's the feature you're paying for.

Fresh subagents are also the right default for genuinely parallel, independent work — the three-to-five-subagent research pattern that defines 2026's production norm. When you're spawning multiple agents to investigate unrelated angles of a question simultaneously, none of them benefit from inheriting a shared conversation history full of context specific to angles they're not covering. A clean brief, tightly scoped, is more reliable than a large inherited context that's mostly noise for that particular subtask.

The brief has to do more work for a fresh agent

The practical cost of choosing "fresh" is that you can no longer be lazy about the prompt. A forked agent can be told "go check if that thing we discussed earlier is actually a problem" and it'll understand, because it was there. A fresh agent given the same instruction has no idea what "that thing" refers to. Every fact the fresh agent needs — what you've already tried, what's out of scope, what a good answer looks like — has to be written into the brief explicitly, because there is no shared history to lean on.

This is where a lot of multi-agent systems quietly degrade: teams start with fresh subagents for good architectural reasons, then under-invest in the brief because writing a complete, self-contained prompt for every subtask is more work than typing a two-line instruction to something that already gets it. The subagent then produces plausible-but-wrong output not because the model is weak, but because it was never told the one constraint that would have ruled out the wrong answer. This is a large part of what Debugging a Multi-Agent System ends up tracing back to.

The middle case: partial context, deliberately chosen

The fork/fresh binary is the two clean extremes, but a lot of real production systems need something in between, and building that middle case well is where more mature multi-agent architectures differentiate themselves. Consider a subagent that needs some of what the lead agent knows — the user's original request, say, and the constraints that came out of an earlier planning step — but shouldn't inherit the lead agent's full exploratory history, including the three approaches it considered and rejected before settling on the current plan. A full fork hands over all of that, including the rejected approaches, which risks anchoring the subagent on reasoning that's no longer relevant, or worse, having it "helpfully" revisit an approach that was already ruled out for a reason it never saw. A fully fresh spawn loses the constraints entirely and risks the subagent re-deriving them wrong.

The right answer here is usually a curated handoff rather than either primitive in its pure form: a fresh subagent, briefed with a deliberately constructed summary of exactly the constraints and context it needs, written by the lead agent as a distinct step rather than inherited wholesale. This costs more upfront engineering — someone has to design what belongs in that summary — but it avoids both failure modes: the subagent isn't drowning in irrelevant history, and it isn't missing the constraints that actually matter. This is effectively the same handoff-design discipline covered in Designing Handoffs Between Specialist Agents, applied specifically to the moment a new agent is being created rather than to a result being passed between two agents that already exist.

Cost is part of the decision, not just correctness

There's also a token-economics dimension to the fork-versus-fresh choice that's easy to miss when you're only thinking about correctness. A forked agent inherits and shares the parent's prompt cache, which — per the token math covered in The 15x Token Tax of Parallel Subagents — makes it comparatively cheap to launch even though it's carrying a large context. A fresh subagent starts cold, with no cache to inherit, which means its first turn pays full price for whatever context you do give it, even if that context is much smaller than the forked alternative's. For a short, narrow task, fresh is usually cheaper in absolute terms despite the cache disadvantage, because there's simply less total context in play. For a long-running investigation where a fork would let you avoid re-explaining an increasingly complex situation over and over, the cache advantage can flip the calculus the other way. Neither primitive is a free lunch, and treating the choice as purely architectural — ignoring what it costs — is how teams end up with an accurate but unaffordable fleet.

A quick decision rule

Fork when the task needs your accumulated understanding to do well, and you don't need its intermediate work visible — debugging investigations, "go check this specific thing," anything where re-explaining the situation would take longer than just cloning it. Spawn fresh when independence is the point — verification, adversarial review, parallel research across unrelated angles, or any handoff to a specialist agent whose value comes precisely from not sharing your assumptions.

If you're not sure which one to reach for, ask whether you'd trust the result more if the agent had seen everything you've seen, or less. That answer tells you which primitive you actually want.

Get this wrong in either direction and the symptom looks like a model capability problem — the agent "hallucinated" a fix, or "missed obvious context." Usually it's neither. It's a fork that should have been fresh, or a fresh agent that should have been a fork.

---

Part of the "The Subagent Economy" series on aiskill.market.