deep-research: v2.3.0 — raised clarifying question caps (5/10), added tool selection strategy, post-dispatch no-polling rule; ask-testing: v1.0.0 — new peer agent for testing profile
This commit is contained in:
@@ -1,7 +1,7 @@
|
||||
---
|
||||
name: deep-research
|
||||
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.
|
||||
version: 2.2.0
|
||||
version: 2.2.1
|
||||
author: Hermes Agent
|
||||
license: MIT
|
||||
platforms: [linux]
|
||||
@@ -23,12 +23,12 @@ See `references/design-rationale.md` for the v2.0 architecture decisions and Cla
|
||||
|
||||
## Clarifying Questions (Before Dispatch)
|
||||
|
||||
If the operator's question is ambiguous enough that the research agent would waste the first ~20 turns guessing, ask clarifying questions BEFORE dispatching. Cap is tight on purpose — if you find yourself writing more than 5, the question itself is under-specified and the right move is to push back to the operator, not interrogate them.
|
||||
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.
|
||||
|
||||
**Limits:**
|
||||
- **Default cap: 3 questions.** Most well-formed questions need 0–3.
|
||||
- **Hard cap: 5 questions.** Only if the question has multiple high-stakes branches that genuinely change the research strategy.
|
||||
- **Abort at 6+:** If you think you need more than 5, 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 6+ questions.
|
||||
- **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.
|
||||
|
||||
**When to ask vs. when to dispatch:**
|
||||
- Ask when the answer would change the research strategy (e.g., "Are you researching a person, a company, or a topic?" — different toolkits).
|
||||
@@ -52,6 +52,19 @@ hermes -p research -s deep-web-research chat -q "<question>" -Q --max-turns 600
|
||||
hermes -p research -s deep-web-research chat --resume <session_id> -q "<follow-up>" -Q --max-turns 600 --yolo
|
||||
```
|
||||
|
||||
## Post-Dispatch Behavior (MANDATORY)
|
||||
|
||||
**After dispatching, continue working with the user. Do NOT poll, wait, or check for results unless the user explicitly asks.**
|
||||
|
||||
- The research runs as a background process. It will complete on its own.
|
||||
- Do NOT call `session_search` on the research session to check progress.
|
||||
- Do NOT call `process wait` or `process poll` on the background process.
|
||||
- Do NOT proactively surface results when the background process completes.
|
||||
- **Only check for results when the user explicitly asks** (e.g., "what did the research find?", "is it done?", "show me the results").
|
||||
- When the user asks, use `session_search` on the research profile with the captured session_id to retrieve and relay the condensed answer.
|
||||
|
||||
The session_id is captured from output line 1 and held in conversation context for follow-up questions and result retrieval. No state file needed.
|
||||
|
||||
## What the Research Agent Does
|
||||
|
||||
The `deep-web-research` skill on the research profile enforces:
|
||||
@@ -65,6 +78,28 @@ The `deep-web-research` skill on the research profile enforces:
|
||||
|
||||
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.
|
||||
|
||||
## Tool Selection Strategy
|
||||
|
||||
The research agent must determine the best tools for each research type — not use a fixed set. Analyze the question and select from the full arsenal:
|
||||
|
||||
| Research Type | Primary Tools | Secondary Tools |
|
||||
|---|---|---|
|
||||
| **Person/identity** | SearXNG (people search engines, social media), web scraping (full pages) | Browser (dynamic sites), Python (data enrichment) |
|
||||
| **Email/phone** | SearXNG (breach databases, public records), web scraping | Browser (captcha-walled sites), Python (pattern analysis) |
|
||||
| **Software/tech** | SearXNG (GitHub, docs, PyPI/npm), web scraping (changelogs, issues) | Terminal (live version checks), Browser (interactive docs) |
|
||||
| **Politics/news** | SearXNG (news category, multiple engines), web scraping (primary sources) | Browser (paywalled articles), Python (timeline analysis) |
|
||||
| **AI/ML** | SearXNG (arxiv, papers, HuggingFace), web scraping (model cards, benchmarks) | Terminal (live API probes), Python (data analysis) |
|
||||
| **General topic** | SearXNG (general + news + scholarly), web scraping (authoritative sources) | Browser (interactive content), Python (synthesis) |
|
||||
|
||||
**Tool selection rules:**
|
||||
- Always use multiple SearXNG engines per search — never rely on a single engine
|
||||
- For any claim about a live system, run a terminal probe (curl, ping, API call) — don't just search
|
||||
- For version-sensitive claims, check at least 2 independent sources (docs + GitHub + PyPI)
|
||||
- For paywalled or JavaScript-heavy content, use the browser tool
|
||||
- For data that needs aggregation or analysis, use Python in the terminal
|
||||
- Docker-based tools (SearXNG, Playwright) are available and should be used when appropriate
|
||||
- The research agent has full terminal, file, web, browser, and Python access — use all of them
|
||||
|
||||
## When to Use
|
||||
|
||||
- User says "deep research", "ask web", "research this", "deep dive on"
|
||||
@@ -103,6 +138,7 @@ The research agent self-reports are not verified fact. If it claims a file write
|
||||
5. **Don't re-condense.** The research agent already produced a condensed answer. Relay it, don't summarize it further.
|
||||
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.
|
||||
|
||||
## Pre-Dispatch Reasoning Check (MANDATORY)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user