Three patterns that earn the overhead

A fan-out / synthesize run

1. Task: compare 5 vendors
2. Parent writes 5 briefs up front

   The fan-out test: every brief can be written before any worker starts. If brief 3 depends on worker 1’s findings, this is a pipeline, not a fan-out.

3. Worker 1 — vendor A (fresh context)

   Fills its disposable window with vendor A’s docs, pricing pages, changelogs. None of it will survive — by design.

4. Worker 2 — vendor B (fresh context)

   Runs concurrently. Workers share no state, so wall-clock time approaches the slowest worker, not the sum.

5. Workers 3–5 (fresh contexts)

   Same brief template, one variable swapped. Identical return formats make the reports mechanically comparable.

6. Reports return — one page each

   The parent now holds ~5 pages instead of ~5 crawled websites. This is the entire economic argument in one node.

7. Gaps or contradictions?

   Two reports disagree on vendor C’s rate limits? Don’t guess — spend one more cheap, targeted delegation.

8. Targeted follow-up brief

   A narrow brief for exactly the gap: “Resolve: does vendor C throttle at 100 or 1,000 rps? Return one number with a source.”

9. Parent synthesizes comparison

   Synthesis happens in a clean window that holds the goal, the user’s constraints, and five tight reports — nothing else.

10. Recommendation delivered

Fan-out research

Earns the overhead via: parallelism + isolation, multiplied.

Test: several slices, each generating bulk the parent never needs verbatim, with every brief writable up front. Use one brief template with a variable slot — identical return formats make reports mechanically comparable at synthesis time.

Trap: hidden dependencies. If worker 2 would do its job differently after seeing worker 1’s findings, the slices aren’t independent — you have a pipeline wearing a fan-out costume, and forcing it parallel means every worker guesses at what a neighbor already knows.

Isolated risky work

Earns the overhead via: a privilege boundary, not just a context boundary.

Parsing an untrusted upload, browsing an unvetted website, running generated code — give the job to a subagent with no credentials and narrow tools, ideally sandboxed. If the input carries a prompt injection payload, the hijacked agent holds nothing worth stealing: you have structurally removed a leg of the lethal trifecta instead of asking a prompt to resist persuasion.

Trap: isolation that exists only in the prose. A “restricted” subagent that in fact inherits the parent’s full toolset is a boundary written in wishes. The runtime must enforce the narrower privileges — this is least privilege made structural, and the security domain drills it hard.

Fresh-eyes review

Earns the overhead via: independence — the one thing the parent cannot give itself.

An agent that just wrote 500 lines reviews them inside the context that produced them: its window holds every assumption and rationalization that led to the bug. A review subagent that receives only the diff and the requirements — not the authoring conversation — re-derives its judgment from scratch. Same reason the debate pattern demands critics that don’t share the proposer’s context.

Trap: helpfully passing the reviewer “background” from the authoring session. Every bit of shared context is shared blind spots; the emptiness of the reviewer’s window is the feature you are paying for.