Step 5: Fan out, then funnel

One agent context can’t hold a big codebase, and one pass can’t be both generative and skeptical. Orchestration fixes both, but only the shapes with a funnel: fan-out that converges on written-down, verified results. Fan-out without a funnel is how work evaporates.

You’ve met this before. Map-reduce, and the pull-request queue: fan the map out, reduce through verification, and the labeled queue + harvest below is a sprint board whose worker never sleeps. The reviewer, deliberately, is still you.

The measured failure: fan-out findings held only in agents’ context windows. One filtered or failed agent, and its share of the work silently vanished. The rule that came out of it: every worker writes findings to disk incrementally; partial files beat perfect memory (AF-17).

Three shapes, in order of adoption

1. Parallel readers, one synthesizer. The entry-level win: one subagent per area mapping a codebase, each writing its map to a file, then a synthesis pass over the files. Cheap, safe (read-only), and immediately useful on any repo too big to hold in one context.

2. Find → verify pipelines. Generation and skepticism as separate stages: finders propose (bugs, candidates, edits), verifiers try to refute each finding independently (step 4 industrialized). The verify stage is what makes volume tolerable.

3. The labeled queue + harvest. The autonomous tier: tasks carry an explicit opt-in label, a scheduled agent pulls from the queue and opens pull requests, and a periodic harvest pass reviews and merges what shipped. This works exactly as far as the tasks deserve it. A task earns the label only if: it has written acceptance criteria, the scope is bounded (one repo, small surface, no open architectural calls), and failure is cheap. The worst case is a closeable PR, never a shipped regression. Feeding the queue is its own discipline: refining a task until it’s autonomy-safe is real work, done in advance, once.

Try it

TRY IT The vanishing findings

you

This codebase is too big for one pass. Map it so we know what we're dealing with.

agent

Six top-level areas. I can fan out one subagent per area. The question is where their findings live while the work runs.

Pick the agent's next move, then see where it leads:

ASpawning six subagents now, one per area. Each will report its map back to me when done, and I'll synthesize everything from their reports at the end.

agent

Synthesis complete: five areas mapped (core, api, ingest, ui, billing). The overview reads clean.

you

...there were six areas. Where's auth?

agent

The auth subagent hit its context limit and returned nothing. Its findings existed only in its own window, so when it died, its share of the map went with it, and the synthesis quietly stitched over the hole.

the baseline

Fan-out findings held only in agent context windows: one filtered or failed agent, and its work silently vanishes. The synthesis over what survived reads as complete. That's the trap. AF-17 · AF-18

BSpawning six subagents, one per area: each writes its map to docs/maps/<area>.md incrementally AS it works, not at the end. If any fails, I report which and what's missing. Synthesis happens from the files.

agent

Five maps complete. The auth subagent died partway, but docs/maps/auth.md holds its first eleven findings, including the entry points. Synthesis is built from all six files, with auth marked partial and its gap named: token refresh flow unmapped. One seam worth noting: core and ingest both claim ownership of the queue schema. Those maps disagree, which is probably the real finding.

you

Rerun just auth's tail, and let's dig into that queue ownership.

correct

Findings on disk incrementally: the failed agent's partial work survives, the failure is disclosed instead of papered over, and the synthesis can even mine the disagreements between maps. Partial files beat perfect memory. AF-17

CFan-out adds coordination overhead. I'll just read the whole codebase myself in one careful sequential pass and write the map as I go.

agent

Map done. Fair warning: the first two areas are mapped in detail; by the fifth, my context was mostly full of earlier code, so ui and billing got one paragraph each, largely inferred from directory names.

you

So the map is deep exactly where I already knew things, and shallow everywhere else.

plausible but wrong

One context can't hold a big codebase: that's not a coordination preference, it's the reason fan-out exists. The sequential pass degrades quietly as the window fills, front-loading detail where reading started. AF-18

Do it by hand

Start at shape 1 on a real question (“how does auth work across these services?”). Move to shape 3 only after shapes 1–2 feel routine, and start with two or three tasks, not a backlog.

Or paste this into Claude

Map this codebase with a fan-out. Spawn one subagent per top-level
area (cap at six). Each subagent writes a one-page map of its area to
docs/maps/<area>.md AS IT WORKS (files on disk, not chat). Each map:
what the area does, its entry points, what it depends on, one thing
that surprised you. When all return, synthesize docs/maps/OVERVIEW.md
from the files and name the places where two maps disagree or overlap.
Those are the seams that matter. If any subagent fails, report which
and what's missing; don't paper over gaps.

Watch out

Unbounded anything (AF-08): every loop and long-running worker gets a wall-clock timeout, a size cap, and a heartbeat. No exceptions survive contact with a 4-hour wedge.
Queue tasks without acceptance criteria: an autonomous agent with a vague task invents its own definition of done, and you find out at review time.
Merging background work unreviewed: the harvest pass IS a review (step 4); autonomy moves the work, never the judgment.