The big idea
Search answers queries. Research answers questions.
"What's the capital of France?" is a search. "Which vector database should we bet on, and why?" is research: it decomposes into dozens of sub-questions, needs sources that disagree to be reconciled, and ends in a cited report — not a snippet. Every major lab shipped a "deep research" agent for exactly this gap. What has to exist between a search box and a trustworthy report?
An orchestrated crew: a lead agent that plans and delegates, parallel sub-researchers with clean contexts, a shared evidence store of claims-with-sources, a budget that ends the loop, and a synthesis pass whose citations are verified, not decorative.
How to read this: Each step opens with a real design decision — make the call before seeing what ships. Watch the crew grow, hover any box, replay the flow. At the end, poison a source and watch the hygiene machinery fight back. Hit Begin.
Step 1 · The skeleton
A lead that plans, not a loop that wanders
Hand the whole question to one agent with a search tool and it wanders: chases the first interesting thread, forgets half the question, and declares victory when the context fills. Research needs structure before it needs searches. What's the first component?
Design decision: The user asks a broad, hard question. What happens first?
The call: A lead agent decomposes the question into sub-questions and a coverage plan. — "Compare vector DBs" becomes: performance benchmarks, pricing, operational maturity, ecosystem, migration cost — a checklist the rest of the system executes and audits against.
The Research Lead owns the question: it decomposes it into sub-questions, decides what "covered" looks like, and delegates. Planning first turns an open-ended wander into an auditable checklist — and gives every later component something to measure against.
Decompose, then search: The plan is the rubric. Without it you can't detect gaps, can't parallelize, and can't know when you're done. With it, research becomes a coverage problem — and coverage problems are engineerable.
Step 2 · Divide the question
Parallel sub-researchers, isolated contexts
Five sub-questions, each needing dozens of searches and long documents read. Serially, that's slow. In one shared context, it's worse than slow: benchmarks drown pricing, pricing drowns ecosystem, and the window rots before the report starts. How is the work split?
Design decision: How should the five sub-questions be worked?
The call: Parallel sub-researchers, each owning one sub-question with its own clean context. — Isolation is the point: each worker reads deeply within its lane and returns distilled findings. Fan-out buys speed; clean windows buy quality.
The lead spawns Sub-Researchers — one per sub-question, each with a fresh, task-scoped context. They run in parallel, dig deep in their lane, and report back findings. This is the isolate operation of context engineering, applied as an org chart.
Isolation as quality control: Sub-agents aren't just parallelism — they're context hygiene. Each window holds one question's material, so depth in one lane never crowds out another. The lead reads conclusions, not raw research.
Step 3 · The grind
Search, read, note — repeat
Inside one lane, what does a sub-researcher actually do? First results are rarely the answer: the good benchmark is on page two of a blog linked from a forum post. One-shot retrieval produces one-shot understanding.
Design decision: How does a sub-researcher work its sub-question?
The call: An iterative loop: search, open and READ promising sources, extract claims, refine the next query from what was learned. — Each round’s findings sharpen the next round’s queries — the agent follows leads like a human researcher, going deeper as its understanding compounds.
Each worker runs the search-read-note loop: query the Search/Fetch tools, open the promising results, read them properly, extract claims, and let each finding refine the next query. Depth comes from iteration — queries get smarter as understanding compounds.
Reading is the moat: The difference between shallow and deep research agents is literally whether they open the documents. Snippet-skimmers plateau at page-one consensus; readers find the primary source three links deep.
Step 4 · Write it down
The evidence store: claims, with receipts
A worker just read thirty pages. What flows upward — and what survives the loop? Raw transcripts overflow every window, and "I remember reading somewhere that…" is how hallucinated citations are born.
Design decision: What does a sub-researcher persist from its reading?
The call: Atomic claims, each paired with its exact source, confidence and date. — "Qdrant p99 = 12ms at 10M vectors — [benchmark URL, 2026-03]" is usable, checkable and compact. The report gets built FROM this store, so citations are structural, not decorative.
Workers write to a shared Evidence Store: atomic claims, each with source URL, quote, confidence and timestamp. Contradictions become visible (two claims, same topic, different numbers), and the eventual report can only say what the store can back.
Claims + sources, atomically: Pairing every claim with its receipt at WRITE time is what makes verification possible at read time. Break the pairing anywhere and citations degrade into vibes with URLs attached.
Step 5 · Know when to stop
Gap-driven iteration, under a budget
Research never feels finished — there's always one more source. Meanwhile every round costs real tokens and real minutes. Who decides between "keep digging" and "we know enough"?
Design decision: When does the research loop end?
The call: The lead audits the evidence against the coverage plan, dispatches another round only for real gaps — inside a hard budget. — Gap-driven iteration: "pricing lane is thin, benchmarks conflict — one more targeted round." The depth budget (rounds, tokens, dollars) caps it regardless.
Between rounds, the Lead reads the evidence store against its plan: covered, thin, or conflicting? Real gaps trigger targeted follow-up rounds; the Depth Budget — rounds, tokens, wall-clock, dollars — hard-caps the whole affair, with everything logged to the Trace.
Diminishing returns are measurable: Round one moves the report enormously; round four barely. Auditing coverage between rounds turns "when to stop" from a feeling into a measurement — and the budget makes overruns impossible, not just unlikely.
Step 6 · Write the report
Synthesis from evidence, not from memory
Time to write. The tempting shortcut: hand the model the question and let it write from everything it "learned along the way." That's how you get a beautiful report with claims nobody actually found.
Design decision: What does the synthesizer write FROM?
The call: The evidence store — every sentence traceable to stored claims and sources. — The report is a rendering of the store: structure from the coverage plan, claims from the evidence, disagreements surfaced explicitly with both sources shown.
The Synthesizer drafts the report from the Evidence Store: the coverage plan gives the structure, stored claims give the substance, and every sentence carries its citation. Where sources conflict, the report says so — presenting both, with dates and authority, instead of silently averaging.
Reports are renderings: Treat the report as a view over the evidence database, not a creative act. Anything the store can’t support doesn’t belong on the page — which is exactly what makes the next step enforceable.
Step 7 · The honesty pass
Verify every citation actually says that
The draft cites forty sources. Models are excellent at producing citations that look right — real URLs, plausible attributions — that don't quite say what the sentence claims. Ship that, and one wrong citation poisons trust in the other thirty-nine.
Design decision: The draft is written and cited. Ship it?
The call: Run a citation-verification pass: re-check each cited source against the sentence citing it. — A separate check re-reads the stored quote (or the live source) and asks one question per citation: does this actually support this sentence? Failures get cut, weakened, or re-researched.
The Citation Check walks every claim-citation pair with a narrow prompt: does the source support the sentence? Unsupported claims are cut or sent back for another research round. Only then does the report — with its now-load-bearing citations — go to the user.
Verification is a separate job: Generation optimizes for coherence; verification optimizes for truth. Splitting them — different pass, clean context, one narrow question at a time — is the same generator-verifier gap that powers every serious eval pipeline.
The payoff
You built a deep research agent
From a search box to a research organization: a lead that decomposes and audits, parallel sub-researchers with clean contexts, an iterative search-read-note grind, an evidence store of claims-with-receipts, gap-driven rounds under a hard budget, synthesis rendered from evidence, and citations that survive an independent check.
Now poison a source and watch the hygiene stack respond — source tracking, contradiction surfacing, authority weighting, and the citation check that refuses to let confident nonsense reach the report.
- Decompose first — the plan is the rubric everything audits against
- Sub-researchers — parallel lanes, isolated contexts, findings up
- Search-read-note — iterate; reading documents is the moat
- Evidence store — atomic claims paired with sources, always
- Gap-driven rounds — audit coverage, follow up only real gaps
- Depth budget — rounds/tokens/$ ceilings end the endless
- Synthesis = rendering — the report is a view over the evidence
- Citation check — every claim re-verified against its source