[FEATURE] conversation forking for parallel agent spawning

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When using the Agent tool to spawn parallel teammates, every spawned agent starts with a blank conversation — it receives only the system prompt and the prompt string. The parent agent's accumulated context (file reads, architectural understanding, design decisions made over N turns) is completely lost.

This forces the orchestrating agent to manually compress and serialize its understanding into each agent's prompt, which is:

• Lossy — conversation context can't be perfectly serialized into a summary
• Cache-inefficient — the compressed context lands in user messages, not the cacheable system prompt prefix, so it's duplicated N times with no prompt caching benefit
• Tedious for the orchestrator — the main agent spends significant tokens re-explaining what it already knows

This is the core friction that makes parallel agent workflows less effective than they should be.

Proposed Solution

Add a conversation forking mechanism to the Agent tool — an option to clone the parent's current message history as the starting context for the spawned agent.

Conceptually:

Agent(
  prompt: "Now implement component A based on what we discussed",
  fork: true,   // ← inherit parent's conversation history
)

The spawned agent would begin its conversation with the full parent message history as prefix, followed by the new prompt as the first user turn. Since the forked prefix is identical across all spawned agents, it would benefit from prompt caching — written once, cached for all parallel branches.

Alternative Solutions

1. Context snapshot via CLAUDE.md (works today, DIY) — Before spawning agents, the orchestrator writes a .claude/context-snapshot.md summarizing accumulated understanding, referenced by CLAUDE.md. Spawned agents auto-load it as system prompt (cached). Downside: still requires manual compression, and pollutes project files.

1. Explicit context parameter — Instead of full fork, allow passing a structured context object or message array to the Agent tool. More flexible than full fork but still requires the orchestrator to decide what to include.

1. Shared memory / context store — A runtime key-value store that agents can read/write to, separate from the task board. Less about forking, more about coordination.

Priority

Medium - Would be very helpful

Feature Category

Performance and speed

Use Case Example

Building a frontend feature that spans multiple files:

Turn 1-5:   User and agent discuss requirements, read existing code,
            agree on component structure and API contracts

Turn 6:     Agent is ready to implement. Needs to create:
            - API route handler
            - React component
            - State management hook

Today:      Agent must write 3 separate prompts, each re-explaining
            the architecture, conventions, and decisions from turns 1-5.
            Each prompt is unique content → no caching → 3x cost.

With fork:  Agent spawns 3 forked agents. Each inherits turns 1-5
            as cached prefix. Only the specific task instruction is new.
            Parallel execution, shared context, prompt caching works.

Additional Context

• The conversation history is already a message array — the data structure for forking exists
• Prompt caching on the forked prefix would make this cost-efficient (identical prefixes across siblings = cached)
• This would make the Agent tool + /teams workflow dramatically more effective for any non-trivial parallel task decomposition
• The orchestrator pattern (plan → decompose → delegate → merge) is already well-supported by worktrees and the task board — context forking is the missing piece that would make it truly seamless