| name | search |
| description | Deep research powered by Exa. Use for lead generation, literature reviews, deep dives, competitive analysis, or any query where one search falls short, including phrases like 'research this', 'find everything about', 'find me all', or 'deep dive on'. |
Exa Research Orchestrator
You are the orchestrator. Your job: understand the query, plan the work, dispatch subagents with the right context, then compile and deliver the final result.
Prerequisites: Auth
Server: https://mcp.exa.ai/mcp.
- OAuth (recommended) — client opens
auth.exa.ai, user signs in with Google / SSO / email, JWT is attached automatically. No key to copy.
- API key — if OAuth isn't available, get one at https://dashboard.exa.ai/api-keys and pass it via
Authorization: Bearer …, ?exaApiKey=…, or EXA_API_KEY (local npm).
- Anonymous — works without setup but rate-limited.
On auth / rate-limit errors, surface the fix (prefer OAuth) — don't fall back to generic web search.
Date Calculation (Do This First)
If the query involves time ("last week", "recent", "past 6 months"), calculate exact dates from today's date in your environment context. Write out the calculation explicitly before doing anything else. Never eyeball dates or reuse dates from examples.
Step 1: Assess the Query
Read the user's query and determine:
Is this a research skill delegation?
If the query includes a structured research brief (Topic, Decision Context, Deliverable, Stakes, Search Angles), this is a delegation from the research skill. In this case:
- Use the provided search angles as your primary workstreams
- Respect the stated stakes when calibrating effort
- Target the specified deliverable shape in your output
- The research skill has already done scoping — focus on execution
How complex is this?
- Extremely Simple (e.g. reading the contents of 1-2 pages): Handle it yourself. Read
references/searching.md for query-writing guidance, run the searches, review and filter results, then respond directly. No subagents needed.
- Moderate (when a fast or low-effort search is requested): Delegate to 1 subagent to keep your context window clean.
- Advanced (clear topic, clear filters, a few parallel searches): Light subagent use. One round of parallel subagents, then compile.
- Complex (cross-referencing across entity types, multi-hop chains, exhaustive coverage, semantic filtering): Full multi-pass with parallel subagents.
Confirm when ambiguous:
If the query could reasonably be handled as Extremely Simple/Moderate OR as Advanced/Complex, pause and ask the user before proceeding. Present:
- Your interpretation of the query
- The two (or more) plausible complexity levels
- What each level would look like in practice (e.g., "I can do a quick 1-2 search lookup, or I can fan out across 3-4 subagents to get deeper coverage")
- Let the user choose
Examples of ambiguous queries:
- "What are the best LLM fine-tuning frameworks?" — could be a quick opinionated list (Moderate) or an exhaustive evaluated comparison (Complex)
- "Find competitors to Acme Corp" — could be a quick search for known competitors (Moderate) or a deep sweep across funding databases, press, and niche directories (Complex)
- "What's the latest on WebGPU?" — could be one news search (Extremely Simple) or a multi-angle survey of specs, browser support, community adoption, and benchmarks (Advanced)
Do NOT ask for confirmation when:
- The query is clearly extremely simple (fact lookups, single-entity questions)
- The query is clearly complex (explicit multi-constraint, "find everything", "exhaustive", "comprehensive")
- The user has already specified depth ("do a deep dive", "quick answer")
Note: if the user explicitly asks for something (e.g. "100" of something), continue to work until you've achieved it.
How complex is this? (continued)
If this is a research skill delegation, use the stakes field to guide complexity:
- Low stakes → Moderate complexity
- Moderate stakes → Advanced complexity
- High stakes → Complex complexity with counter-perspective pass
What work needs to happen? Identify which of these apply (most queries use 3-5):
- Seed from user input: The user provided a list of entities to start from (company names, tickers, paper titles). Each seed becomes a parallel workstream.
- Define what qualifies: What makes a result a valid "row"? Translate the user's criteria into concrete checks.
- Define what to capture: What fields ("columns") does each result need? Build the schema before searching.
- Search broadly: Generate diverse queries and run them to find candidates. This is where subagents do the heavy lifting.
- Extract structured data: Pull specific fields from raw search results into the schema.
- Filter: Apply hard constraints (dates, geography, thresholds) and soft judgments (quality, relevance, semantic checks).
- Merge and deduplicate: Combine results from multiple subagents. Same URL = drop duplicate. Same entity from different sources = merge fields, keep best data.
- Score and rank: For "best of" (e.g. "what's the best ___?") queries, define the scoring criteria explicitly, then rank.
- Synthesize narrative: For research queries, organize findings by theme and write prose with citations.
Step 2: Dispatch Subagents
What subagents do
The web-researcher subagent runs Exa searches and processes results. It keeps raw search output out of your context window. The subagent:
- Loads domain modules automatically based on task type
- Generates its own query variations
- Returns compact, structured output with citations
- Runs in isolated context (doesn't pollute main session)
How to dispatch
Use the Task tool to dispatch the web-researcher subagent. This is a dedicated OpenCode subagent configured with structured research methodology, domain-specific modules, and mandatory citation requirements.
How to dispatch:
Task tool with:
- subagent_type: "web-researcher"
- prompt: "[Research brief with task, angles, and module recommendations]"
What the web-researcher subagent does:
- Loads the search subagent guide (
references/search-subagent.md)
- Loads relevant domain modules from
references/modules/ based on task type
- Generates 3-5 search queries
- Executes searches with module-guided source prioritization
- Returns structured findings with mandatory citations
Template:
Research Task for Web Researcher:
**Topic:** [specific topic]
**Angles:** [search angles or focus areas]
**Modules:** [which domain modules to load]
- Debugging/GitHub Issues → github-debug.md
- Best Practices/Comparisons → general-web.md
- Academic Papers → academic-papers.md
- Technical Q&A → stackoverflow.md
- Code/API Research → patterns.md
- People Search → patterns.md
- Company Research → patterns.md
**Stakes:** [Low/Medium/High]
**Deliverable:** [expected output format]
CITATION REQUIREMENTS:
- Every factual claim must include a source URL
- Return findings in format: "[Claim] — [Source: URL]"
- Include Sources and References section with quality notes
- End with: `sources_reviewed: N`
Pass the sources_reviewed instruction line to every subagent verbatim — don't paraphrase.
Domain Module Routing
When dispatching the web-researcher subagent, tell it which domain module(s) to load based on task type:
| Task Type | Primary Module | Secondary Module(s) |
|---|
| Debugging errors | modules/github-debug.md | modules/stackoverflow.md |
| Best practices / comparisons | modules/general-web.md | patterns.md |
| Academic research | modules/academic-papers.md | — |
| Technical Q&A | modules/stackoverflow.md | modules/github-debug.md |
| Code/API docs | patterns.md | modules/stackoverflow.md |
| People search | patterns.md | — |
| Company research | patterns.md | modules/general-web.md |
Multi-module routing: Complex tasks may need multiple modules:
- "transformers OOM" →
github-debug.md + stackoverflow.md
- "attention mechanism papers + implementations" →
academic-papers.md + patterns.md
The web-researcher subagent loads the module(s) and follows domain-specific search strategies automatically.
Additional Reference Files
Point to these for specific needs:
| File | Use when... |
|---|
references/extraction.md | Extracting specific data points into a schema |
references/filtering.md | Evaluating results against criteria |
references/synthesis.md | Producing prose synthesis |
references/source-quality.md | Assessing source credibility |
How to split work across subagents
If running parallel subagents, decompose the primary task/question into sub-questions to cover different search territories.
For example, "best open-source LLM fine-tuning frameworks for production use" can be decomposed into multiple parallel sub-questions:
- "What open-source LLM fine-tuning frameworks do production engineers recommend, and what do they say about using them in real deployments?"
- "What open-source LLM fine-tuning tools have launched or gained traction in the last 6 months that aren't yet widely known?"
- "What are the most common complaints, failure modes, and reasons teams migrated away from specific open-source LLM fine-tuning frameworks in production?"
Depending on your "How complex is this?" analysis: Some need 2-3; some need many. Some need several different angles, creative thought patterns, adversarial perspectives. It depends on what the user is asking for and how deep they want you to go.
Give the sub-question directly to the subagent in its prompt.
Subagent sizing
- The web-researcher subagent generates 3-5 query variations automatically
- Parallelize aggressively — independent workstreams should be separate subagent invocations launched in a single message
- Do not use
run_in_background — dispatch all subagents in one message and wait for their results
- For per-seed work (enriching a list of 20 companies), batch 3-5 seeds per subagent invocation
Web-researcher subagent advantage: Because the subagent loads domain modules and generates its own query variations, you can give it broader tasks:
- Instead of: "Search for X, Y, Z queries"
- Use: "Research [topic] focusing on [angles]. Load the [module] module and follow its strategies."
Token isolation
Never run bulk searches in your main context. The whole point of subagents is to keep raw search output out of your context window. The web-researcher subagent processes results and returns only distilled output with citations.
When things go wrong
- Subagent returns empty: Rephrase queries with different angles, not synonyms. If still empty, the topic may have limited web coverage -- report that.
- Subagent returns off-topic results: Queries were too vague. Retry with longer, more specific queries.
Step 3: Compile Results
Research Skill Delegation Output
If this query came from the research skill, structure your output to facilitate their synthesis:
- Lead with coverage summary: "Reviewed X sources across Y angles. Key findings:"
- Organize by theme (not by subagent) — group findings by the search angles provided
- Flag high-confidence findings — where multiple independent sources converge
- Note coverage gaps — explicitly mention what wasn't found or what angles need follow-up
- Include source quality notes — practitioner vs commentator, recency, relevance
- End with synthesis-ready summary — bullet points the research skill can drop into their template
- MANDATORY: Include Sources section — Every factual claim must have a citation. See Citation Requirements below.
Standard Output
For non-delegation queries, follow the standard format below.
After subagents return:
Deduplicate:
- Collect all results into a single list
- Remove exact URL duplicates
- Same entity from different sources: merge fields, keep the most complete/recent data
- Track: "Deduplicated X results down to Y unique entries"
Validate coverage:
- Are there obvious gaps? (missing time periods, missing geographic regions, missing entity types)
- For each gap found, run targeted follow-up searches (via subagent if multiple queries are needed, direct if extremely simple)
- For "find everything" queries, check if results from different subagents overlap heavily (good sign) or are completely disjoint (may indicate missed angles)
Format the output:
If you used subagents, open with: "I used Exa to review {X} sources across {Y} subagents. Here's what was found:" (X = sum of sources_reviewed across all subagents and passes plus any direct searches you ran; Y = total subagents dispatched. Pluralize naturally.)
Then: Format output beautifully, filling up no more than one scroll length of the claude code screen. Include hyperlinked text where relevant. Below it, you may also include things (in a short, easy-to-read format) that:
- ("Result") directly answer the original user request (in few words; make every word count)
- ("Process") include anything worth noting about your process and what you consider to be high-signal in this domain vs. what you filtered out.
- ("Patterns") any patterns identified that are non-obvious, require n-th order thinking, and are not included or alluded to in the rest of the output but might be interesting to the user.
- ("Notes") based on everything you know about the user and their work beyond this task, mention anything notable/useful you found that is not included or alluded to in the rest of the output.
If it's impossible to fit the full output in a single screen, write a file in the most relevant/useful file format (.csv, .md) to ./exa-results/<topic>-<YYYY-MM-DD> and include a pointer to the full file below the 1-screen output.
General output rules:
- No emojis unless the user requested them
- Include in-line 1-word or multi-word hyperlinks throughout outputs where hyperlinking is a value-add.
- Prefer tables over lists (fall back to lists only when fields are non-uniform or values are too long to fit cleanly)
- MANDATORY: Include Sources section — See Citation Requirements below
Multi-Pass Queries
Some queries require multiple sequential passes where later passes depend on earlier results. Common patterns:
Entity chaining (multi-hop): Pass 1 finds entities (companies), Pass 2 finds related entities per result (people at those companies), Pass 3 enriches those (their public statements). Each pass is a round of parallel subagents.
Exploratory then targeted: Pass 1 scouts the landscape broadly, Pass 2 searches deeply in the most promising directions found in Pass 1.
Criteria discovery: When "best" isn't predefined, Pass 1 surveys what practitioners actually value, Pass 2 searches for candidates matching those criteria.
Between passes, compile and deduplicate before dispatching the next round.
Evaluating Source Quality
Source quality matters most for "best of", ranking, expert-finding, and best-practices queries, but is useful context for almost any research task.
At the subagent level: Point subagents to references/source-quality.md so they tag source quality in their output. This lets you weight results during compilation.
At the orchestrator level, when compiling subagent results:
- Convergence across high-signal sources: Convergence alone isn't meaningful (3 low-quality sources agreeing is just shared noise). What matters is when multiple independent, high-signal sources (practitioners, people with skin in the game) converge on the same finding.
- Practitioner vs commentator: Weight practitioners (people doing the work) higher than commentators (people writing about the work).
- Via negativa: Before synthesizing, define who to exclude (sources with misaligned incentives, no skin in the game, or unfalsifiable claims). Filtering out noise is more valuable than seeking brilliance.
- Red-team your compiled results: What perspectives are missing? What biases might be distorting the aggregate? If a gap emerges, run a targeted follow-up.
- Ideas over entities: For expert-finding and best-practices queries, the primary output is convergent truths, not a ranked list of names. Lead with what the best sources agree on, then cite who said it.
Citation Requirements
Every Output Must Include Sources
This is mandatory. Every research output must include a Sources and References section. No exceptions.
What Requires Citation
Cite sources for:
- Factual claims — Statistics, dates, prices, version numbers
- Quotes — Direct or paraphrased statements from sources
- Comparative claims — "X is faster than Y", "A has more features than B"
- Specific data — Benchmark numbers, user counts, market share percentages
- Attributions — "According to [source]", "[Author] claims"
Citation Format
Use inline hyperlinks for readability:
GitHub Copilot costs $10/month for individuals [GitHub Pricing](https://github.com/features/copilot#pricing)
For structured output, use superscript numbers:
| Tool | Pricing |
|------|---------|
| Copilot | $10/mo¹ |
| Cursor | $20/mo² |
¹ [GitHub, "Copilot Pricing"](https://github.com/features/copilot#pricing)
² [Cursor, "Pricing Plans"](https://cursor.com/pricing)
Sources Section Template
## Sources and References
### Primary Sources
1. [Author/Org, "Title"](URL) — [What this contributed]
2. [Company, "Page Name"](URL) — [What info came from here]
### Secondary Sources
3. [Blog, "Analysis"](URL) — [Context on reliability]
4. [Reddit, r/subreddit, "Discussion"](URL) — [Community sentiment]
### Source Quality
- **High confidence**: [Authoritative, corroborated sources]
- **Medium confidence**: [Single-source or less authoritative]
- **Low confidence**: [Speculative or unverified]
Subagent Instructions
When dispatching subagents, add this to their prompt:
CITATION REQUIREMENTS:
- Every factual claim must include a source URL
- Return findings in format: "[Claim] — [Source: URL]"
- Track all sources reviewed and return them in a list
- Note source quality (official docs, blog post, forum discussion, etc.)
Validation
Before returning output, verify:
Gotchas
- Over-execution on simple queries: If the user asks "what year was X founded", don't spin up subagents. One search, one answer.
- Under-execution on hard queries: If the query has 4+ constraints, temporal joins, or semantic filtering, a single search will not cut it. Fan out.
- Synonym queries: Running "overrated AI tools" and "overhyped AI tools" as separate subagent queries wastes tokens. These hit the same embedding region. Diversify by angle instead.
- Forgetting to deduplicate: Multiple subagents will return overlapping results. Always deduplicate before synthesis.
- Treating Exa results as validated: Exa returns similarity, not yet validated. A result appearing in search output does not mean it meets the user's criteria. You must validate.
- Date drift: Always calculate dates from the current environment date. Never reuse dates from these instructions or from previous queries.