Coordinates parallel investigation threads to simultaneously explore multiple hypotheses or root causes across different system areas. Use when debugging production incidents, slow API performance, multi-system integration failures, or complex bugs where the root cause is unclear and multiple plausible theories exist; when serial troubleshooting is too slow; or when multiple investigators can divide root-cause analysis work. Provides structured phases for problem decomposition, thread assignment, sync points with Continue/Pivot/Converge decisions, and final report synthesis.
Coordinate parallel investigation threads to explore multiple hypotheses simultaneously. Most effective for production incidents, performance regressions, or integration failures where the root cause is unclear.
When uncertain, explore multiple paths in parallel. Converge when evidence points to an answer.
Parallel investigation reduces time-to-solution by eliminating serial bottlenecks.
Break the problem into independent investigation threads:
Problem: API responses are slow
Investigation Threads:
├── Thread A: Database performance
│ └── Check slow queries, indexes, connection pool
├── Thread B: Application code
│ └── Profile endpoint handlers, check for N+1
├── Thread C: Infrastructure
│ └── Check CPU, memory, network latency
└── Thread D: External services
└── Check third-party API response times
Each thread should be independent (no blocking dependencies), focused (clear scope), and time-boxed.
Assign threads with clear ownership:
## Thread A: Database Performance
**Investigator:** [Name/Agent A]
**Duration:** 30 minutes
**Scope:**
- Query execution times
- Index utilization
- Connection pool metrics
**Report Format:** Summary + evidence
Each thread follows this pattern:
Thread Log Template:
## Thread: [Name]
**Start:** [Time]
### Findings
- [Timestamp] [Finding]
### Evidence
- [Log/Metric/Screenshot]
### Preliminary Conclusion
[What this thread suggests about the problem]
Regular convergence to share findings:
Sync Point Agenda:
1. Each thread report (2 min each)
2. Discussion & correlation (5 min)
3. Decision: Continue, Pivot, or Converge (3 min)
Sync Point Decisions:
When a thread identifies the likely cause:
Hub and Spoke: One coordinator assigns threads, tracks progress, calls sync points, and makes convergence decisions. Best when one person has the most context.
Peer Network: Equal investigators post findings to a shared channel and self-organize convergence when a pattern emerges. Best when investigators have similar expertise.
[Thread A] [Status] Starting query analysis
[Thread B] [Finding] No N+1 patterns in user endpoint
[Thread A] [Finding] Slow query: SELECT * FROM orders WHERE...
[Thread C] [Dead End] CPU and memory within normal
[Thread A] [Hot Lead] Missing index on orders.user_id
## Thread A Summary
**Status:** Hot Lead
**Key Finding:** Missing index on orders.user_id
**Evidence:** Query taking 3.2s, explain shows full table scan
**Recommendation:** Likely root cause — suggest converge
| Thread Status | Action |
|---|---|
| All exploring | Continue parallel |
| One hot lead | Validate lead, others support |
| Multiple leads | Prioritize by evidence strength |
| All dead ends | Reframe problem, new threads |
| Confirmed cause | Converge, begin fix |
A typical two-hour investigation: