What parent does NOT see from subagent
What you'll learn
The parent only sees the subagent's final summary. The tool calls, intermediate outputs, and dead-ends stay in the subagent's context.
- Context isolation is unidirectional. Parent → brief in. Subagent → summary out.
- Parent does NOT see: tool-call trail, intermediate outputs, dead-ends, raw reads, failed attempts.
- Parent sees only what the summary contains.
Context isolation between parent and subagent is **unidirectional**: the parent passes a brief in, the subagent returns a summary. The parent does *not* see the subagent's intermediate work — the tool-call trail, the partial outputs, the dead-end reasoning, the raw read-file contents the subagent looked at, the failed attempts. All of that lives in the subagent's context only.
What the parent *does* see: whatever the subagent's final summary contains. If the summary mentions 'I tried X, then Y, then settled on Z,' the parent knows that. If the summary just says 'Done; here's the final patch,' the parent has no insight into how the subagent got there. The summary is the entire surface area between the two contexts.
Implication for design: anything the parent might need to act on must be in the summary. If the parent needs to know which files were touched, the summary must list them. If the parent needs the subagent's reasoning trace, the summary must include it. The default ('subagent did its work') gives the parent only the final answer — that's usually fine, but it's a property to design around.
Implication for debugging: when something goes wrong inside the subagent, the parent can't see why. Errors that show up at integration time may be caused by something deep in the subagent's loop the parent has no visibility into. Mitigation: subagents should return detailed summaries when failures happen (or always, if the work is risky) so the parent has enough to act on.
Key points
- Context isolation is unidirectional. Parent → brief in. Subagent → summary out.
- Parent does NOT see: tool-call trail, intermediate outputs, dead-ends, raw reads, failed attempts.
- Parent sees only what the summary contains.
- Design implication: summary must contain everything the parent needs to act on.
- Debugging implication: subagent failures need detailed summaries for parent visibility.
Examples
Subagent: 'Implemented parseInvoiceLine; tests pass. Returning the function.' Parent sees: the function and a one-liner. Parent doesn't see the 5 attempts before that or which test cases were tricky.
Subagent's brief asked it to 'return: the function + a list of test cases that are tricky + any assumptions you made.' Subagent's summary includes all three. Parent has visibility because the summary was *designed* for it.
Pitfalls
- Assuming the parent will see the subagent's tool calls or intermediate outputs. It won't.
- Designing parent integration logic that depends on the subagent's working notes (which the parent never receives).
- Not specifying summary shape in the brief. Subagent decides what to surface; parent gets whatever it picked.
Source notes: 00-academy-basics/notes/08-subagents.md
Ask Claude
Build a prompt with this lesson + your question, copy it, and open the Claude Project in a new tab.