The Decision Rule and Execution Modes
One Rule to Decide
All the guidance collapses into a single question: does the intermediate work matter? If the answer is no — you just need the final result — delegate it to a subagent. If the answer is yes — you need to see and react to what's happening along the way — keep it in your main thread.
The whole decision in one branch: if you don't need the journey, delegate; if you must watch and react, keep it in the main thread.
| Use subagents for | Avoid subagents for |
|---|---|
| Research and exploration | 'Expert' personas that add no capability |
| Code reviews (fresh context) | Multi-step pipelines where each step depends on the last |
| Tasks needing a custom system prompt | Running tests where you need full output to debug |
A pocket guide built from the decision rule and the three anti-patterns.
Foreground vs. Background
Once you decide to delegate, a subagent can run in the foreground or the background. Foreground subagents block the main conversation until they finish, and permission prompts pass through to you as they arise. Background subagents run concurrently while you keep working — but they run with the permissions already granted and auto-deny any tool call that would otherwise prompt.
- •Foreground: blocking, interactive — you see and answer permission prompts in real time.
- •Background: concurrent — you keep working; the subagent auto-denies anything that would prompt (a needed permission causes that call to fail, though the subagent continues).
- •Claude decides foreground vs background based on the task; you can also ask it to 'run this in the background' or press Ctrl+B to background a running task.
Background subagents and permissions
If a background subagent fails because it needed a permission it couldn't request, just start a new foreground subagent with the same task to retry with interactive prompts. Background is great for autonomous work, but interactive tasks belong in the foreground.
Forks: Isolation's Opposite
There's a special mode worth knowing: a fork. A fork is a subagent that inherits the ENTIRE conversation so far instead of starting fresh. This deliberately drops the input isolation subagents normally provide — a fork sees the same system prompt, tools, model, and message history as the main session. Its own tool calls still stay out of your conversation and only its final result returns, so your main context stays clean.
| Fork | Named subagent | |
|---|---|---|
| Context | Full conversation history | Fresh context + the prompt you pass |
| System prompt & tools | Same as main session | From the subagent's definition |
| Model | Same as main session | From the subagent's model field |
| Best when | Background is too much to re-explain; try parallel approaches | A focused, reusable, constrained worker |
A fork trades input isolation for zero re-explaining; a named subagent keeps a fresh, constrained context.
When a fork beats a named subagent
Use a fork when a named subagent would need too much background to be useful, or when you want to try several approaches in parallel from the same starting point. Because a fork reuses the parent's prompt cache, it's also cheaper than spawning a fresh subagent for tasks that need the same context. (Forks are experimental; enabled via CLAUDE_CODE_FORK_SUBAGENT=1.)
Choosing Main Thread vs. Subagent
Zooming out, here's the practical guidance for the everyday choice between keeping work in the main conversation and delegating it.
- 1.Main conversation: frequent back-and-forth, phases that share lots of context (plan → implement → test), quick targeted changes, or when latency matters (subagents start fresh and need time to gather context).
- 2.Subagent: the task produces verbose output you don't need, you want to enforce tool/permission restrictions, or the work is self-contained and can return a summary.
- 3.Skills (an alternative): when you want a reusable prompt/workflow that runs in the MAIN context rather than an isolated subagent context.
Section complete
You can now decide when to delegate and how to run it. The final section scales up: subagents in the Agent SDK, parallel execution, and the multi-agent orchestration patterns behind Anthropic's research system.
Key Takeaways
- ✓The decision rule: does the intermediate work matter? No → delegate to a subagent; Yes → keep it in the main thread.
- ✓Use subagents for research, code review, and custom-prompt tasks; avoid them for expert personas, dependent pipelines, and test running.
- ✓Foreground subagents block and pass permission prompts through; background subagents run concurrently but auto-deny anything that would prompt.
- ✓Claude picks foreground/background by task; you can request background or press Ctrl+B; a background failure due to permissions can be retried in the foreground.
- ✓A fork inherits the full conversation (dropping input isolation) but keeps its tool calls out of your context — good when re-explaining is costly or for parallel approaches; it reuses the parent prompt cache (cheaper).
- ✓Choose the main conversation for iterative/shared-context/low-latency work, subagents for verbose self-contained work, and Skills for reusable prompts that run in the main context.
Check Your Understanding
Test what you learned in this lesson.
Q1.According to the decision rule, when should you keep work in the main thread instead of delegating?
Q2.How does a background subagent handle a tool call that would normally prompt for permission?
Q3.How does a fork differ from a named subagent?
Q4.When is a fork preferable to a named subagent?
Practice This Lesson