Read-and-Discard Isolation

Offload work that reads a lot but returns little to a separate context. What gets discarded is the intermediate clutter that piles up while reading — the result comes back as a summary. This is not a pattern for discarding results.

Problem

Investigation produces dozens of times more clutter than the answer it yields. Searches that miss, files opened and found wrong, implementation candidates considered and dropped — all of it becomes dead weight the moment the answer lands. But what gets read piles up by default: an agent has no way to selectively un-read what it has already read. The spent clutter stays behind, riding along on every subsequent turn, crowding out the original instructions and constraints. Say "the investigation is done, let's implement" and the very next turn, the agent starts implementing with all the investigation debris still attached.

Context

Applies when:

• The volume read far exceeds the volume brought back — exploration, research, impact analysis, review
• The result compresses to a few lines — a recommendation, a location, a yes/no judgment
• The intermediate material is never referenced afterward — the act of reading itself has no further use

Does not apply when:

• What was read is itself the object of subsequent work. The contents of a file to be edited cannot serve as editing material once reduced to a summary
• The conversation's history matters to the judgment. An isolated context knows neither the prior thinking nor the constraints that came before it
• The lookup is small enough to finish in one pass. Building a boundary at all has a cost

Boundary with neighboring patterns:

• The Break-Even Point of Delegation — the structure of isolating is this pattern; its price tag is that pattern
• Session Boundary Design — if the unit discarded is the conversation itself, that pattern; if it's one section within a conversation, this pattern
• Resident Context Inventory — reducing what keeps riding along on every turn is that pattern; expelling what suddenly balloons in the moment is this pattern

Solution

Only two thin channels cross the boundary: the task handed in and the summary brought back. Whatever intermediate material balloons in between disappears along with the isolated context.

Why this works. It isn't that there's no other way to trim context. But the levers that do exist operate by folding up the conversation itself or by compressing the whole of it, and both act at the granularity of the entire conversation (this coarser-grained design is Session Boundary Design).

Neither operates at the fine grain of "drop just this investigation's debris and keep the conversation going." What we actually want to discard — the searches that missed, the wrong files — is smaller than a conversation, yet the tool's unit of discard is the conversation itself.

In other words, "read, then erase only what was read" is not an available choice. What is available is where the reading happens.

This pattern has the material read, from the start, in a place built to be discarded. Stand up a disposable context, hand it only the task, let it read as much as it needs, and cross the boundary exactly once, in the direction of the summary. What was read never crosses back. Once the work is done, that context disappears along with everything it read. From the main context's point of view, an investigation that reads a hundred files and one that reads three lines both land in the same handful of lines.

This only works when there's an asymmetry. Building the boundary pays off only when the input (volume read) far exceeds the output (volume brought back). For work where the two are close — editing exactly what was read, for instance — a summary just drops information without saving anything. Judging applicability by "is this a big task" misses the point. What matters isn't size but ratio.

How the boundary is designed determines the quality of the result. The isolated context knows none of the calling side's history. If the task handed over is vague, it can't judge what matters, and the summary comes back thin or off-target. The sender's job isn't to "hand over something short" — it's to make explicit what counts as a sufficient answer. Isolation only works as well as the handoff.

Trade-offs

Advantages

• The main context doesn't get dirtier in proportion to how much investigation happens. Even reading a hundred files leaves only a summary on the main side. The scale of the investigation is decoupled from the headroom left for the work that follows.
• Not knowing becomes an advantage. Because it receives no history, the isolated context isn't dragged along by prior framing. For a review that wants several independent perspectives, this ignorance is itself the point.

Costs

• A summary is an irreversible compression. What gets dropped is decided on the isolated side, and the caller never sees what was dropped. Even if the summary misses the mark, nothing survives on the main side to reveal that it did.
• Crossing the boundary costs something in both directions. Spinning up the context, writing the task, integrating the result — none of it is free. More round trips mean more consumption (the official docs say as much, below). For a small lookup, isolation costs more than it saves.

GitHub Copilot in Practice

Copilot isn't a single product. The mechanism behind this pattern exists in both VS Code and Copilot CLI, but where a human can intervene differs by surface.

VS Code — the main agent decides whether isolation is needed

Source: Agents concepts (retrieved 2026-07-16). The page defines the first characteristic of a subagent as follows Official:

Context isolation: each subagent runs in its own context window. It doesn't inherit the main agent's conversation history or instructions. It receives only the task prompt.

Focused results: only the final result is returned to the main agent, keeping the main context focused and reducing token usage.

Each subagent runs in its own context window, inherits neither the main agent's conversation history nor its instructions, and receives only the task prompt. Only the final result comes back. The boundary described in Solution is written here directly as a product specification.

The same page states plainly that the point of this mechanism is context optimization Official:

Without subagents, every file read, search result, and intermediate step during research accumulates in the main agent's context window, potentially crowding out important information. Subagents perform their work in a separate context window and return only a summary, keeping the main conversation focused on the task at hand.

The recognition that reads, search results, and intermediate steps accumulate in the main context and can crowd out important information, and the fix of "working in a separate context and returning only a summary" — this maps one-to-one onto this pattern's Problem and Solution sections.

The main agent is the one that invokes it (source: Subagents in Visual Studio Code, retrieved 2026-07-16) Official:

Subagents are typically agent-initiated, not directly invoked by users in chat. To allow the main agent to invoke subagents, make sure the agent/runSubagent tool is enabled.

The human's role isn't to order isolation every time — it's to set up the conditions under which isolation can happen. When invoking from a prompt file, include runSubagent or agent in the tools frontmatter.

