You end this module with one claim in your own project traced back to a saved, dated source — and a folder structure you can reuse the next time something needs checking rather than guessing at.
This is optional, picked up after Move from idea to evidence. It takes the "research before building" habit from the core and makes it something a second person can check without asking you anything.
It runs on the same discipline as a recurring procedure or a split build — named scope, kept evidence, a reviewer who opens the files.
What this module teaches
What the evidence says about many agents versus one
Two studies, cited honestly for what they actually measured, not for what would be convenient. A Mount Sinai clinical-AI study (npj Health Systems, March 2026) found orchestrated multi-agent setups degrade more slowly than a single agent as concurrent clinical tasks scale from 5 to 80 — a finding about coordination overhead versus task volume, not a Claude Code benchmark. A Google Research, Google DeepMind and MIT paper (arXiv:2512.08296, December 2025) ran 260 configurations across six benchmarks and found gains on parallelisable tasks, losses on sequential ones. Together they support one narrow claim: whether to fan out to many agents depends on the structure of the task, not on more agents always being better.
The brief with a pass test
"Research all competitors" is not a scope — it is a topic wearing a scope's clothes. A real brief names the goal in one sentence, names the items by name, states what each agent must save and where, says which sources are allowed and banned, and ends with a pass test written so it can be checked against the files themselves. No brief, no agents.
One agent per named item
Never one agent sent to cover a whole list. Each agent gets the goal, its own single item, its deliverable, the allowed and banned sources, the depth, the pass test, and the exact folder to save into. A list handed to one agent gets skimmed; a list split into named, single-item assignments gets checked.
Raw evidence kept untouched
Every agent saves what it found, as found, into a dated, named file — never a paraphrase, never a summary standing in for the source. Where a source can't be reached, that gets a dated log of the attempt, not a guess dressed up as a finding. This is what makes a later disagreement checkable: the raw file is still there to re-read.
Two review stops
Stop 1 checks the raw data itself before anything is written up: every named item present or logged, every claimed file actually on disk, no invented content. Stop 2 checks the finished report against those same raw files and argues with the reasoning. Both stops read the files, not the agents' own summaries of them — a summary can be wrong in ways a source file cannot.
The README paper trail
One file carries the folder map, both stops' status blocks, and a dated log — added to, never rewritten. A reviewer who joins on day nine should be able to read this one file and know exactly what's verified, what's still open, and what got overridden along the way, without asking anyone.
The assignment
There is no new snapshot for this module — the reference project stops at Core 3. Your own project stands in for it.
Your own project, plus one claim, comparison point or competitor fact you've never actually verified against a source.
A traceable research folder for that one item: a brief with a pass test, the raw source saved untouched, a verified insight that names where it came from, and a README paper trail.
Every claim in your output traces to a saved raw source, any gap is marked UNAVAILABLE instead of quietly filled in, and a reviewer who only opens the files — not your summary of them — reaches the same conclusion you did.
One agent or many, stated honestly
Both studies are supporting evidence for one narrow claim and nothing more. Neither is a Claude Code measurement, and neither is cited here as one.
| Study | What it actually measured | What it supports |
|---|---|---|
| Mount Sinai, npj Health Systems (Nature), March 2026 | Clinical retrieval, extraction and dosing tasks. Orchestrated multi-agent degrades more slowly than a single agent as concurrent tasks scale from 5 to 80. | Coordination overhead and task volume interact. Not a Claude Code benchmark. |
| Google Research / Google DeepMind / MIT, arXiv:2512.08296, December 2025 | 260 configurations across six benchmarks. Gains on parallelisable tasks, losses on sequential ones. | The fan-out decision depends on the structure of the task. |
Supported: whether to use many agents or one depends on the structure of the task. Not supported: any Claude Code performance figure. The rule this module follows either way — one agent per named item — comes from what makes research checkable, not from either study.
The Claude Code research skill, applied
Three real files, not a snapshot: the skill and its two templates as they run here. The only change made for publishing is that the review steps name a second reviewer on a different model rather than one specific tool.
The folder template
Every project uses this, no variations. A folder doing the same job under a different name gets its contents merged into the matching one — file names never change.
docs/
README.md paper trail: folder map, stop status, dated log
01_raw_data/
context/ brief, and anything the client provided to explain the work
research/ our external research, saved untouched
sandbox_data/ client data and what we pull (exports, API dumps, samples)
02_verified_insights/ checked findings and reports
03_assets/ Claude Design, prototypes, decksThe brief, with its pass test
No brief, no agents. "Research all competitors" is not a scope — ask for the names.
# Brief: <topic>
- date: YYYY-MM-DD
- requested by:
## Goal
One question, in one sentence. Example: which task-management tools let a small team export its project data.
## Scope
Named items, one agent each. Example: Trello, Asana, Linear.
## Deliverables
- Raw: what each agent must save, and where (`01_raw_data/research/`)
- Verified: the fields every item must end up with (`02_verified_insights/`)
- Output: the report, and who reads it
## Tools
Which tools agents may use.
## Sources
- Allowed:
- Banned:
## Amount
How many sources per item.
## Depth
Snapshot of the page, or the full document.
## Pass test
What "done" means, checkable on the files. Example: every named item has a saved
source document or a dated log of the failed attempt, and every verified field is
filled or marked UNAVAILABLE.One agent per named item, raw evidence kept
Each agent gets the goal, its own single item, its deliverable, the allowed and banned sources, the depth, the pass test, and the exact folder to save into. It saves the source material untouched, named <source>__<subject>__<topic>__YYYY-MM-DD.ext, and logs the item as included with its file or excluded with a source-backed reason. A source that couldn't be reached gets a dated log of the attempt — never a guess.
Two review stops, and a re-run that flags disagreement
Stop 1 checks the raw files: every named item present or logged, every claimed file on disk, no invented content. Nothing moves to 02_verified_insights/ until that stop is clear. Stop 2 checks the finished report against those same raw files and argues with the reasoning. Between the two, the same brief runs again in one fresh agent — more than 10% disagreement between the two runs gets written into the report, not smoothed over.
# <project or topic> research
Workflow: `01_raw_data -> STOP 1 REVIEW -> 02_verified_insights -> STOP 2 CHALLENGE -> final`
## Stop 1 — raw data review
```text
status: NOT_STARTED | READY_FOR_REVIEW | ISSUES_FOUND | CLEAR
reviewer_result:
second_reviewer_result:
submitted_on:
decision_on:
```
### Review notes
Added to, never rewritten. One section per pass, dated, with the verdict and the rework list.
## Stop 2 — challenge
```text
status: NOT_STARTED | IN_PROGRESS | CLEAR
second_reviewer_result:
submitted_on:
decision_on:
```
## Decisions and overrides
Dated. What was decided, by whom, and the trade-off accepted.
## Log
- YYYY-MM-DD — what happened.Common mistakes
Agents sent with a topic instead of a goal, scope and pass test
Write the brief first, every time.
One agent told to cover the whole list
One agent per named item.
Findings written straight into the report folder
Nothing enters 02_verified_insights/ before both stops are CLEAR.
Reviewer reads the agents' summaries
The reviewer opens the files.
A gap quietly filled from a nearby fact
Mark it UNAVAILABLE, plus a dated log of the attempt.
Make every claim traceable to a source
The free research skill, the folder template it fills, and the reviewer prompts that check the saved files rather than the summaries.
The traceable research skill and its templates
Research runs one agent per named item, keeps every raw source, marks what it could not find, and stops twice for a reviewer who opens the files.
A claim with nothing behind it“Replit is SOC 2 compliant.”
True or not, nobody can check it without redoing the search, and nothing says whether it covers the product or the company behind it.
The same claim, traceableThe same claim, as the skill records it
Quote · link · date · scope
- Quote
- The sentence copied word for word from the tool's own page, not a summary of it.
- Source
- The link it came from, and the date it was checked.
- Scope
- “Covers the builder: stated / not stated” — a certificate held by the company does not automatically cover the product.
- Gaps
- Two pages would not load. They were marked unread rather than filled in, and the review caught that one of them was readable after all.
FAQ
Want research your team can actually trust?
We run traceable, source-backed research on real client projects — named scope, a pass test, and a reviewer who opens the files.
Core 3 runs the same "check it before you build it" habit on a single build
Core 2 covers the dev-docs convention this module's README paper trail sits beside
Specialist 4 turns a repeated procedure like this one into a skill of your own
Specialist 5 splits independent work the same way this module splits research agents
The course
Core modules first. Specialists are optional — take the one that matches your work.
- Core 1
Stop Claude guessing
Turn a vague idea into a brief Claude can build from: facts, assumptions marked as assumptions, agreed success criteria.
- Core 2
Stop starting over
Set up project memory so a fresh session, or a teammate, can pick the work up from the files alone.
- Core 3
Move from idea to evidence
The route from brief to reviewed change: research, one shared page, a prototype, a plan, a small build, a second opinion.
- Specialist 4
Automate recurring work
Encode a procedure you repeat as a skill, and fire it automatically with a hook.
- Specialist 5
Build in parallel
Run two pieces of work at once without them blocking each other, then review how they fit together.
- Specialist 6
Run research you can trace
Research where every claim traces back to a saved source, and gaps are marked instead of filled in.
You are here - Standalone
MCP or a single API call
A judgment call on two axes: what it costs you in context window, and how much access it opens.
Behrad Mirafshar
Founder, Bonanza Design
Founder of Bonanza Design. Builds operating brains for companies in the AI knowledge crisis. Multi-week engagements, run on the client's infrastructure, owned by the client.
Connect on LinkedIn