Deep research¶
/deep-research <question> runs a multi-source research loop as a bundled
kind: workflow command: it
plans sub-questions, fans out parallel read-only researcher subagents,
adversarially reviews the digest for gaps, re-searches what's missing,
verifies that every cited URL actually resolves, and writes a cited report.
Like every workflow, the script is shown at the
ASK approval gate before
it runs, and every subagent it dispatches still passes the permission gate.
The researcher lanes use web_search, so a Brave key
is required.
Local question? Use /research
/deep-research is the web loop. For a question about this codebase
or repo material, the bundled /research <question> command is the local
sibling — it scales 1–5 read-only explorer lanes to the question's
complexity and synthesizes from
artifact handles,
with no web egress and no Brave key.
The loop¶
| Phase | What happens |
|---|---|
| plan | One researcher decomposes the question into the fewest sub-questions (1–4) |
| research fan-out | Up to 4 parallel researcher lanes, each budgeted to ≤ 8 web tool calls |
| adversarial review | A read-only critic attacks the digest's coverage and evidence; returns up to 3 gaps |
| gap re-search | Up to 2 more lanes on the gaps (one reflection round only — no open-ended looping) |
| verify citations | Every cited URL goes through the citation-liveness gate (below) |
| write | A writer lane synthesizes the report via structured output (schema=), citing only verified sources |
The caps are deliberate: worst case ≈ 44 web operations (4 lanes × 8 calls + 2 gap lanes × 6 calls) and ~10 subagents per run — sized for a single shared local GPU, well inside the workflow runtime's own ceilings. Intermediate research stays in script variables; only the final report re-enters your conversation.
The citation-liveness gate¶
Deep-research agents fabricate 3–13% of the URLs they cite, even with live web access (arXiv 2604.03173). The gate closes that hole with a hard rule the script enforces (not the model):
- every URL cited by any finding is checked with the
cite_checktool; - a live URL is cited as-is;
- a dead but archived URL is substituted with its Wayback Machine snapshot (the report notes the original);
- a dead, unarchived URL is dropped with a note — never silently kept;
- a URL the writer introduces that was never checked is dropped too.
The report ends with a citation-liveness: summary line (checked / live /
wayback-substituted / dropped) and a ## Sources section containing only
verified URLs. If the liveness check itself fails, the report says so loudly
and marks every citation UNVERIFIED rather than pretending.
The cite_check tool¶
cite_check is a standalone READ-kind tool (any agent with it in its toolset
can use it — the bundled researcher profile carries it). It checks a batch
of up to 32 URLs in one call without downloading page bodies: a HEAD
request per URL (falling back to a body-less GET when the server rejects
HEAD), the same SSRF guard as web_fetch on every hop,
and — for dead URLs — one lookup against the
Wayback availability API for an
archived substitute. It returns one JSON object per URL:
{url, status: live|wayback|dead, http_status, final_url?, wayback_url?, note?}.
It proves existence, not support — a live URL can still fail to back the claim citing it. Cross-verification of claims is the researcher lanes' job; the gate just guarantees you can actually open every source in the report.
The skill vs the command¶
The bundled deep-research skill is the
inline, single-agent variant of the same methodology (outline → fan-out →
verify + liveness-check → synthesize), useful when the question is small or
you want the research to happen in your conversation. The /deep-research
command is the orchestrated variant — parallel lanes, an adversarial
reviewer, and the script-enforced liveness gate. For a report you intend to
keep, prefer the command.