Appearance
Deploy cheap parallel scouts to harvest ground truth from the codebase before the planner writes a single task — so the plan is anchored in what's actually there, not what the planner assumed.
Guide
How to Scout Before Planning
Why scouts exist
Planners that haven't read the code are guessing.
planner alone
Writes tasks from assumed structure
01receives requestok
02infers from training priorguess
03emits task listguess
04workers hit realitybreak
Plan collapses on first file that doesn't look like the prior. The planner self-assessed its own assumptions — the failure mode Trust But Verify names.
planner + scouts
Writes tasks from a scouted briefing
01receives requestok
02scouts fan out in parallelread
03reports return, planner synthesizesverified
04emits grounded task listanchored
Plan is anchored to real files, real line numbers, real unknowns. The investigative pass is independent of the planner's context window.
Scouting isn't extra work — it's the work the planner was pretending to do anyway.
The reading path
Six nodes. In this order. Each answers the next "why."
1
Trust But Verifyprinciple
Why scouts exist at all. An agent cannot reliably self-assess its own code — the context window that generated the assumption is the one evaluating it. An independent investigative pass is the architectural response to that limitation, not a nice-to-have.
2
Minimum Contextprinciple
Why each scout gets a narrow slice. Scouts given full project context produce noisy, unfocused reports. Scope the context to the single question the scout must answer — anything more invites hallucinated connections.
3
Scout Reportprimitive
What a scout returns. A structured artifact — findings, confidence levels, explicit unknowns. Define this before deploying: the report format is what lets the planner consume output without interpretation overhead.
4
Agentprimitive
What a scout is. A discrete agent — system prompt, tool access, single-purpose constraint. Scouts are agents, not inline planning steps. One agent, one question, one report.
5
Scout Swarmpattern
How you deploy them. Multiple scouts running in parallel — mix of higher-capability and lower-cost models assigned by question complexity. The swarm produces a portfolio of Scout Reports the planner consumes as a synthesized briefing.
6
Architecture is Agent Performanceprinciple
Why parallel beats one deep reader. Latency, cost, and coverage all improve when investigative work is distributed. How many scouts and at what capability tier directly determine plan quality.
Read top-to-bottom. Each step justifies the next — skip one and the chain breaks.
What it looks like in practice
One question fans out. One briefing comes back.
Parallel fan-out · structured fan-in · one planner.
Request
"add OAuth to the API"
→
split by
question
Scout
auth layout
high tier
Scout
API routes
low tier
Scout
session store
low tier
Scout
test conventions
low tier
→
structured
reports
Report
findings + unknowns
Report
findings + unknowns
Report
findings + unknowns
Report
findings + unknowns
→
synthesized
briefing
Planner
grounded
task list
Scouts run in parallel — latency is the slowest scout, not the sum.
Tiering by question complexity is where the cost math works out: most reads are cheap-tier jobs.
The six nodes, at a glance
Pick a card if you need a deeper dive.
principle
Trust But Verify
The epistemic ceiling on self-review — why independent investigation is structural, not optional.
principle
Minimum Context
Scope-per-scout. Full context breeds noise; sliced context keeps reports actionable.
primitive
Scout Report
The output artifact — findings, confidence, unknowns. The contract the planner consumes.
primitive
Agent
A scout is an agent. System prompt, tools, single purpose — not a planning substep.
pattern
Scout Swarm
The deployment shape. Parallel scouts, mixed tiers, portfolio of reports into one briefing.
principle
Architecture is Agent Performance
Why the distributed shape wins. Scout count and tier directly move plan quality.
Three principles frame the why, two primitives define the what, one pattern specifies the how.
Where to go after
Scouts returned. Now what?
adjacent guide
how-to-prompt
Once scouts return their reports, the planner's prompt needs to be structured to consume them correctly. Start here to shape the planner side of the handoff.
adjacent guide
how-to-build-metaagents
Scout swarms are a multi-agent pattern. This guide covers the broader orchestration layer they slot into — when scouts become part of a larger composed system.
The discipline
No planner writes tasks before something has read the code.
Scouts are cheap, parallel, and scoped. The briefing they produce is the ground truth the plan stands on. Skip the scout pass and the plan is a guess wearing a task list's clothes.