LangChain Deep Agents can start a subagent from a copy of the supervisor's context — Forked vs isolated subagent context — What does it mean?
The news. On September 8, 2026, LangChain shipped two subagent context modes in Deep Agents: isolated and forked. An isolated subagent receives a fresh context window carrying only its task description. A forked subagent inherits the supervisor's conversation state as it stands at the moment of delegation. The stated target is the worker that would otherwise repeat file reads and context gathering the supervisor has already done — while keeping reviewers isolated, so a second opinion is not anchored on the first. Read the post →
Picture the first reader closing a case file they have spent an hour inside. The margins are full: which documents mattered, which were dead ends, what the dates actually say. Now a second reader has to answer one narrow question about that same case. You can hand them the marked-up file, or you can hand them the question and nothing else — and that single choice decides both how long they take and how independent their answer is. Until a harness makes it a setting, that choice still gets made — silently, by whatever the harness happens to do by default.
Fork mode is a copy, not a summary, and the distinction carries the whole idea. When the supervisor delegates, the harness copies its message state as it stands, removes the trailing tool call — the half-issued call that is invoking the subagent, which the subagent should not see aimed at itself — and appends the delegated task as a new user message. The subagent runs from there. Its final answer is handed back as the result of that original tool call, so from the supervisor's side the delegation looks exactly like any other orchestrator-to-worker call. Only the worker's starting point changed.
That "copy, don't summarize" detail is what makes the mode cheap rather than merely convenient. Because the inherited prefix arrives unchanged rather than rewritten, it is still the prefix the serving layer has already processed — so it stays eligible for prompt caching rather than arriving as new text. A summarized handoff would forfeit most of that: a prefix cache matches only up to the first point where the text diverges, so rewriting the conversation into a summary gives up reuse of everything after that point, and producing the summary usually costs a model call of its own. It is the same rule a serving engine follows for shared-prefix reuse — the longer the prefix you leave untouched, the more of it stays reusable.
| Mode | Starting context | Rediscovery | Cacheable prefix | Fits |
|---|---|---|---|---|
| Isolated | The task description, nothing else | Repeated for anything it still needs | None to inherit | Reviewers, verifiers, independent researchers |
| Forked | A copy of the supervisor's conversation | Avoided for whatever was inherited | The supervisor's prefix, unchanged | Workers continuing the supervisor's own line of work |
The tempting reading is that isolation is the slow default and forking is the fix. It is not. Isolation is not overhead to be optimized away; it is the right choice whenever the second answer has to be independent of the first. A reviewer who inherits the supervisor's transcript inherits the supervisor's conclusion with it, and a second opinion that has already read the first opinion is worth much less than it looks. That is the same reasoning the curriculum uses when it treats subagents as a context-isolation tool rather than as extra hands — and it is why the useful question is no longer "should I use a subagent" but "what should this subagent be allowed to have already read." Workers that continue your work should fork. Critics that check your work should not.
Where the token bill actually lands
Hold one quantity fixed. A supervisor has read eight files and run a handful of searches, and now carries a 40,000-token conversation; it delegates one subtask described in 2,000 tokens. (Both figures are illustrative — the announcement publishes no measurements.)
Send that subtask to an isolated subagent and it starts at zero. To answer well it has to reach roughly the understanding the supervisor already has, which means re-reading roughly the same eight files: about 40,000 tokens of rediscovery, plus the 2,000-token task, so ~42,000 fresh input tokens — and, before any of them, the sequential tool calls that go and fetch them.
Send it to a forked subagent and those same 40,000 tokens arrive as a copy of a prefix the serving layer has already seen; only the appended task is new. Assume two things — that the subtask genuinely needs all eight files, and that the inherited prefix does land a cache hit — and fresh uncached input falls from ~42,000 tokens to ~2,000, about 21× less, with the round trips that fetched those files skipped along with it. Those skipped round trips count separately from the tokens: each one the worker no longer makes is a sequential wait it no longer sits through — the reason an agent's cost profile has a latency axis as well as a token axis.
Goes deeper in: AI Agents → Context Engineering → Subagents as Context Isolation
Related explainers
- Explorer-subagent context offloading — the other half of the trade: what a subagent should send back to the supervisor.
- Cache-preserving system messages — why an unchanged prefix is worth protecting in the first place.
- Programmatic subagent fan-out — deciding how many subagents to spawn, once you have decided what each one starts with.