Dispatching Parallel Agents
Overview
When you have multiple unrelated failures (different test files, different subsystems, different bugs), investigating them sequentially wastes time. Each investigation is independent and can happen in parallel.
Core principle: Dispatch one agent per independent problem domain. Let them work concurrently.
When to Use
Decision flow: Multiple failures? → Are they independent? (No → single agent) | Independent? → Can work in parallel? (No/shared state → sequential) | Yes → Parallel dispatch
Use when: 3+ test files with different root causes | Multiple subsystems broken independently | Each problem understood without others | No shared state
Don't use when: Failures related (fix one might fix others) | Need full system state | Agents would interfere
The Pattern
1. Identify Independent Domains: Group failures by what's broken (File A: approval flow, File B: batch behavior, File C: abort). Each domain independent.
2. Create Focused Agent Tasks: Each agent gets: specific scope (one file/subsystem), clear goal (make tests pass), constraints (don't change other code), expected output (summary of findings/fixes).
3. Dispatch in Parallel: Task("Fix agent-tool-abort.test.ts") + Task("Fix batch-completion.test.ts") + Task("Fix tool-approval-races.test.ts") - all concurrent.
4. Review and Integrate: Read summaries → verify no conflicts → run full test suite → integrate all changes.
Agent Prompt Structure
Good prompts are: Focused (one problem domain), Self-contained (all context included), Specific output (what to return).
Example: "Fix 3 failing tests in agent-tool-abort.test.ts: [list tests + expected behavior]. Timing/race issues. Read tests → identify root cause → fix (event-based waiting, not timeout increases). Return: Summary of findings and fixes."
Common Mistakes
| ❌ Bad | ✅ Good |
|---|---|
| Too broad: "Fix all tests" | Specific: "Fix agent-tool-abort.test.ts" |
| No context: "Fix race condition" | Context: Paste error messages + test names |
| No constraints: Agent refactors everything | Constraints: "Do NOT change production code" |
| Vague output: "Fix it" | Specific: "Return summary of root cause and changes" |
When NOT to Use
Related failures (fix one might fix others) | Need full context | Exploratory debugging | Shared state (same files/resources)
Real Example
Scenario: 6 failures across 3 files after refactoring. Decision: Independent domains → parallel dispatch. Results: Agent 1 (timeouts → events), Agent 2 (event structure bug), Agent 3 (async wait). All independent, no conflicts, suite green. 3 problems solved in time of 1.
Key Benefits
Parallelization (simultaneous) | Focus (narrow scope) | Independence (no interference) | Speed (3 → 1 time unit)
Verification
After agents return: Review summaries → check for conflicts → run full suite → spot check for systematic errors.
Blocker Criteria
STOP and report if:
| Decision Type | Blocker Condition | Required Action |
|---|---|---|
| Independence check | Problems share state or files | STOP and use sequential investigation instead |
| Minimum threshold | Fewer than 3 independent failures | STOP and investigate directly without parallel dispatch |
| Conflict detection | Agent changes would overlap | STOP and re-partition domains |
| Context requirements | Problem requires full system context | STOP and use single agent investigation |
Cannot Be Overridden
The following requirements CANNOT be waived:
- Problems MUST be verified independent before parallel dispatch - shared state means sequential
- Minimum 3 failures REQUIRED for parallel dispatch - fewer means direct investigation
- Each agent MUST have focused scope (one file/subsystem) - broad scope is FORBIDDEN
- Agent prompts MUST include constraints about what NOT to change
- Full test suite MUST run after integrating all agent changes
Severity Calibration
| Severity | Condition | Required Action |
|---|---|---|
| CRITICAL | Dispatched agents for related/connected failures | MUST stop and switch to sequential investigation |
| CRITICAL | Agent changes conflict with each other | MUST re-partition domains and re-dispatch |
| HIGH | Agent prompt lacks scope constraints | MUST add specific "do NOT change" constraints |
| HIGH | Skipped post-integration test suite | MUST run full test suite before completion |
| MEDIUM | Agent prompt lacks expected output format | Should add specific output requirements |
| LOW | Could optimize domain partitioning | Fix in next iteration |
Pressure Resistance
| User Says | Your Response |
|---|---|
| "Just dispatch agents for all failures, don't analyze" | "MUST verify independence first. Related failures need sequential investigation to avoid conflicts." |
| "Two failures is enough for parallel dispatch" | "CANNOT dispatch for fewer than 3 failures. Direct investigation is faster for 1-2 problems." |
| "Skip the verification step, agents finished successfully" | "MUST run full test suite after integration. Agent success doesn't guarantee no conflicts." |
| "Give agents broad scope to fix more issues" | "Focused scope prevents interference. MUST limit each agent to one file/subsystem." |
Anti-Rationalization Table
| Rationalization | Why It's WRONG | Required Action |
|---|---|---|
| "These failures look independent enough" | Looking independent ≠ verified independent; check for shared state | MUST verify independence before dispatch |
| "Dispatching for 2 failures saves time" | Overhead of parallel dispatch exceeds benefit for <3 failures | MUST investigate directly if fewer than 3 |
| "Agents can figure out their own scope" | Unclear scope causes agents to interfere with each other | MUST provide explicit scope and constraints |
| "Test suite passed for each agent" | Individual success doesn't catch integration conflicts | MUST run full suite after integration |
| "Re-partitioning is too much work" | Conflicting changes create more work than re-partitioning | MUST re-partition if domains overlap |