§01 The failure mode
The naive way to use concurrency is to hand the same task to several agents and take the best result. This works for generation. It does not work for anything that touches state.
When several agents can all edit, the operator's job silently changes from directing work to reconciling conflicting work. That is a worse job. It scales badly, it requires holding every agent's reasoning in your head at once, and it produces the specific kind of exhaustion where you stop reading diffs carefully around the third one.
The division that holds up: many readers, one writer. Agents that only look are cheap to run concurrently, because their outputs merge trivially — a map of one territory does not conflict with a map of another. Agents that change things are serialized through a single decision-maker who holds the whole picture.
§02 What a scout is for
A scout answers where does this live and what shape is it. It does not answer what should we do. That distinction is the entire discipline.
A well-scoped scout task looks like: find where projects are defined in this repo, quote one existing entry verbatim so I can copy its shape, tell me every file that must change to add another, and do not modify anything. It comes back with paths, formats, and constraints. The decision about what to actually write stays with the operator.
The reason this works is that reading is where the token cost and the context bloat live, and it is also the part that parallelizes without coordination. Four unrelated repositories can be mapped at once by four agents that never need to know the others exist.
§03 The session
A concrete run: four codebases, unrelated to each other, four scouts dispatched concurrently. A single-page Svelte app with hand-written markup and no data layer. A SvelteKit site whose blog posts are flat markdown but whose metadata is hardcoded in three separate files. A zero-build static site of hand-authored HTML with JSON-LD in every page. A Create React App with no content layer at all.
Two findings from that run are worth reporting, because they are the kind of thing that decides whether the subsequent edit is correct or a broken deploy.
A premise was wrong and the scout said so. The dispatch described one of the four as a Svelte site. It was not — it was Create React App, and the scout's first line was the correction. Every plan downstream of that assumption would have been wrong. An agent with edit authority and an agreeable disposition would have started writing Svelte into a React project.
A constraint surfaced that no diff would have shown. In the single-page app, the project cards sit in an absolutely-positioned grid inside a container with hardcoded minimum heights per breakpoint. Adding one card adds a row, and the row overflows the container into the footer. The scout reported the constraint alongside the format. The edit that followed changed two things — the card and the container heights — and shipped clean. An agent that only knew "add a card like the others" would have shipped a visually broken page that compiles perfectly.
That second one generalizes. The expensive knowledge in a codebase is rarely the pattern. It is the constraint next to the pattern. Scouts are good at surfacing those precisely because they are reading rather than producing, and there is no pressure toward a finished-looking answer.
§04 Where it stops working
Three limits we keep hitting.
Scouts inherit your framing. Ask "where is the blog" and a scout will tell you where the blog is. It will not tell you the blog is the wrong place for what you're about to write. Judgment about whether a task is worth doing does not delegate — the operator who dispatched four agents is still the only one who knows why.
Summaries lose the thing you didn't ask about. A scout returns what its prompt asked for. Detail outside the question is dropped, and you cannot tell from the report what was dropped. The mitigation is asking for verbatim quotes of real code rather than descriptions of it — a quoted block carries the details your question failed to anticipate.
Parallelism is bounded by your reading speed, not theirs. Four scouts return four reports that one human must actually read. Past roughly that number, the operator becomes the queue. This is the same ceiling we keep measuring in the product — the bottleneck is never the model, it is the person integrating what comes back.
§05 The rule
Concurrency for reading. Serialization for writing. One context that holds the decision.
Stated that way it sounds obvious, and it is — it is roughly how a competent team of humans already works. The reason it needs saying is that the tooling makes the opposite easy. Spawning five agents that can all edit is one command, and it feels like leverage right up until you are refereeing five diffs against a codebase none of them fully read.
What we're testing next is whether the writer role can hand off cleanly mid-task — whether a decision-maker's context can transfer to a fresh one without the receiving agent quietly re-deciding things that were already settled. Early attempts say no. We don't yet understand what would have to be true for it to work.
The examples in this post came from ordinary product work rather than a benchmark — multi-repo edits, a Godot game's web build, and the analytics behind a small browser game that happens to be a convenient test subject because it is real, shipping, and has users who notice when something breaks.