ForkedSubAgent, that instead inherits the parent’s full effective conversation history and exact system prompt.
Use forking when a subagent is delegated deep into an investigation and shouldn’t have to re-derive context the parent already gathered. For example, handing an in-progress incident investigation off to a subagent that drafts the postmortem.
Configure a forked subagent
A forked subagent uses a separate spec,ForkedSubAgent, not SubAgent. It shares most SubAgent fields (name, description, tools, model, middleware, interrupt_on, permissions, response_format), but two are rejected outright rather than silently ignored:
system_prompt: a forked subagent always uses the parent’s inherited system prompt.skills: a fork’s own skills injection would be immediately overwritten by the inherited system prompt, so it’s rejected instead of quietly doing nothing.
How it works
A forked subagent’s system message isn’t a static copy of the parent’s prompt. It’s captured dynamically from whatever the parent’s own middleware actually produced on its last call (skills injection, memory, custom prompt mutation), then replayed into the fork verbatim. This is what lets the fork share the parent’s prompt cache prefix instead of paying for a cold start; a fork’s own tools still work normally, but expect cache misses where they diverge from the parent’s. The inherited history also gets a short preamble marking it as a continuation, not a fresh request.Forking a CompiledSubAgent
ACompiledSubAgent can also set mode: "fork". This inherits the parent’s message history the same way, but keeps the compiled graph’s own system prompt. A CompiledSubAgent is already fully built, so there’s no system message for it to inherit into.
When to use forking
See also
- Subagents: Configure subagent names, descriptions, and system prompts
- Dynamic subagents: Dispatch subagents from interpreter code
- Context engineering: How conversation history is summarized as it grows
Connect these docs to Claude, VSCode, and more via MCP for real-time answers.

