quick-research

name

quick-research

description

Mid-depth research orchestrator sitting between WebSearch and external deep-research tools (Gemini/ChatGPT). Spawns 2-4 parallel research-assistant sub-agents, synthesizes findings, writes a cited Markdown report to docs/research/. Use for research writeups, multi-source comparisons, options/candidate ranking, or any topic exploration deeper than a single WebSearch. The calling agent decides when to invoke based on user intent.

Quick Research

Overview

Quick research enables comprehensive topic exploration using a multi-agent architecture. A lead researcher (Claude Code) orchestrates multiple parallel research sub-agents to explore different aspects of a topic simultaneously, then synthesizes findings into a well-cited report.

This approach mirrors Anthropic's production research system which found that multi-agent systems outperform single-agent by 90%+ on breadth-first queries.

When to Use This Skill

• Complex research requiring multiple independent directions
• Comparative analyses (e.g., "Compare OpenAI vs Anthropic vs Google approaches to AI safety")
• List/ranking requests (e.g., "Find the top 20 AI companies in healthcare")
• Validation questions requiring deep domain exploration
• Any research exceeding what a single web search can accomplish

⚠️ Phase 0 — MANDATORY WEB RECON (Do This FIRST)

DO NOT SPAWN SUB-AGENTS WITHOUT BASELINE KNOWLEDGE. Assigning research topics without knowing the current landscape is the #1 failure mode of this skill — it produces research that's confidently wrong about deprecated tools, outdated model versions, and last-year's "state of the art."

The Rule

Before any deeper research:

1. Run date "+%d/%m/%Y - %A" to confirm today's exact date (day/month/year).
2. Run 2–3 baseline WebSearch queries to anchor yourself in the current reality of the topic. Search with the full date ("April 2026", not just "2026"). Focus on:
   • What is the current state of the art as of THIS month?
   • What has been released, deprecated, or renamed in the last 3–6 months?
   • Who are the current players and what are their latest versions?
3. Read the results carefully. Note specific product names, version numbers, release dates, prices. Pay attention to "deprecated", "sunset", "replaced by" language.
4. ONLY THEN proceed to Phase 1 (scope) and Phase 2 (sub-agents), armed with current public-web reality.

Why This Is Non-Negotiable (Especially for AI / LLM / Tech Topics)

AI and LLM landscapes change completely every few months. A model that was SOTA in January may be deprecated by April. Prices drop 10x in a quarter. New providers appear, old APIs shut down. If you spawn sub-agents with stale mental models ("research Gemini 2.5 Flash pricing"), they'll return stale-but-confident findings because they're just following your lead. The sub-agents can't correct for what you didn't know to ask.

A concrete failure pattern to avoid:

• ❌ User asks "compare vision LLMs for my RAG pipeline"
• ❌ You immediately spawn sub-agents for "Gemini 2.5 Flash", "Qwen2.5-VL", "GPT-4o-mini"
• ❌ All three sub-agents dutifully research those specific models
• ❌ You deliver a report confidently recommending models that are deprecated, superseded, or retired
• ❌ User (rightfully) asks: "why didn't you check what's CURRENT first?"

Correct pattern:

• ✅ Run date → confirm today is 2026-04-10
• ✅ Search "latest vision LLM April 2026" / "Gemini vision model current version 2026" / "Qwen3-VL release"
• ✅ Discover: Gemini 3.1 Pro/Flash-Lite exist, Gemini 2.5 Flash sunsets June 2026, Qwen3-VL released Sept 30 2025 (supersedes 2.5), GPT-4o-mini retired Feb 2026
• ✅ NOW spawn sub-agents to deep-dive the ACTUAL current models

Date Discipline

Every date you write must include day + month + year, not just year. "2026" is useless — "released 30 September 2025" or "deprecated as of 17 June 2026" is actionable. Sub-agent prompts should also demand day/month/year precision and flag anything older than 3 months as "potentially stale, verify."

How Many Baseline Searches?

• Fast-moving topics (AI, LLMs, crypto, frontier tech): 3 searches minimum
• Stable topics (legal, historical, well-established science): 1–2 searches
• Time-sensitive claims ("latest", "recent", "current", "best"): always 3+

