Search

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.

1. OAuth (recommended) — client opens auth.exa.ai, user signs in with Google / SSO / email, JWT is attached automatically. No key to copy. 2. 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). 3. 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 two things:

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: 1. Your interpretation of the query 2. The two (or more) plausible complexity levels 3. 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") 4. 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.

What work needs to happen? Identify which of these apply (most queries use 3-5):

1. 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. 2. Define what qualifies: What makes a result a valid "row"? Translate the user's criteria into concrete checks. 3. Define what to capture: What fields ("columns") does each result need? Build the schema before searching. 4. Search broadly: Generate diverse queries and run them to find candidates. This is where subagents do the heavy lifting. 5. Extract structured data: Pull specific fields from raw search results into the schema. 6. Filter: Apply hard constraints (dates, geography, thresholds) and soft judgments (quality, relevance, semantic checks). 7. Merge and deduplicate: Combine results from multiple subagents. Same URL = drop duplicate. Same entity from different sources = merge fields, keep best data. 8. Score and rank: For "best of" (e.g. "what's the best ___?") queries, define the scoring criteria explicitly, then rank. 9. Synthesize narrative: For research queries, organize findings by theme and write prose with citations.

Step 2: Dispatch Subagents

What subagents do

Subagents run Exa searches and process the results. They keep raw search output out of your context window. Each subagent should:

• Read the reference file(s) you point it to
• Run the specific searches you assign
• Return compact, structured output

How to dispatch

Use the Agent tool to dispatch subagents. Reference file paths are relative to the directory this file was loaded from.

Use model: "haiku" for subagents.

Tell each subagent: 1. Which reference file(s) to read for instructions (always include the absolute path) 2. What specific searches to run or what specific work to do 3. What output format to return

Template:

Read the file at [this skill's directory]/references/searching.md for instructions on how to query Exa effectively.

Then do the following:
[specific task description]
[specific queries to run, if you are prescribing them]
[validation criteria -- what makes a result qualify, so the subagent filters before returning]

Return: [output format -- e.g. "compact JSON with name, url, snippet per result" or "markdown table with columns X, Y, Z"].

End with EXACTLY: `sources_reviewed: N` where N = sum of `numResults` across every `web_search_exa` call (incl. retries). E.g. calls with numResults 10, 10, 5 → `sources_reviewed: 25`.

Pass the `sources_reviewed` instruction line to every subagent verbatim — don't paraphrase.

Which reference files to point subagents to

Always point subagents to references/searching.md. It contains Exa query guidance and an index of domain-specific pattern files that the subagent will select from based on its task.

Point to whichever of these also apply:

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: 1. "What open-source LLM fine-tuning frameworks do production engineers recommend, and what do they say about using them in real deployments?" 2. "What open-source LLM fine-tuning tools have launched or gained traction in the last 6 months that aren't yet widely known?" 3. "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

• Aim for 3-5 searches per subagent
• Parallelize aggressively — independent workstreams should be separate subagents 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

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. Subagents process results and return only distilled output.

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

After subagents return:

Deduplicate: 1. Collect all results into a single list 2. Remove exact URL duplicates 3. Same entity from different sources: merge fields, keep the most complete/recent data 4. 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)

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:

1. 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. 2. Practitioner vs commentator: Weight practitioners (people doing the work) higher than commentators (people writing about the work). 3. 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. 4. 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. 5. 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.

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.

Extracting Structured Data from Search Results

After running searches, you need to extract structured information from the results. This file covers how to do that well.

When You Have Enough from Snippets

Exa search results include titles, URLs, and text snippets ("highlights"). For many fields (company name, person name, funding round, publication date), the snippet is sufficient. Extract directly from what you have before fetching full pages.

When to Deep-Read with web_fetch_exa

Fetch the full page when:

• The snippet mentions what you need but doesn't include the actual value
• You need to read body text to make a judgment call (e.g. "does this blog post show genuine design opinion or is it generic?")
• You need to extract multiple fields from a single rich source (case study page, team page, filing)
• The task requires reading beyond the first few sentences

web_fetch_exa {
  "urls": ["https://source-1.com", "https://source-2.com"],
}

Batch up to 5-10 URLs per fetch call to minimize round trips. Avoid using maxCharacters param or head/tail bash tools; the point is to understand full page context.

Extracting into a Schema

When you've been given a schema (the "columns" for the result), extract each field per result:

1. Structured fields (name, date, URL, funding amount, ticker): Extract the literal value. If not present, mark as missing rather than guessing.

2. Categorical fields (industry, stage, role level): Map to the closest category. Note uncertainty if the mapping is ambiguous.

3. Semantic fields (sentiment, whether something qualifies as "genuine opinion", relevance to a theme): Read the content and make a judgment call. Include a brief rationale so downstream synthesis can weigh your assessment.