The same page has this to say about how to hand off work Official:

To optimize subagent performance, clearly define the task and expected output.

The sender's responsibility described in Solution shows up here as an official recommendation too.

Searched, but not found Absence Confirmed

An early draft note in this catalogue considered labeling this mechanism #agent/runSubagent (with a # prefix) and citing the description "Run a task in an isolated subagent context." Having read both pages above (Agents concepts and Subagents in Visual Studio Code) in full on 2026-07-16, neither phrase appears on either page, and the notation is agent/runSubagent without the #. Neither is adopted here.

What's absent is the wording, not the feature. This doesn't confirm the #-prefixed notation is wrong — only that it isn't written on these two pages. It may still exist on other surfaces or in other material.

Copilot CLI — a human can instruct it explicitly

Source: Creating and using custom agents for GitHub Copilot CLI (retrieved 2026-07-16) Official:

Work performed by a custom agent is carried out using a subagent, which is a temporary agent spun up to complete the task. The subagent has its own context window, which can be populated by information that is not relevant to the main agent. In this way, especially for larger tasks, parts of the work can be offloaded to custom agents, without cluttering the main agent's context window.

A subagent is defined as disposable (a temporary agent spun up to complete the task) — a place that may be filled with information irrelevant to the main agent. This is where the "discard" in read-and-discard lands.

The CLI ships a built-in agent that embodies this asymmetry directly (source: About custom agents, retrieved 2026-07-16) Official:

task — A command execution agent that runs development commands (tests, builds, linters, formatters, dependency installs) and reports results efficiently. It returns a brief summary on success, and full output on failure, keeping the main context clean.

A brief summary on success, full output on failure — the volume brought back changes with the outcome. The product embeds the judgment that discarding is safe only "when things went well"; when it fails, the process itself is the information. This is directly usable as a design principle when deciding what to summarize in practice.

Parallelization can be instructed by a human via /fleet (source: Running tasks in parallel with the /fleet command, retrieved 2026-07-16) Official:

Context window: Each subagent has its own context window, separate from the main agent and other subagents. This allows each subagent to focus on its specific task without being overwhelmed by the full context of the larger task.

But the same page states the cost just as plainly Official:

Each subagent can interact with the LLM independently of the main agent, so splitting work up into smaller tasks that are run by subagents may result in more LLM interactions than if the work was handled by the main agent. Using /fleet in a prompt may therefore cause more GitHub AI Credits to be consumed.

Isolation isn't free. All the official docs state is that more round trips mean more consumption; how to weigh that cost is the subject of The Break-Even Point of Delegation.

Differences across surfaces

Surface	Human intervention point	Source
VS Code	The main agent judges whether isolation is needed. Humans enable agent/runSubagent and nudge it through how the prompt is written	Subagents in Visual Studio Code, above
Copilot CLI	Parallelization can be instructed via /fleet; a specific agent can be named in the prompt with @CUSTOM-AGENT-NAME	fleet page, above

The mechanism is the same "isolated context" on both surfaces, yet where a human can control it differs by surface. A blanket statement like "Copilot supports subagents" erases this distinction. In practice, VS Code puts more weight on designing the handoff so that isolation gets chosen, while the CLI allows explicit instruction via /fleet or by naming an agent.

That said, the official wording is "typically agent-initiated, not directly invoked by users in chat" — doubly hedged. It doesn't say VS Code can't be called explicitly. This catalogue doesn't read that as "cannot be called" — what's confirmed is only that it is typically agent-initiated.

Also Known As

Name	Source
Subagent	Primary — both VS Code's and Copilot CLI's official docs use this name for the subordinate agent working in an isolated context (source: in Practice section above)
Context isolation	Primary — the name VS Code's official docs give to the first characteristic of a subagent. Names a property, not a mechanism (source: in Practice section above)
Read-and-Discard Isolation	Descriptive — this catalogue's descriptive name; no primary source uses it

The official term Subagent names a mechanism. This pattern is a practice, and it holds even without the mechanism — investigating in a separate session or window and writing only the result back into the main task has the same structure regardless of tooling. Repurposing the mechanism's name for the practice means the practice gets overlooked in environments that lack the mechanism. So the practice is given a descriptive name of its own. Descriptive marks a name coined by this catalogue.

Related

• Failure as Institutional Memory — this pattern judges that the process of reading has no value worth keeping and discards it; that pattern judges that an incident that happened here has value worth keeping and retains it. Two ends of the same question: what earns the right to occupy context
• The Break-Even Point of Delegation — whether to isolate is this pattern's structure; what isolation costs is that pattern. The official docs note that running more in parallel means more LLM interactions (see in Practice)
• Session Boundary Design — if the unit discarded is the conversation itself, that pattern; if it's one section within a conversation, this pattern
• Resident Context Inventory — reducing what keeps riding along on every turn is that pattern; expelling what suddenly balloons in the moment is this pattern
• Keeping the Prefix Stable — works in the same direction. VS Code's official docs list, among the recommendations for not breaking the cache, "Isolate exploration in subagents: Run research in a subagent to keep the parent session prompt stable" (Cache Explorer, retrieved 2026-07-16) Official. Isolation keeps the parent session's prefix stable — the intermediate material this pattern expels from the main context is, from that pattern's point of view, volatile matter that would otherwise break the prefix. The same operation is justified for two different reasons
• If reading just one more next: The Break-Even Point of Delegation — having seen the structure of isolation, it's next to look at its price tag