Budget 1–2 minutes for Phase 0. It will save hours of rework.

---

Architecture

# PSEUDO-CODE - Conceptual workflow, not executable code

def deep_research(user_query):
    # Phase 0: MANDATORY WEB RECON — baseline web searches
    today = run("date +%d/%m/%Y")
    baseline_facts = []
    for query in generate_2_to_3_recon_queries(user_query, today):
        baseline_facts.append(WebSearch(query))
    # You now know what actually exists in the current landscape.
    # Do NOT skip this step. Do NOT proceed until you have this knowledge.

    # Phase 1: Scope (informed by Phase 0 baseline)
    brief = clarify_and_create_research_brief(user_query, baseline_facts)

    # Phase 2: Research Loop (max 3 iterations)
    all_findings = []
    for iteration in range(3):
        subtopics = identify_gaps_or_subtopics(brief, all_findings, baseline_facts)
        if not subtopics:
            break  # sufficient findings

        # Spawn parallel sub-agents (in single message)
        # Model selection is up to the lead researcher — pick based on task.
        # Default to Sonnet for quality synthesis; use Haiku only when the task
        # is pure fact-retrieval AND cost is an explicit constraint.
        findings = parallel([
            Task(subagent_type="research-assistant", model=pick_model(topic), prompt=topic)
            for topic in subtopics
        ])
        all_findings.extend(findings)

    # Phase 3: Synthesize
    synthesized = merge_and_deduplicate(all_findings)

    # Phase 4: Report
    report = generate_report_with_citations(brief, synthesized)

    # Phase 5: Save (default behavior)
    if not user_opted_out_of_saving:
        save_to_file(f"docs/research/{date}-{topic_slug}.md", report)

    return report

Quick Research Workflow

Phase 0: MANDATORY WEB RECON (see dedicated section above)

This phase is non-negotiable. Run date "+%d/%m/%Y - %A", then do 2–3 baseline WebSearch queries about the current state of the topic — especially any claim of "latest", "best", or "state of the art" in fast-moving fields (AI, LLMs, frontier tech). Only after you know the current external landscape may you proceed to Phase 1. Do not skip. Do not rationalize skipping. See the "Phase 0 — MANDATORY WEB RECON" section above for rules and failure examples.

Phase 1: Scope the Research

Informed by Phase 0 baseline, clarify the research scope:

1. Analyze the query in light of the baseline facts - Update your mental model: which products/versions/players are actually current? Which have been deprecated?
2. Ask clarifying questions if needed - Ask only if the intended direction remains meaningfully ambiguous. If the user explicitly says not to ask, do not ask; proceed with best-guess assumptions.
3. Create a research brief - A focused statement capturing:
   • The core research question
   • Specific dimensions to explore
   • Anchor the brief to current (post-Phase-0) reality — do not name specific deprecated versions
   • Any constraints or preferences from the user
   • Source quality preferences (academic, official, etc.)

Phase 2: Delegate Research to Sub-Agents

Use the Task tool with subagent_type: "research-assistant" to spawn parallel research agents. Model selection is the lead researcher's call — pass whichever model fits the task.

Model guidance (not a hard rule):

• sonnet (default) — use for synthesis, strategic framing, nuanced comparison, domain-specific reports (competitive intelligence, investment memos, audience-tailored briefs). This is the right choice for most research tasks where the quality of the write-up matters.
• haiku — use only when the task is pure fact-retrieval (collect links, extract specific numbers, list items) AND cost is an explicit user constraint. Haiku's synthesis is noticeably weaker; do not use it if the output is going into a document that a human will read as-is.
• opus — rarely needed for research; reserve for tasks that need reasoning beyond what Sonnet delivers.

If the user has stated a preference ("use sonnet", "minimize cost"), honor that. Otherwise, default to Sonnet.

SEARCH TOOL USAGE - TRY WEBSEARCH FIRST, FALLBACK TO EXA (OPTIONAL):

