What you’ll be able to do
- Decide what context a subagent actually needs versus what it inherits by default
- Explain context bleed and why it degrades subagent reliability
- Design a structured handoff payload instead of a transcript dump
- Recognize when shared context is genuinely required
What you need to know
Isolation is a design decision, not a default
A subagent doesn't automatically get "just enough" context — an architect has to decide what crosses the boundary. The default temptation is to hand over everything: the full parent transcript, every tool result so far, the entire system prompt. That's not safety through completeness; it's cost and noise through completeness.
The question to ask for every subagent invocation is narrow: what does this specific subtask need to succeed, and nothing more? A summarization subagent needs the text to summarize, not the eight prior turns of an unrelated planning conversation that happened to precede it.
Context bleed degrades the thing you delegated for
Context bleed is what happens when irrelevant instructions or state leak into a subagent's reasoning because it inherited more than its task required. A subagent instructed to "extract line items from this invoice" that also inherits a system prompt written for a customer-support persona may start hedging, apologizing, or following support-specific formatting rules that have nothing to do with invoice extraction.
This is the opposite of what delegation was supposed to buy you. You isolated a subtask to get a more focused, more reliable result — bleed reintroduces the noise you delegated to escape.
Structured handoffs over transcript dumps
A structured payload is smaller, cheaper, and — critically — reviewable. You can validate it against a schema before it's sent, log it for audit, and know exactly what the subagent had access to when something goes wrong. A transcript dump answers "what might the subagent have seen" with "everything, probably," which is not an answer you can debug from.
When shared context is the right call
Isolation isn't a universal rule — some subtasks genuinely need shared state. A subagent continuing a multi-step negotiation needs to know what's already been offered; a subagent doing a second pass over a document needs the first pass's findings. The distinction is between context the subtask depends on to do its job correctly, and context that's merely available because it happened to be in the parent's history. Pass the former deliberately, as structured fields. Don't pass the latter by default.
Key concept
Isolation has to be designed in, not assumed. Pass a subagent the structured fields its task actually depends on — not the parent transcript, and not the parent’s system prompt.
When a scenario describes a subagent behaving oddly or off-persona, check what it inherited before you touch its own instructions — the bleed is usually coming from upstream context, not a bad prompt.
Practice scenario
Work it through, then open this
The subagent only needs the current ticket’s text and any fields the classification task actually depends on — tier, product line, prior category if relevant to routing. The three-month-old billing complaint is noise that can bias classification toward “billing” even when the current ticket is unrelated. Replace the transcript forward with a structured payload containing only the fields the classification task depends on.
Build exercise — Redesign a subagent handoff
Intermediate · 20 min
What you’ll learn
- Auditing what a subagent currently receives versus what it needs
- Converting a transcript-based handoff into a structured payload
- Spotting context bleed from an inherited system prompt
-
Take an existing subagent invocation and list every piece of context it currently receives.
- Why: Most handoffs accumulate context nobody deliberately decided to include.
- You should see: At least one field that’s present because it was easy to forward, not because the subtask needs it.
-
Design a structured payload containing only the fields the subtask’s success actually depends on.
- Why: A minimal, structured handoff is smaller, auditable, and can be schema-validated before it’s sent.
- You should see: A shorter, named-field payload instead of a prose dump.
-
Check whether the subagent inherits the parent’s system prompt, and whether any of its instructions belong to a different role than the subagent’s task.
- Why: Inherited system-prompt instructions are a common, hard-to-spot source of context bleed.
- You should see: Either a clean, task-specific instruction set, or bleed you just found.
Exam traps
Passing the full parent conversation to every subagent “just in case”
Costs tokens and dilutes focus for a hypothetical need that’s rarely real. Pass what the task depends on.
Letting a subagent inherit system-prompt instructions meant for a different role
This is context bleed’s most common source, and it shows up as a subagent behaving off-task in ways that look like a prompting bug but are actually an isolation bug.
Handing off a natural-language summary where a structured field would be reliable
Prose is ambiguous and hard to validate. A named field with a known type is not.
Assuming isolation is free when it actually requires deliberate design
Isolation doesn’t happen by default — someone has to decide what crosses the boundary and build the payload that enforces it.
Sharing context because it’s the default, not because the task needs it
Shared context should be a deliberate choice for subtasks that depend on prior state, not the path of least resistance.