What you end this module with
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.
Optional: the core plus the hub's takeover test is what completes the course.
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. That is 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.
Starts from
Your own project, plus one claim, comparison point or competitor fact you've never actually verified against a source.
Required output
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.
Passes when
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
| Mistake | Fix |
|---|---|
| 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.
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, traceable
| What the skill records | |
|---|---|
| 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,” since 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. |
- 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
