Dispatching Parallel Agents

Dispatching Parallel Agents

Iron Law: Parallelize when tasks have NO dependencies. Sequentialize when outputs flow to inputs.

When to Use

The Process

1. IDENTIFY   -> Find parallelizable work
2. VALIDATE   -> Confirm independence
3. STRUCTURE  -> Prepare Task tool calls
4. DISPATCH   -> Execute in parallel
5. COLLECT    -> Gather results
6. SYNTHESIZE -> Combine insights

Step 1: Identify Parallelizable Work

Good Candidates:

## Feature: Multi-Platform Integration

### Parallelizable:
- [ ] Research Stripe API patterns (deep-researcher)
- [ ] Research SendGrid email patterns (deep-researcher)
- [ ] Research Twilio SMS patterns (deep-researcher)

### Sequential (depends on above):
- [ ] Design unified integration layer (backend-engineer)

Parallelization Checklist:

• Tasks don't modify same files
• Tasks don't depend on each other's output
• Tasks don't require shared state
• Order of completion doesn't matter
• Failures can be handled independently

Step 2: Validate Independence

Dependency Matrix:

Independence Rules:

• Read-only tasks are always parallelizable
• Write tasks to DIFFERENT files are parallelizable
• Write tasks to SAME files are NOT parallelizable
• Tasks with upstream dependencies are NOT parallelizable

Step 3: Structure Parallel Task Calls

Single Message, Multiple Task Invocations:

I'll dispatch three research tasks in parallel.

Task: @deep-researcher
## Research: Stripe Payment Patterns
Load skills: documentation-research, api-design
Investigate best practices for Stripe webhook handling,
idempotency, and error recovery.

---

Task: @deep-researcher
## Research: SendGrid Email Patterns
Load skills: documentation-research, api-design
Investigate best practices for SendGrid template management,
tracking, and bounce handling.

---

Task: @deep-researcher
## Research: Twilio SMS Patterns
Load skills: documentation-research, api-design
Investigate best practices for Twilio message delivery,
status callbacks, and rate limiting.

Structuring Rules:

• All Task invocations in SAME message
• Each task gets complete, independent context
• Include all required skills per task
• Define clear deliverables per task
• Specify consistent output format

Step 4: Dispatch Execution

Execution Patterns:

Pattern A: Homogeneous (Same Agent Type)

Task: @deep-researcher
Research topic A...

Task: @deep-researcher
Research topic B...

Task: @deep-researcher
Research topic C...

Use when: Same type of work across different domains.

Pattern B: Heterogeneous (Different Agent Types)

Task: @security-auditor
Audit authentication flow...

Task: @performance-optimizer
Analyze bundle size...

Task: @quality-engineer
Review test coverage...

Use when: Different expertise needed for independent validations.

Pattern C: Exploration (Multiple Approaches)

Task: @backend-engineer
Implement using approach A (Redux)...

Task: @backend-engineer
Implement using approach B (Zustand)...

Task: @backend-engineer
Implement using approach C (Jotai)...

Use when: Evaluating different solutions before committing.

Step 5: Result Collection

Collect from each parallel task:

## Results: [Task Name]

### Agent: [agent-name]
### Status: SUCCESS | PARTIAL | FAILED

### Findings:
- Key finding 1
- Key finding 2
- Key finding 3

### Artifacts:
- File: /path/to/output.md
- Notes: Inline summary

### Recommendations:
- Recommendation 1
- Recommendation 2

### Confidence: HIGH | MEDIUM | LOW

Collection Rules:

• Wait for ALL parallel tasks to complete
• Document failures separately from successes
• Preserve all artifacts and findings
• Note confidence levels for each result

Step 6: Result Synthesis

Combining Parallel Results:

## Synthesis: [Feature/Research Area]

### Completed Tasks: 3/3

### Aggregated Findings:
| Topic | Key Insight | Confidence |
|-------|-------------|------------|
| Stripe | Use webhooks with idempotency keys | HIGH |
| SendGrid | Template versioning required | MEDIUM |
| Twilio | Status callbacks essential | HIGH |

### Patterns Identified:
- All services require idempotent handling
- Webhook verification is critical for all
- Error retry with exponential backoff needed

### Conflicts/Divergence:
- None | [Describe any conflicting findings]

### Recommended Next Steps:
1. Design unified webhook handler
2. Implement idempotency layer
3. Create service abstraction

### Tasks for Sequential Phase:
- [ ] Unified integration design (depends on all research)

Error Handling

Partial Failures

## Parallel Execution Summary

### Succeeded: 2/3
- [x] Research A - Complete
- [x] Research B - Complete
- [ ] Research C - FAILED

### Failure Analysis:
- Task: Research C
- Error: API documentation unavailable
- Impact: Cannot proceed with C integration

### Recovery Options:
1. Retry with different source
2. Proceed without C (if optional)
3. Block and escalate to user

Failure Handling Rules:

• Successes are valid even if some tasks fail
• Document failure reasons clearly
• Assess impact on dependent work
• Offer recovery options to user
• Don't retry automatically without user consent

Timeout Handling

## Timeout Handling

### Completed: 2/3
### Timed Out: 1/3

### Action:
- Preserve completed results
- Document timeout: Task C exceeded 5 min limit
- Options:
  1. Retry with simpler scope
  2. Continue without result
  3. Increase timeout and retry

Common Use Cases

Use Case: Codebase Exploration

Task: @deep-researcher
Find all authentication implementations...

Task: @deep-researcher
Find all database query patterns...

Task: @deep-researcher
Find all error handling patterns...

Use Case: Multi-File Validation

Task: @quality-engineer
Validate frontend test coverage...

Task: @quality-engineer
Validate backend test coverage...

Task: @quality-engineer
Validate E2E test coverage...

Use Case: Solution Comparison

Task: @backend-engineer
Prototype solution using ORM A...

Task: @backend-engineer
Prototype solution using ORM B...

Red Flags

• Parallel tasks modifying same file -> Race condition
• Missing independence validation -> Hidden dependencies
• Not waiting for all results -> Incomplete synthesis
• Ignoring partial failures -> Lost information
• Sequential data flow in parallel -> Incorrect ordering

Decision Criteria

Integration

Pairs with: subagent-driven-development (for complex orchestration), debug (parallel hypothesis testing), brainstorm (parallel ideation)