Subagent-Driven Literature Review

Overview

Core principle: Fresh subagent per batch + consolidation between batches = fast parallel screening with quality control

For large literature reviews (50+ papers), dispatching parallel or sequential subagents dramatically speeds up screening while maintaining quality through consolidation checkpoints.

When to Use

Use subagent-driven approach when:

• Large searches: 50+ papers to screen
• Parallelizable work: Papers are independent, can be screened separately
• Deep dive tasks: Multiple papers need detailed extraction (data tables, methods, datasets)
• Citation exploration: Following citation networks recursively
• Context management: Main context getting full, need fresh context
• Time pressure: Need results faster than sequential screening

Do NOT use when:

• Small searches (<20 papers) - overhead not worth it
• Need real-time user visibility into every paper
• Papers require cross-comparison during screening
• Simple, fast screening tasks

Use Cases

1. Parallel Paper Screening (Most Common)

Scenario: You have 100 papers from PubMed search to screen for relevance

Pattern:

Main agent:
1. Splits 100 papers into 5 batches of 20
2. Dispatches 5 subagents IN PARALLEL (single message, multiple Task calls)
3. Each subagent:
   - Fetches abstracts for its batch
   - Scores using rubric
   - Returns JSON with results
4. Main agent consolidates results into papers-reviewed.json

Time savings: 5x faster than sequential!

Prompt template for subagent:

I need you to screen papers 1-20 from this PMID list for relevance to [QUERY].

PMIDs to screen: [PMID list]

Use the evaluating-paper-relevance skill to:
1. Fetch abstract for each PMID
2. Score 0-10 based on:
   - Keywords: [list]
   - Data types needed: [measurements, protocols, datasets, etc.]
3. Return JSON:

{
  "screened_papers": [
    {"pmid": "12345", "score": 8, "status": "relevant", "reason": "..."},
    ...
  ],
  "stats": {"highly_relevant": 3, "relevant": 5, "not_relevant": 12}
}

Do NOT update papers-reviewed.json - return results only.

**Rate limiting (CRITICAL - PubMed limits are SHARED across all parallel subagents):**
- If you are the ONLY subagent running: Use 500ms delays (2 req/sec, safe)
- If running with OTHER parallel subagents: Use longer delays to share capacity
  - You are 1 of 2 parallel: Use 1 second delays
  - You are 1 of 3 parallel: Use 1.5 second delays
  - You are 1 of 5 parallel: Use 2.5 second delays
- If you get HTTP 429 errors: Wait 5 seconds, then use 5-second delays for remaining requests