1. First try WebSearch tool for the query
2. If WebSearch fails (API error) AND you have an Exa API key set, fallback to Exa API via Bash:

# Fallback to Exa if WebSearch fails (requires EXA_API_KEY env var; skip if not set)
curl -s -X POST https://api.exa.ai/search \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $EXA_API_KEY" \
  -d '{"query": "your search query", "type": "auto", "numResults": 10}'

# Fetch content from results
curl -s -X POST https://api.exa.ai/contents \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $EXA_API_KEY" \
  -d '{"ids": ["url1", "url2"], "text": true}'

Always prefer WebSearch when available. Exa fallback is optional — if you don't have an Exa account, just use WebSearch alone.

Scaling Rules

Query Type	Sub-Agents	Tool Calls Each
Simple fact-finding	1	3-10
Direct comparisons	2-4 (one per element)	10-15
Complex/broad research	5-10	15-20

Delegation Best Practices

1. Provide complete, standalone instructions - Sub-agents cannot see other agents' work
2. Specify clear task boundaries - Avoid overlapping responsibilities
3. Define output format expectations - What structure should findings take?
4. Include source guidance - What types of sources to prioritize?
5. Avoid acronyms - Be explicit and specific in task descriptions

Example: Spawning Parallel Sub-Agents

For a query like "Compare OpenAI vs Anthropic vs Google approaches to AI safety":

Use Task tool THREE times in parallel (single message, multiple tool uses):

Task 1:
  subagent_type: "research-assistant"
  model: "sonnet"  # default; caller can override per task
  prompt: |
    Research OpenAI's approach to AI safety and alignment.

    Focus on:
    - Their philosophical framework for AI safety
    - Key research priorities and publications
    - Their stance on the alignment problem
    - Notable safety initiatives and teams

    CITATION RULES (CRITICAL):
    - Every factual claim MUST have an inline clickable link: ([Source Name, Year](URL))
    - Do NOT use footnote numbers like [1]. Use full inline markdown links.
    - If data is unavailable, explicitly state "Not publicly disclosed" or "No data found"
    - Prioritize official OpenAI sources, research papers, and executive statements.

Task 2:
  subagent_type: "research-assistant"
  model: "sonnet"
  prompt: |
    Research Anthropic's approach to AI safety and alignment.
    Focus on:
    - Their philosophical framework (Constitutional AI, etc.)
    - Key research priorities and publications
    - Their stance on the alignment problem
    - Notable safety initiatives and teams

    CITATION RULES (CRITICAL):
    - Every factual claim MUST have an inline clickable link: ([Source Name, Year](URL))
    - Do NOT use footnote numbers like [1]. Use full inline markdown links.
    - If data is unavailable, explicitly state "Not publicly disclosed" or "No data found"
    - Prioritize official Anthropic sources and research papers.

Task 3:
  subagent_type: "research-assistant"
  model: "sonnet"
  prompt: |
    Research Google DeepMind's approach to AI safety and alignment.
    Focus on:
    - Their philosophical framework for AI safety
    - Key research priorities and publications
    - Their stance on the alignment problem
    - Notable safety initiatives and teams

    CITATION RULES (CRITICAL):
    - Every factual claim MUST have an inline clickable link: ([Source Name, Year](URL))
    - Do NOT use footnote numbers like [1]. Use full inline markdown links.
    - If data is unavailable, explicitly state "Not publicly disclosed" or "No data found"
    - Prioritize official DeepMind sources and research papers.

CRITICAL: Launch all sub-agents in a SINGLE message with multiple Task tool calls to enable true parallelization.

Phase 3: Synthesize Findings

After all sub-agents return:

1. Collect all findings - Gather results from each sub-agent
2. Identify patterns and gaps - What themes emerge? What's missing?
3. Spawn additional sub-agents if needed - Fill gaps with targeted follow-up research
4. Deduplicate and organize - Remove redundant information, structure by theme

Phase 4: Generate Final Report

Create a comprehensive report that:

1. Answers the research brief directly
2. Organizes by logical structure (see Report Structures below)
3. Includes all relevant findings with inline citations
4. Ends with Sources section listing all referenced URLs

