Sub-agents and isolation

The disagreement, stated fairly#

In June 2025 two credible teams published opposite conclusions, one day apart. Most writing since has picked a side instead of finding the axis that separates them.

Both are correct, and treating this as a matter of taste is the mistake.

Research is additive: two agents finding two facts gives you two facts, and "union" is the way to combine them. Implementation is interlocking: two agents building two components must agree on a hundred unstated conventions, such as error shapes, naming, null handling, logging and what a return value means. Each is an implicit decision, made independently, and independent decisions do not compose.

This is a property of the work, not of the architecture. That is why the argument cannot be settled in general and is easy to settle for a given task.

The composability test#

Apply it before delegating. Four questions; a "no" to any one means do not parallelise. See composability.

1. Is the way to combine the outputs trivial? Can you say in one sentence how they merge: "concatenate the findings", "union the file lists", "take the most severe result"? If combining needs judgment, you have not delegated work. You have deferred an integration problem and made it harder, because the reasoning behind each part is gone.
2. Can you write the output schema in under 20 lines? If the result needs prose to explain itself, the sub-agent held something the schema cannot carry, and the parent will need it.
3. Are the implicit decisions already fixed? List what the sub-agent must decide that is not in its brief. For a search task: nothing. For "implement the retry logic": backoff strategy, jitter, maximum attempts, which errors are retryable, logging, metric names, where config lives. That is seven decisions another agent might make differently. Fix them in the brief or do not delegate. A brief that fixes all seven is dictation, and you have done the thinking anyway. That is not failure. It is recognising that the thinking was the work.
4. Can the parent verify the result without redoing it? "Return the file and line where X is defined" takes one read to check. "Return a refactored module" takes a review as careful as writing it. Unverifiable delegation moves work; it does not remove it.

What isolation buys, and what it costs#

The benefit is real and specific#

Isolation turns a large intermediate context into a small result. A survey that reads 45K tokens and concludes in 350 tokens returns under 1% of its context to the parent — chapter 3's M-9 numbers: about 9K total tokens isolated versus 15K accumulating P.

The parent's context stays clean and dense. It never sees the 40 files that turned out to be irrelevant, so they never become distractors for the rest of the session. The benefit is the dilution avoided, not only the tokens saved.

The cost is larger than usually reported#

The 80% figure deserves a moment. If spend explains most of the gain, the architecture is largely a way of spending more tokens productively. The real question becomes whether the same spend used differently (more attempts, a better model, longer single-agent runs) would buy as much. For research tasks, apparently not: parallel exploration genuinely helps. For coding, which is more sequential and interlocking, there is no comparable published result. Do not import the research finding into your coding agent without testing it.

Contract loss#

Contract loss is the failure the parent cannot fix on its own. The sub-agent read a file that revealed the real cause and returned only what was asked. The parent cannot know what it was not told, and when the sub-agent ends, its context is gone.

Mitigations, most effective last:

1. The "notable observations outside scope" field from chapter 3's M-9. Cheap, and it recovers a surprising amount.
2. Return file:line pointers instead of conclusions, so the parent can re-derive cheaply.
3. Save the sub-agent's transcript to a file and give the parent the path. This turns contract loss into offload: the parent can read it if the summary is not enough. It is the best available answer and rarely done.

Five topologies#

Ordered from least to most isolation.

The boundary problem#

Every isolation boundary is a lossy channel. What crosses it is what survives. The four kinds of boundary differ in how much control you have.

This ranking is a strong, under-appreciated reason to prefer resets over compaction that has nothing to do with tokens: with a reset you author what survives.

Five principles for designing boundaries:

1. Make the boundary explicit. A boundary you did not design, such as an eviction firing mid-task, is one you cannot reason about.
2. Write the contract before crossing. Before delegating or resetting, write down what must survive. Writing it changes what you do.
3. Pointers cross better than prose. file:line survives compression, paraphrase and re-reading. A description of what is at that line does not.
4. Verification claims must carry their method. "Tests pass" cannot be checked later. "pytest tests/checkout -q → 47 passed, at commit a3f9c1" can.
5. Cross once. Every extra boundary compounds loss. Two compactions, a delegation and a reset put the original task statement through four lossy channels.

The sub-agent contract#

## Task
<one sentence>

## Scope
In:  <paths, modules, the question>
Out: <explicitly out of scope>

## Tools available
<the minimum set; narrow tool sets are the main quality lever>

## Fixed decisions (do not re-decide)
- <any convention the parent has already chosen>

## Output schema
findings:
  - path: <file:line>
    what: <one line>
    confidence: high|medium|low
notable_outside_scope:      # the contract-loss mitigation
  - <anything surprising you saw>
transcript_path: <written on exit, so the parent can recall it>

## Limits
max_result_tokens: 1500
max_turns: 25

Three fields do the heavy lifting. Fixed decisions prevent implicit-decision conflicts. notable_outside_scope recovers contract loss. transcript_path turns contract loss into offload. The version with a pre-check is in the templates appendix.

When not to isolate#

• The task fits comfortably in one context. All overhead, no benefit.
• The work interlocks. Question 3 says no.
• You cannot verify the result cheaply. You have moved work, not removed it.
• Cost is your binding constraint. Isolation raises total spend by design.
• You are debugging. Debugging is a chain of dependent inferences. Splitting it breaks the chain, and the sub-agent's dead ends, the most valuable part of a debugging trace, die with it.
• The task is short. Under about 20 turns, the prefix tax dominates.

The last two are the ones people get wrong most often.

Measuring isolation#

The redo rate is the most diagnostic. A high value means you pay the full cost of isolation for a fraction of the benefit, and you can measure it by reading five transcripts.