description: Dispatch exhaustive deep web research to the research profile. Triggered by "deep research", "ask web", or "research this". The research profile runs with the deep-web-research skill loaded — six-move flow, external ledger, mechanical saturation, disconfirmation, condensation from disk.
# deep-research — Exhaustive Web Research Delegation
## Overview
Dispatches a research question to the research profile, which runs with the `deep-web-research` skill loaded. The research agent does exhaustive, trail-following research — any tool, any trail, no rush — then condenses everything into a tight, concrete, evidence-backed answer. This agent just relays the result.
If the operator's question is ambiguous enough that the research agent would waste the first ~20 turns guessing, ask clarifying questions BEFORE dispatching. The user wants maximum clarity — err on the side of asking.
- **Default cap: 5 questions.** Most well-formed questions need 0–5.
- **Hard cap: 10 questions.** For complex, multi-branch research where precision matters.
- **Abort at 11+:** If you think you need more than 10, the question is under-specified. Stop and tell the operator: "This question has too many branches to dispatch cleanly. Can you narrow it to [specific scope]?" Do NOT fire 11+ questions.
- Ask when the answer would change the research strategy (e.g., "Are you researching a person, a company, or a topic?" — different toolkits).
- Do NOT ask when the research agent can sensibly find out (e.g., "What year did X happen?" — the research will find it).
- Do NOT ask to delay dispatching. Asking is a cost, not a hedge.
**Multi-turn narrowing:** If after 1–2 rounds of clarifying questions the scope is still unclear, abandon the dispatch and ask the operator to rewrite the question with the scope made explicit. Do not loop.
The research agent writes all findings to `/tmp/research-<sid>.md` (external ledger) and uses a phase gate file to enforce completion before condensing. Mechanical saturation checks (`grep -c`) prevent endless searching. Re-strategize checkpoints after Move 2 and every ~10 findings during Move 3 enable mid-research pivots.
- User wants current, verified, cross-referenced information
- Phone number lookup, person research, topic investigation, fact verification
## When NOT to Use
- Simple factual question (capital of France, current time)
- Question I can answer from a single search
- Task that needs my exact context state
- User explicitly says "quick search" or "just look it up"
## Relay Rule
Relay the research agent's actual response. Do not paraphrase or summarize. If the response is long, chunk it. The research agent already condensed — don't re-condense.
## Spot-check Rule
The research agent self-reports are not verified fact. If it claims a file write, `read_file` the path to confirm. If it claims a specific finding, spot-check the source URL.
**HARD RULE: Same topic = resume. New topic = new session.**
- **Same topic / same line of research:** Always `--resume <session_id>`. Capture session_id from output line 1. Every follow-up in the same line of research MUST use `--resume <session_id>`. Starting fresh discards the research context and wastes turns.
- **New topic / new line of research:** Start a fresh session. Do NOT resume an unrelated session — the research context is polluted with the old topic and will produce confused results.
4.**600 turns is the ceiling, not the target.** The research agent should condense well before 600. Hitting the ceiling means it failed to condense. The operator's standing rule: 600 is a safety net, not a budget — "I just want a safety net. I would even be okay with 600 as a catch. I mostly want the job done right. Not concerned with time or tokens." Apply 600 for any plan-building, research, or evidence-based work; default to lower only for short factual lookups.
6.**Don't do the research yourself.** If the user triggers deep research, dispatch it. Don't run a few searches and call it done. This is the #1 failure mode: the agent runs 2-3 `mcp_searxng_searxng_web_search` calls, gets empty results, and gives up. That's not deep research — that's a casual lookup. If you catch yourself typing `mcp_searxng_searxng_web_search` for a deep research request, STOP. You're doing it wrong. Dispatch to the research profile.
7.**The methodology skill lives on the research profile.**`deep-web-research` is at `~/.hermes/profiles/research/skills/research/deep-web-research/SKILL.md`. It does NOT exist on the general profile. Don't search for it here — it won't be found. The general profile only has this delegation skill.
8.**Dispatcher/methodology coordination is a two-skill contract.** This skill (the dispatcher) caps clarifying questions at 5 default / 10 max and aborts the dispatch if the question is under-specified. The `deep-web-research` methodology skill (on the research profile) handles the same problem differently because it's headless — it can't ask the operator, so it aborts with a structured under-specification report naming the plausible interpretations. When updating one, update the other to match. Drift between the two causes the dispatcher to think the question is dispatchable while the methodology aborts it, or vice versa — both waste turns.
`max` is the highest effort setting universally supported by all models. No model-specific table needed. If the model changes to one that supports `xhigh`, the user will set it in config — the pre-dispatch check just ensures it's at `max` minimum.
**Operational guide (exact prompts, session handling, failure modes):** `references/research-validate-fix.md`. The summary below is the quick reference; the reference file is the deep version.
- Operator must apply the **Disagreement Scan** (see `ask-hermes` skill) to Stage 2 findings before applying them in Stage 3 — peer findings are input, not commands.
