{"course":{"slug":"context-engineering","title":"Context Engineering","url":"https://addaly.com/learn/context-engineering","level":"advanced","track":"build"},"lesson":{"slug":"sub-agents-and-window-isolation","title":"Sub-agents buy you a window and charge you a boundary","url":"https://addaly.com/learn/context-engineering/sub-agents-and-window-isolation","position":66,"of":87,"minutes":9,"answer":"The reason to spawn a sub-agent is that it reads a great deal and returns a little, so the parent never pays for the reading.","keyIdea":"The reason to spawn a sub-agent is that it reads a great deal and returns a little, so the parent never pays for the reading; and the price is that everything not in the return value is permanently gone, which makes the return contract the real design decision."},"body":{"format":"markdown","text":"## What you are actually buying\n\nStrip away the vocabulary of delegation and roles, and a sub-agent is one mechanism: a second context window that the first one does not pay for.\n\nA research sub-agent runs twelve searches, reads nine pages, burns 80,000 tokens in its own window, and returns 600 tokens of findings. The parent's window grows by 600. The 80,000 happened somewhere the parent will never see and never be billed for again on subsequent turns, which is the part that matters, because in the parent's own window those 80,000 tokens would have been resent on every step for the rest of the task.\n\nThat is the entire benefit. Everything else attributed to sub-agents (specialisation, focus, cleaner prompts) is real but secondary, and mostly achievable other ways.\n\n> Figure: When a second window pays for itself. A two by two grid, rows Reads a great deal and Reads very little, columns Returns a little and Returns a great deal: Reads a great deal and Returns a little: Spawn it; Reads a great deal and Returns a great deal: Little gained; Reads very little and Returns a little: Rarely worth it; Reads very little and Returns a great deal: Do it inline. The benefit is one mechanism: a window the parent does not pay for. The price is that whatever the sub-agent knew and did not write down is gone, not retrievable and not queryable, which makes the return schema the real design decision. The field that earns its place is the one listing what could not be determined, because without it a search that found nothing reads exactly like a search that found everything.\n\n## The boundary is the design\n\nWhatever the sub-agent knew and did not write down is gone. Not retrievable, not queryable: gone, unless you re-run the whole thing.\n\nThis makes the return schema the most consequential thing you write, and it is usually the least considered. A sub-agent told to \"research X and report back\" returns prose of whatever length it fancies, with confident claims and no indication of which are solid.\n\nSpecify it instead:\n\n```json\n{\n  \"findings\": [{\"claim\": \"...\", \"source_url\": \"...\", \"quote\": \"...\"}],\n  \"could_not_determine\": [\"...\"],\n  \"sources_consulted\": 9,\n  \"confidence\": \"high | mixed | low\"\n}\n```\n\nThe field that earns its place is `could_not_determine`. Without it, a sub-agent that failed to find something returns a report that reads exactly like a sub-agent that found everything, and the parent proceeds on an evidence set it believes is complete. This is the characteristic sub-agent failure and it is silent at every layer.\n\nThe quote field is the second. A claim with the sentence it came from can be checked by the parent; a claim without one has to be believed.\n\n## What it costs, beyond the obvious\n\n**Cache fragmentation.** Each sub-agent has its own prefix, so none of them shares the parent's cache. Five sub-agents means five cold prefixes. You can recover most of this by giving every sub-agent of a given type an identical system prompt and toolset, so they at least warm the same cache entry, which means resisting the urge to inject the specific task into the system prompt. Put the task in the first user message, below the breakpoint.\n\n**Compounding compression.** A sub-agent summarising its own sub-agent's summary is two lossy steps. Each is reasonable; together they produce a report whose relationship to the source material nobody can reconstruct. Two levels is usually the practical limit, and one is better.\n\n**No shared state.** Two sub-agents editing the same file is the canonical disaster, and it fails in the ugliest way: both succeed, one overwrites the other, and nothing reports a conflict. If the work touches shared mutable state, either serialise it or do not decompose it.\n\n## Where the real latency win is\n\nParallelism, and it is a genuine one. Four sub-agents searching four sources concurrently take as long as the slowest, not the sum. For read-only, independently decomposable work (search across sources, review across files, check across datasets) this is the strongest argument for the pattern, stronger than the token saving.\n\nIt inverts immediately when the sub-tasks depend on each other. Sequential sub-agents are slower than doing the work inline, because you have added a model call and a serialisation round trip per step for no isolation benefit that a stub would not also give you.\n\n## When not to\n\n- **When the parent will need to ask a follow-up.** There is nobody to ask. The sub-agent is gone. If the shape of the next question depends on the answer, keep the work in one window.\n- **When verification matters more than volume.** The parent can only check what came back. A sub-agent that reasoned badly returns a confident, well-formed, wrong summary, and it looks identical to a good one.\n- **When the task is small.** Below a few thousand tokens of reading, the overhead of a second model call exceeds the saving.\n\n## A test worth running\n\nRun the same task twice: once decomposed into sub-agents, once inline in a single window with aggressive stubbing. Compare three numbers: total tokens billed, wall-clock time, and accuracy on your golden set.\n\nThe result surprises people regularly in both directions. Sub-agents win decisively on parallel read-heavy work. Inline with stubbing wins more often than expected on sequential work, because stubbing achieves much of the same context reduction without paying the boundary. Which one you have is an empirical question about your task, and it takes an afternoon to settle rather than an argument."},"check":{"question":"A research sub-agent fails to find one of three requested facts and returns a fluent summary of the two it found. Why is this the characteristic sub-agent failure?","options":[{"text":"The parent cannot tell a complete report from an incomplete one.","correct":true},{"text":"The sub-agent's tokens are billed to the parent anyway, so the failed search is paid for twice over.","correct":false,"tempting":"Billing is a cost question and is unaffected by whether the search succeeded; the danger here is the parent's false belief."},{"text":"The missing fact stays in the sub-agent's window and leaks into the parent's next request unpredictably.","correct":false,"tempting":"Windows are isolated by construction; nothing leaks across, which is precisely what creates the problem."},{"text":"Constrained decoding forces the summary to fill every field, so absent findings get fabricated to satisfy the schema.","correct":false,"tempting":"A schema can compel a field to exist, but the failure here occurs with free-form prose too and is about what the parent can verify."}]},"prev":{"slug":"the-agent-loop-grows","title":"Why a twenty-step agent run costs what it does","url":"https://addaly.com/learn/context-engineering/the-agent-loop-grows"},"next":{"slug":"the-filesystem-as-context","title":"Put the payload on disk and the pointer in the window","url":"https://addaly.com/learn/context-engineering/the-filesystem-as-context"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'Sub-agents buy you a window and charge you a boundary', in Context Engineering. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/context-engineering/sub-agents-and-window-isolation (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"Sub-agents buy you a window and charge you a boundary","courseTitle":"Context Engineering","module":{"index":7,"slug":"tools-schemas-and-the-agent-window","title":"Tools, schemas and the agent’s window"},"answer":null,"keyIdea":"The reason to spawn a sub-agent is that it reads a great deal and returns a little, so the parent never pays for the reading; and the price is that everything not in the return value is permanently gone, which makes the return contract the real design decision.","hero":{"kind":"figure","figure":{"t":"figure","label":"Figure","figure":{"cols":["Returns a little","Returns a great deal"],"rows":["Reads a great deal","Reads very little"],"type":"matrix","cells":[["Spawn it","Little gained"],["Rarely worth it","Do it inline"]],"title":"When a second window pays for itself","caption":"The benefit is one mechanism: a window the parent does not pay for. The price is that whatever the sub-agent knew and did not write down is gone, not retrievable and not queryable, which makes the return schema the real design decision. The field that earns its place is the one listing what could not be determined, because without it a search that found nothing reads exactly like a search that found everything.","cellLabels":[["the parent grows by six hundred","the parent pays for it all anyway"],["a call and a round trip added","no window pressure to relieve"]]},"alt":"Figure: When a second window pays for itself. A two by two grid, rows Reads a great deal and Reads very little, columns Returns a little and Returns a great deal: Reads a great deal and Returns a little: Spawn it; Reads a great deal and Returns a great deal: Little gained; Reads very little and Returns a little: Rarely worth it; Reads very little and Returns a great deal: Do it inline. The benefit is one mechanism: a window the parent does not pay for. The price is that whatever the sub-agent knew and did not write down is gone, not retrievable and not queryable, which makes the return schema the real design decision. The field that earns its place is the one listing what could not be determined, because without it a search that found nothing reads exactly like a search that found everything."}},"blocks":[{"t":"h2","id":"what-you-are-actually-buying","runs":[{"text":"What you are actually buying"}]},{"t":"p","runs":[{"text":"Strip away the vocabulary of delegation and roles, and a sub-agent is one mechanism: a second context window that the first one does not pay for."}]},{"t":"p","runs":[{"text":"A research sub-agent runs twelve searches, reads nine pages, burns 80,000 tokens in its own window, and returns 600 tokens of findings. The parent’s window grows by 600. The 80,000 happened somewhere the parent will never see and never be billed for again on subsequent turns, which is the part that matters, because in the parent’s own window those 80,000 tokens would have been resent on every step for the rest of the task."}]},{"t":"p","runs":[{"text":"That is the entire benefit. Everything else attributed to sub-agents (specialisation, focus, cleaner prompts) is real but secondary, and mostly achievable other ways."}]},{"t":"h2","id":"the-boundary-is-the-design","runs":[{"text":"The boundary is the design"}]},{"t":"p","runs":[{"text":"Whatever the sub-agent knew and did not write down is gone. Not retrievable, not queryable: gone, unless you re-run the whole thing."}]},{"t":"p","runs":[{"text":"This makes the return schema the most consequential thing you write, and it is usually the least considered. A sub-agent told to “research X and report back” returns prose of whatever length it fancies, with confident claims and no indication of which are solid."}]},{"t":"p","runs":[{"text":"Specify it instead:"}]},{"t":"code","lang":"json","label":"JSON","text":"{\n  \"findings\": [{\"claim\": \"...\", \"source_url\": \"...\", \"quote\": \"...\"}],\n  \"could_not_determine\": [\"...\"],\n  \"sources_consulted\": 9,\n  \"confidence\": \"high | mixed | low\"\n}"},{"t":"p","runs":[{"text":"The field that earns its place is "},{"text":"could_not_determine","code":true},{"text":". Without it, a sub-agent that failed to find something returns a report that reads exactly like a sub-agent that found everything, and the parent proceeds on an evidence set it believes is complete. This is the characteristic sub-agent failure and it is silent at every layer."}]},{"t":"p","runs":[{"text":"The quote field is the second. A claim with the sentence it came from can be checked by the parent; a claim without one has to be believed."}]},{"t":"h2","id":"what-it-costs-beyond-the-obvious","runs":[{"text":"What it costs, beyond the obvious"}]},{"t":"p","runs":[{"text":"Cache fragmentation.","b":true},{"text":" Each sub-agent has its own prefix, so none of them shares the parent’s cache. Five sub-agents means five cold prefixes. You can recover most of this by giving every sub-agent of a given type an identical system prompt and toolset, so they at least warm the same cache entry, which means resisting the urge to inject the specific task into the system prompt. Put the task in the first user message, below the breakpoint."}]},{"t":"p","runs":[{"text":"Compounding compression.","b":true},{"text":" A sub-agent summarising its own sub-agent’s summary is two lossy steps. Each is reasonable; together they produce a report whose relationship to the source material nobody can reconstruct. Two levels is usually the practical limit, and one is better."}]},{"t":"p","runs":[{"text":"No shared state.","b":true},{"text":" Two sub-agents editing the same file is the canonical disaster, and it fails in the ugliest way: both succeed, one overwrites the other, and nothing reports a conflict. If the work touches shared mutable state, either serialise it or do not decompose it."}]},{"t":"h2","id":"where-the-real-latency-win-is","runs":[{"text":"Where the real latency win is"}]},{"t":"p","runs":[{"text":"Parallelism, and it is a genuine one. Four sub-agents searching four sources concurrently take as long as the slowest, not the sum. For read-only, independently decomposable work (search across sources, review across files, check across datasets) this is the strongest argument for the pattern, stronger than the token saving."}]},{"t":"p","runs":[{"text":"It inverts immediately when the sub-tasks depend on each other. Sequential sub-agents are slower than doing the work inline, because you have added a model call and a serialisation round trip per step for no isolation benefit that a stub would not also give you."}]},{"t":"h2","id":"when-not-to","runs":[{"text":"When not to"}]},{"t":"ul","items":[[{"text":"When the parent will need to ask a follow-up.","b":true},{"text":" There is nobody to ask. The sub-agent is gone. If the shape of the next question depends on the answer, keep the work in one window."}],[{"text":"When verification matters more than volume.","b":true},{"text":" The parent can only check what came back. A sub-agent that reasoned badly returns a confident, well-formed, wrong summary, and it looks identical to a good one."}],[{"text":"When the task is small.","b":true},{"text":" Below a few thousand tokens of reading, the overhead of a second model call exceeds the saving."}]]},{"t":"h2","id":"a-test-worth-running","runs":[{"text":"A test worth running"}]},{"t":"p","runs":[{"text":"Run the same task twice: once decomposed into sub-agents, once inline in a single window with aggressive stubbing. Compare three numbers: total tokens billed, wall-clock time, and accuracy on your golden set."}]},{"t":"p","runs":[{"text":"The result surprises people regularly in both directions. Sub-agents win decisively on parallel read-heavy work. Inline with stubbing wins more often than expected on sequential work, because stubbing achieves much of the same context reduction without paying the boundary. Which one you have is an empirical question about your task, and it takes an afternoon to settle rather than an argument."}]}],"check":{"question":[{"text":"A research sub-agent fails to find one of three requested facts and returns a fluent summary of the two it found. Why is this the characteristic sub-agent failure?"}],"options":[{"text":[{"text":"The parent cannot tell a complete report from an incomplete one."}],"correct":true,"tempting":null},{"text":[{"text":"The sub-agent’s tokens are billed to the parent anyway, so the failed search is paid for twice over."}],"correct":false,"tempting":[{"text":"Billing is a cost question and is unaffected by whether the search succeeded; the danger here is the parent’s false belief."}]},{"text":[{"text":"The missing fact stays in the sub-agent’s window and leaks into the parent’s next request unpredictably."}],"correct":false,"tempting":[{"text":"Windows are isolated by construction; nothing leaks across, which is precisely what creates the problem."}]},{"text":[{"text":"Constrained decoding forces the summary to fill every field, so absent findings get fabricated to satisfy the schema."}],"correct":false,"tempting":[{"text":"A schema can compel a field to exist, but the failure here occurs with free-form prose too and is about what the parent can verify."}]}],"order":[1,0,3,2],"why":null},"prev":{"slug":"the-agent-loop-grows","title":"Why a twenty-step agent run costs what it does","minutes":10},"next":{"slug":"the-filesystem-as-context","title":"Put the payload on disk and the pointer in the window","minutes":9}}}