![Cover image for [AI Context #5] Why Use Subagents? Context Isolation and Delegation](/assets/images/posts/6f12e091-1d37-4258-b659-1070e39916f1/1.jpg)
In earlier installments, we explored ways to conserve context: clear history at each work boundary (Part 3) and keep fixed overhead short (Part 4). Yet some tasks remain too large to handle. A typical example is, “Figure out how payment logic flows through this codebase.” A diligent agent would read dozens of files, and as we saw in Part 1, everything it reads accumulates in context. By the time the investigation is complete, no context remains for the actual work that knowledge enables—changing the code.
This installment focuses on subagents, which solve the problem structurally. The key point is simple: you do not need to have only one context window.
Work in another context, bring back only the conclusion
A subagent is a separate agent instance created by the main agent. The key is that this instance receives a new, clean context window of its own.
The flow looks like this. The main agent sends a single instruction to a subagent: “Investigate and summarize how the payment logic flows.” The subagent reads dozens of files in its own context, searches, and traces call relationships. Tens of thousands of tokens accumulate during this process, but they all belong to the subagent’s context. When the work ends, the subagent returns one organized report and disappears. The main context retains only one instruction and one report—just a few hundred to a few thousand tokens.
It is a familiar organizational structure. Instead of conducting market research personally, a manager assigns it to a researcher and receives a one-page report. The point is that the hundred sources reviewed by the researcher do not pile up on the manager’s desk. The manager’s desk—that is, the main context—keeps only the information needed for decisions.
What should you delegate?
Tasks worth delegating have one thing in common: the process is heavy, while the conclusion is light.
First, exploration and investigation. Tasks such as “find everywhere this function is used” or “understand the code related to this bug” require reading a lot, but the final answer is just a list or a summary. They are classic subagent tasks. Claude Code provides dedicated exploration agents for the same reason.
Second, tasks that can be split in parallel. If five modules each need analysis, five subagents can work on them simultaneously in their own contexts. This not only reduces elapsed time; it also prevents their intermediate outputs from mixing in one context and causing confusion.
Third, and somewhat differently, tasks that need a fresh perspective. Code review is the obvious example. The main agent that just wrote the code has a context full of implementation assumptions and trial and error. Reviewing its own code in that state makes it easy to become trapped by those assumptions and judge too leniently. Give the code alone to a context-free subagent, and it sees the code through an unfamiliar reviewer’s eyes. Here, isolation is not a token-saving technique but a quality mechanism.
Conversely, some tasks lose by being delegated. Lightweight work, such as reading one or two files, costs more in delegation overhead than it saves. Tasks that depend heavily on the conversation so far are also a poor fit. The reason comes next.
The cost of isolation: subagents know nothing
A subagent’s clean context is not free. Clean also means knowing nothing about the conversation so far.
The assumptions accumulated over an hour in the main session—the project must preserve a legacy API, tests must not be touched, and this is the user’s preferred approach—are all unknown to the subagent. If they are not written in the instruction, they do not exist. Delegation quality therefore converges on instruction quality. You must include the necessary background, constraints, and desired deliverable format in one instruction to avoid receiving a report built on irrelevant assumptions.
The return path works the same way. The main agent receives only the subagent’s final report, so any discovery omitted from the report disappears with the subagent. That is why it helps to specify the report format in the instruction, for example: “Include the evidence that influenced your judgment and the list of files you checked.” The context poisoning discussed in Part 2 appears here again. If the subagent’s report is inaccurate, the error is transplanted into the main context in compressed form, and the main agent tends to trust it because the original evidence is unavailable for verification. Important conclusions should therefore come with their supporting evidence.
Summary
- A subagent works in a separate, clean context and returns only its conclusion. The key is keeping tens of thousands of process tokens out of the main context.
- Tasks with heavy processes and lightweight conclusions—exploration, investigation, and parallel analysis—are good delegation candidates. For tasks such as review, isolation is also valuable for quality because it provides a fresh perspective.
- The cost of isolation is a break in context. Since a subagent does not know the conversation history, the instruction must include all relevant background and constraints, and the report should be required to include supporting evidence.
One final piece of the series remains. /clear makes the conversation disappear, and a subagent disappears when its session ends. But the project continues. Where should knowledge that must survive beyond the end of a session live? The next installment covers storage outside the context—in other words, memory and externalization.