Research Orchestrator Guru

An agent that orchestrates the complete research lifecycle from query intake through report delivery, coordinating specialized agents and managing the flow of information between research phases for high-quality outcomes.

When to Use This Agent

Choose Research Orchestrator when:

• Running end-to-end research projects with multiple phases
• Coordinating between clarification, research, synthesis, and reporting agents
• Managing complex research workflows that span multiple sessions
• Ensuring quality control across the full research pipeline
• Producing research outputs that meet academic or professional standards

Consider alternatives when:

• Doing a single focused research task (use a research analyst directly)
• Coordinating researchers without orchestrating the full pipeline (use a coordinator)
• Generating reports from pre-existing research (use a report generator)

Quick Start

Copy
# .claude/agents/research-orchestrator-guru.yml
name: Research Orchestrator
model: claude-sonnet-4-20250514
tools:
  - Read
  - Write
  - Bash
  - Glob
  - Grep
prompt: |
  You are a research pipeline orchestrator. Manage the complete
  research lifecycle: query clarification, brief generation,
  task coordination, research execution, fact-checking, synthesis,
  and report generation. Ensure quality at each stage and maintain
  coherence across the full pipeline.

Example invocation:

Copy
claude --agent research-orchestrator-guru "Orchestrate a complete
  research project on the ROI of developer experience investments.
  Take it from initial scoping through final report delivery."

Core Concepts

Research Pipeline Stages

Intake → Clarify → Brief → Coordinate → Research → Check → Synthesize → Report
  │         │        │         │            │         │         │           │
 Query   Refine   Plan    Assign &      Execute   Verify   Combine     Format
 scope   scope    tasks   sequence      searches  claims   findings    deliver

Stage Gates

Gate	Between	Criteria
G1	Clarify → Brief	Query is specific, scoped, actionable
G2	Brief → Research	Plan covers all questions with methods
G3	Research → Check	All assignments completed with sources
G4	Check → Synthesize	Critical claims verified, conflicts flagged
G5	Synthesize → Report	Coherent narrative, no contradictions
G6	Report → Deliver	Formatted, cited, meets quality standards

Quality Metrics

Research Quality Score:
  Source diversity:  Number of independent source types (target: 3+)
  Claim coverage:   Percentage of claims with citations (target: 95%)
  Conflict resolution: Percentage of conflicts analyzed (target: 100%)
  Recency:          Average source age (target: < 2 years)
  Confidence:       Average confidence rating (target: > 70%)

Configuration

Parameter	Description	Default
pipeline_depth	Full or abbreviated pipeline	Full
quality_threshold	Minimum quality score to pass gates	70%
max_iterations	Maximum pipeline cycles	3
parallel_research	Enable parallel research streams	true
fact_check_level	Fact-checking rigor	Medium
output_formats	Report output types	Executive + detailed
checkpoint_saves	Save state between stages	true

Best Practices

1. Enforce stage gates rather than treating the pipeline as a waterfall. Each stage gate checks that the previous stage produced sufficient quality output before proceeding. Don't start research with an ambiguous query. Don't synthesize unverified findings. Don't format a report with contradictions. Stage gates catch problems when they're cheap to fix rather than after the full pipeline runs.

2. Save intermediate artifacts at every stage. Store the refined query, research brief, raw findings, fact-check results, and synthesis separately. These artifacts enable debugging (where did this incorrect finding enter the pipeline?), reruns (regenerate the report without redoing research), and quality audits (verify the fact-checker reviewed all claims).

3. Time-box each stage proportionally. For a 5-day research project: spend day 1 on clarification and brief generation, days 2-3 on research and fact-checking, day 4 on synthesis, and day 5 on report generation and review. Spending too long on early stages starves downstream stages. Spending too little produces low-quality inputs that corrupt downstream outputs.

4. Run the orchestrator iteratively, not once. The first pipeline pass produces a good draft. The second pass fills gaps identified during synthesis. The third pass refines based on stakeholder feedback. Plan for 2-3 iterations from the start. Each iteration should be faster than the previous because the scope of new research narrows with each pass.

5. Monitor coherence across the pipeline, not just stage quality. A pipeline can produce high-quality intermediate artifacts that don't fit together. The orchestrator must verify that the research addresses the brief's questions, the synthesis reflects the research findings, and the report serves the original query's decision context. End-to-end coherence checking prevents pipelines that produce polished irrelevance.

Common Issues

Pipeline produces comprehensive but untimely research. The full pipeline takes too long for time-sensitive decisions. Build a fast-path option: abbreviated pipeline that skips brief generation and fact-checking for lower-stakes questions. The orchestrator should assess urgency and adjust pipeline depth accordingly. A 70% quality report delivered on time beats a 95% quality report delivered after the decision was made.

Quality gates create bottlenecks when standards are too strict. Gates should catch genuine quality problems, not enforce perfection. Set thresholds that filter out unreliable research (missing sources, unverified claims) without blocking research that's good enough to inform decisions. Review gate criteria periodically and adjust based on whether they catch real problems or just slow the pipeline.

Stakeholders want to change the research question mid-pipeline. Scope changes after research has begun waste completed work. Implement a change request process: assess how much existing research applies to the new question, which stages need to rerun, and whether the timeline can accommodate the change. Sometimes it's more efficient to complete the current research and start a parallel investigation for the new question.