4. Negation fields ("no review mentions X", "no Series A announcement"): These require checking that something is absent. Search for the positive case; if nothing surfaces, report absence with confidence level based on how thorough your coverage was.

Handling Missing Data

• Mark fields as "not found" rather than guessing or leaving blank
• Distinguish "confirmed absent" (searched thoroughly, not there) from "not found" (didn't have access or coverage was limited)
• If a source is paywalled or inaccessible, note that explicitly

Confidence Signals

When extracting, note the strength of the evidence:

• Direct: The source explicitly states the value (e.g. "We raised $20M in Series B")
• Inferred: The value is derived from context (e.g. headcount estimated from team page photos)
• Uncertain: Single indirect signal, could be wrong

Output Format

Return extracted data as compact structured output. For lists of entities:

[
  { "name": "...", "field_1": "...", "field_2": "...", "source": "url", "confidence": "direct" },
  ...
]

Or as a markdown table if that better suits your task's instructions.

Keep output compact. Your results will be merged with results from other searches, so verbosity at this stage compounds.

Filtering Results

After extracting data from search results, you may need to filter rows based on criteria from the original query. This file covers how to apply filters effectively.

Hard Filters

Hard filters have clear, binary criteria: a date range, a geographic constraint, a numeric threshold, a category membership.

Apply these mechanically:

• Check each row against the criterion
• Remove rows that fail
• No judgment call needed

Examples: "published in 2025", "based in SF or NYC", "under $500B market cap", "excluding Novo Nordisk"

Negation filters ("excluding X", "not sponsored by Y") are hard filters applied in reverse. Check for the presence of the excluded value and remove matches.

Soft Filters

Soft filters require judgment: "genuine design opinion" vs "generic blog post", "actually shipping" vs "just evaluating", "high-signal" vs "noise".

For these: 1. Read the relevant content (use web_fetch_exa if snippets are insufficient) 2. Make a judgment call based on the content 3. Include a brief rationale for each keep/drop decision so your reasoning is visible

Semantic negation is a type of soft filter: "no review mentions smell, noise, or pest complaints" requires reading review content and detecting whether these topics appear, even if phrased differently.

Filter Order

Apply filters in this order to minimize wasted work: 1. Hard filters first -- cheap, mechanical, eliminates rows before you spend tokens on judgment 2. Soft filters second -- only on rows that passed hard filters

Temporal Filters

Queries often involve time: "in the last 6 months", "began enrolling in 2025", "recent".

• Calculate exact date boundaries from the current date before filtering
• Check publication/event dates against the boundary
• If a date is ambiguous (e.g. "early 2025"), note the uncertainty rather than silently including or excluding

Completeness vs Precision

The original query determines the balance:

• "Find every..." or "exhaustive" -- err on the side of including borderline cases, flag them as uncertain
• "Find the best..." or "top N" -- err on the side of precision, drop borderline cases
• Default: include borderline cases with a flag, let downstream processing decide

Query Patterns: Code and Documentation

Always include programming language and framework/library in your query.

// API usage
web_search_exa { "query": "Stripe API create subscription Node.js code example", "numResults": 5 }

// Error resolution
web_search_exa { "query": "React hydration mismatch server client explanation fix", "numResults": 10 }

// GitHub implementations
web_search_exa { "query": "GitHub repository [library] example project open source", "numResults": 10 }

Use web_fetch_exa to read official docs when you know the URL.

Query Patterns: Companies

Use category:company for structured company data (funding, headcount, description).

// By category
web_search_exa { "query": "category:company AI infrastructure startups San Francisco", "numResults": 10 }

// By stage
web_search_exa { "query": "category:company Series B fintech payments", "numResults": 10 }

// Similar to known company
web_search_exa { "query": "category:company companies like Stripe", "numResults": 8 }

For competitive intelligence, layer multiple angles:

web_search_exa { "query": "category:company companies like [target]", "numResults": 10 }
web_search_exa { "query": "category:company [category] software tools", "numResults": 15 }
web_search_exa { "query": "[category] startup launch funding announcement recently", "numResults": 15 }

For funding/investors:

web_search_exa { "query": "[company] funding round raised investors", "numResults": 5 }
web_search_exa { "query": "category:company [company]", "numResults": 5 }

Query Patterns: News and Recent Events

web_search_exa { "query": "category:news [topic] announcement", "numResults": 15 }
web_search_exa { "query": "[topic] news update latest development [month year]", "numResults": 15 }

For reactions/sentiment on recent events, search across platforms:

web_search_exa { "query": "[event] reaction analysis commentary", "numResults": 12 }
web_search_exa { "query": "[event] criticism concerns issues bugs", "numResults": 15 }

Query Patterns: Research Papers

Use category:research paper for Exa's paper index.

// By topic
web_search_exa { "query": "category:research paper sparse attention mechanisms for long context transformers", "numResults": 12 }

// Survey/review papers
web_search_exa { "query": "category:research paper [topic] comprehensive survey review", "numResults": 10 }

// By author
web_search_exa { "query": "category:research paper [author name] [topic]", "numResults": 5 }

// By recency (encode time in query)
web_search_exa { "query": "category:research paper large language model advances 2025 2026", "numResults": 15 }

To find seminal papers: search for survey papers first, then deep-read them to extract foundational references.

Query Patterns: People

Use category:people for LinkedIn-weighted results. For discovery queries, be specific -- vague queries like "category:people researcher founder CEO startup" will match many irrelevant LinkedIn profiles. Include specific companies, timeframes, or roles to narrow results.

// By company + role
web_search_exa { "query": "category:people engineer at OpenAI", "numResults": 10 }
web_search_exa { "query": "category:people VP director at Cursor", "numResults": 10 }

// By role + location
web_search_exa { "query": "category:people Head of Growth B2B SaaS startup San Francisco", "numResults": 12 }

// Specific person
web_search_exa { "query": "category:people Jane Smith Anthropic machine learning", "numResults": 5 }

For comprehensive company coverage, search by department and seniority in parallel:

web_search_exa { "query": "category:people engineering at Acme", "numResults": 10 }
web_search_exa { "query": "category:people product design at Acme", "numResults": 10 }
web_search_exa { "query": "category:people sales marketing at Acme", "numResults": 10 }

Supplement with non-LinkedIn sources:

web_search_exa { "query": "Acme team page employees about us", "numResults": 5 }
web_search_exa { "query": "joined Acme recently hired new role announcement", "numResults": 5 }

Deduplicate by LinkedIn URL (canonical) or name + current company (fallback).

Query Patterns: Hidden Relationships

Finding connections that aren't explicitly listed anywhere. Direct queries ("X clients") return articles about them, not actual connections. Use indirect signals instead.

Start with the subject's own platforms:

web_search_exa { "query": "[subject] official website blog podcast", "numResults": 5 }
web_search_exa { "query": "[subject] conversation interview testimonial guest", "numResults": 8 }
web_fetch_exa { "urls": ["https://subject-website.com/blog", "https://subject-website.com/about"] }

For B2B (company -> customers):

web_search_exa { "query": "[company] case study customer success story", "numResults": 5 }
web_fetch_exa { "urls": ["https://company.com/customers", "https://company.com/case-studies"] }

Indirect signal searches:

// Testimonials
web_search_exa { "query": "personal blog [subject] changed my life testimonial", "numResults": 15 }

// Duration markers (high confidence -- people don't fabricate decades)
web_search_exa { "query": "[subject] years decades longtime worked with known since", "numResults": 10 }

// Terminology detection: find insider terms, then search for people using them
web_search_exa { "query": "[subject] method terminology concepts framework", "numResults": 5 }
web_search_exa { "query": "[unique term 1] [unique term 2] personal story", "numResults": 10 }

Searching with Exa

You have two tools:

• `web_search_exa` -- search by query. Supports query and numResults params. Use category:<type> inline in the query string for category filtering.
• `web_fetch_exa` -- read full content from known URLs. Use after search when snippets are insufficient.

Do NOT use web_search_advanced_exa or any other Exa tools. Only use these two tools -- do not use Bash, Grep, Read, or Write to process results. Filter and summarize results inline.

How Exa Search Works

Exa uses vector embeddings, not keywords. It finds pages semantically similar to your query. It does not match keywords exactly, directly understand boolean logic (AND/OR/NOT), or validate that results meet your criteria. You are describing a target page, and Exa returns the nearest neighbors in embedding space.

Writing Good Queries

Describe the page you want to find, not the fact you want to know.

Write queries as natural grammatical phrases.

`numResults` sizing -- match to query precision:

Never use numResults above 25. If you need more coverage, run more queries with different angles at n=10-15 rather than one query at n=50.

Use category filters when searching for a specific entity type. Available inline categories: company, research paper, news, personal site, people. Add category:<type> at the start of your query string.

web_search_exa { "query": "category:research paper sparse attention mechanisms for long context", "numResults": 10 }
web_search_exa { "query": "category:people VP Engineering AI infrastructure San Francisco", "numResults": 10 }
web_search_exa { "query": "category:company developer tools for API testing", "numResults": 10 }

Query Diversity

When you need to run multiple queries on the same topic, make sure they target genuinely different angles, not just synonym swaps. "overhyped" vs "overrated" vs "disappointment" are the same angle. A skeptic angle vs a builder angle vs a practitioner angle are genuinely different.

Word order affects embeddings. "Python async patterns for web scraping" and "web scraping async patterns in Python" can sometimes return different results. Use this to your advantage when you need coverage -- run 2-3 phrasings in parallel.

Encoding Time

If your task involves time ("last week", "recent", "this month"), calculate exact dates FIRST from the current date in your environment context. Then encode dates semantically in the query: "published in March 2026" rather than using date filters. Never eyeball dates.

Anti-Patterns

• Boolean operators ("AND", "NOT") are just words to Exa, not operators
• Quotes don't force exact phrase matching
• Very short queries (1-2 words) produce scattered, low-quality results
• Don't use dates from examples -- always calculate from the current date

When Searches Return Nothing

If a query returns 0 or only irrelevant results: a. Make the query longer and more specific b. Try a different angle, not a synonym swap c. If multiple angles return nothing, the topic likely has limited web coverage -- report that rather than fabricating results

Domain-Specific Patterns

If your task involves any of these domains, read the relevant pattern file(s) for specialized query strategies. Pick whichever files match your task — most tasks use 1-2.

When web_fetch_exa Fails

Fall back to fetching with any other fetch tool you have access to. If that also fails, skip it and work with remaining sources.

After Getting Results

Exa returns similarity, not validation. You must review titles/snippets and discard irrelevant results using your judgment. Don't assume all results match your criteria. For the most promising results, use web_fetch_exa to read the full content.

web_fetch_exa {
  "urls": ["https://promising-url-1.com", "https://promising-url-2.com"],
}

Evaluating Source Quality

When assessing sources during search and extraction, tag quality signals in your output so results can be weighted and ranked downstream.

Noise Signals -- Filter Out First

Before deep-reading, check for these disqualifiers:

Practitioner vs Commentator

The most important distinction. Practitioners do the work; commentators write about the work.

Practitioner signals: shipped products, open-source contributions, case studies with specific numbers, "we built X and here's what happened"

Commentator signals: roundup posts, "top 10" lists, content primarily linking to others' work, no first-hand experience described

Note this distinction in your quality tags.

Verification Searches

When validating a source's credibility (for expert-finding and best-of queries):

// Who cites them?
web_search_exa { "query": "[name] recommended by experts practitioners", "numResults": 5 }

// Track record?
web_search_exa { "query": "[name] results portfolio case study shipped", "numResults": 5 }

// Criticism?
web_search_exa { "query": "[name] criticism overrated wrong", "numResults": 5 }

Only run verification searches when the task specifically calls for evaluating source credibility. For standard search tasks, just tag what you observe from the content you already have.

Tagging in Output

For each source, include a short free-form quality string describing what you observed -- e.g. "shipped the product, writes from direct experience" or "roundup blog, no original work shown, links to others." Don't classify into categories. Just describe what you see so the signal is preserved for downstream ranking.

Synthesizing Research into Narrative

When the task calls for a narrative answer (not a list or table), this file covers how to synthesize findings from multiple sources into a coherent, well-structured response.

When Synthesis Applies

Synthesis is the right output format when:

• The user is asking "what do people say about X" or "what's the current state of Y"
• The answer requires integrating perspectives from multiple sources
• The output should be prose with citations, not a table of entities

Structure

Lead with the answer

Put the core finding or conclusion first. The user should get value from the first paragraph alone.

Organize by theme, not by source

Bad: "Source A says X. Source B says Y. Source C says Z." Good: "Theme 1: [insight supported by A, B]. Theme 2: [insight supported by C, with counterpoint from A]."

Surface disagreement explicitly

When credible sources disagree, don't collapse to consensus. Present both sides with their evidence:

• "On [topic], [position A] (supported by [sources]) vs [position B] (supported by [sources]). [When each applies or why they diverge]."

Include confidence signals

• How many independent sources support a claim?
• How fresh is the evidence?
• Are the sources practitioners or commentators?

Thematic Clustering

When dealing with many reactions or perspectives (e.g. "what are people saying about X"):

1. Read through all results 2. Identify recurring themes (not just topics -- themes have a stance or direction) 3. Group results by theme 4. For each theme: state the theme, cite 2-3 representative sources, note the volume 5. Flag outlier themes that appear only once but carry important signal

Citation Practice

• Every factual claim gets a source URL
• Prefer inline citations: "Engineers report 3x latency reduction (source)"
• For quotes, include the exact text and attribute it

Common Mistakes

• Source-by-source summaries: Feels comprehensive but is unreadable and doesn't synthesize
• Collapsing disagreement: Picking a winner instead of presenting the landscape
• Missing recency: Treating 2023 sources as current for fast-moving topics
• Over-synthesis: Producing a full essay when the user asked a narrow question