Phase 5: Save Research Report

By default, save all research reports to docs/research/ as Markdown files.

1. Create docs/research/ directory if it doesn't exist
2. Generate filename from topic: YYYY-MM-DD-topic-slug.md (e.g., 2026-01-03-ai-safety-comparison.md)
3. Save the complete report with all citations and sources
4. Inform the user where the report was saved

Skip saving only if: The user explicitly says they don't want a Markdown file saved.

This ensures research is preserved for future reference and can be shared with team members.

Report Structures

For comparisons:

# [Topic] Comparison

## Overview
[Brief context]

## [Element A]
[Detailed findings]

## [Element B]
[Detailed findings]

## Comparative Analysis
[Cross-cutting comparison]

## Conclusion
[Key takeaways]

## Sources
[Numbered list of all sources]

For lists/rankings:

# Top [N] [Category]

## 1. [Item]
[Details with citations]

## 2. [Item]
[Details with citations]

...

## Sources
[Numbered list]

For topic exploration:

# [Topic] Research Report

## Overview
[Context and scope]

## [Aspect 1]
[Detailed findings]

## [Aspect 2]
[Detailed findings]

## Key Insights
[Synthesized conclusions]

## Sources
[Numbered list]

Citation Rules — INLINE IS MANDATORY

Every claim must have a clickable source link nearby. Dumping a numbered source list at the bottom with no inline references is useless — readers won't cross-reference.

Format by context

In prose paragraphs — use inline markdown links right after the claim:

FE Credit commands ~50% of Vietnam's consumer finance market (Vietnam News, 2025)

In tables — keep data clean and readable. Put source links in a note block immediately below the table:

GOOD — table stays readable, sources right below:

| Company | Customers | Market Share | 2024 Profit |
|---------|-----------|-------------|-------------|
| FE Credit | 14M+ | ~50% | VND 515B |
| Home Credit | 16M | ~10% | VND 1,291B |

> Sources: FE Credit data from [Vietnam News, 2025](https://vietnamnews.vn/.../1722800/...) and [FiinGroup, 2024](https://fiingroup.vn/.../11130948). Home Credit data from [Vietnam.vn, 2025](https://www.vietnam.vn/en/...) and [The Investor, 2025](https://theinvestor.vn/...).

BAD — URLs crammed into cells, unreadable:

| Company | Market Share |
|---------|-------------|
| FE Credit | ~50% ([Vietnam News, 2025](https://vietnamnews.vn/brandinfo/1722800/over-a-decade...)) |

Rules

1. Prose: inline link right after the claim. Tables: source note immediately below the table.
2. Distinguish data sources clearly: If data comes from your own database/internal queries, say "from internal data". If estimated/back-calculated, say "ESTIMATED from [source]"
3. When data is unavailable, say so explicitly — don't leave blanks or omit the row. Write "Not publicly disclosed" or "No data found"
4. Flag uncertain claims — if a number seems off (e.g., "68% market share"), note the source and add a caveat
5. Sub-agents must return findings with inline [Source Title](URL) format — instruct this explicitly in every sub-agent prompt
6. A ## Sources section at the end is optional as a convenience index, but is NOT a substitute for inline/below-table citations

Hard Limits

To prevent excessive resource usage:

• Maximum 10 parallel sub-agents per research iteration
• Maximum 3 research iterations (initial + 2 follow-ups)
• Stop when findings are sufficient - Don't pursue perfection
• Token awareness - Multi-agent systems use ~15x more tokens than chat

Key Insights from Anthropic's Research System

1. Token usage explains 80% of performance variance - Distribute work across agents with separate context windows
2. Start wide, then narrow - Broad queries first, progressively focus
3. Context isolation prevents failures - Each sub-agent handles one subtopic cleanly
4. Sub-agent output compression - Have sub-agents summarize their findings to avoid "game of telephone" information loss
5. Parallel execution cuts time 90% - Always spawn sub-agents in parallel when independent

References

For detailed prompt templates and architecture details, see:

• references/prompts.md - Research agent prompt templates
• references/architecture.md - Multi-agent system architecture details