dispatching-parallel-agents · diff
git:20260903.f055d0e to git:20260920.8265b5c
59 added, 175 removed. Audit A to A.
---
name: dispatching-parallel-agents
- description: "Use when facing 2+ independent tasks without a written plan, with no shared state or sequential dependencies, where parallel delegation beats inline cost; otherwise inline. Planned tasks use subagent-driven-development."
+ description: "Use when facing 2+ independent tasks without a written plan, with no conflicting shared mutable state or sequential dependencies, where parallel delegation beats inline cost; otherwise inline. Planned tasks use subagent-driven-development."
---
# Dispatching Parallel Agents
- ## Overview
-
- You delegate tasks to specialized agents with isolated context. By precisely crafting their instructions and context, you ensure they stay focused and succeed at their task. They should never inherit your session's context or history — you construct exactly what they need. This also preserves your own context for coordination work.
-
- 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
-
- ```dot
- digraph when_to_use {
- "Multiple failures?" [shape=diamond];
- "Are they independent?" [shape=diamond];
- "Single agent investigates all" [shape=box];
- "One agent per problem domain" [shape=box];
- "Can they work in parallel?" [shape=diamond];
- "Sequential agents" [shape=box];
- "Parallel dispatch" [shape=box];
-
- "Multiple failures?" -> "Are they independent?" [label="yes"];
- "Are they independent?" -> "Single agent investigates all" [label="no - related"];
- "Are they independent?" -> "Can they work in parallel?" [label="yes"];
- "Can they work in parallel?" -> "Parallel dispatch" [label="yes"];
- "Can they work in parallel?" -> "Sequential agents" [label="no - shared state"];
- }
- ```
-
- **Use when:**
- - 3+ test files failing with different root causes
- - Multiple subsystems broken independently
- - Each problem can be understood without context from others
- - No shared state between investigations
-
- **Don't use when:**
- - Failures are related (fix one might fix others)
- - Need to understand full system state
- - Agents would interfere with each other
-
- ### Event-Based Opportunities
-
- Parallel investigation may also be considered after the minimum baseline is
- understood when one of these events occurs:
-
- - evidence or test results conflict and can be checked independently;
- - a high-risk change needs an independent, read-only compatibility or impact review;
- - a blocked attempt can be retried with materially different context or model;
- - separate host/install surfaces can be inspected without shared writes.
-
- These events do not override the safety gates. Unknown dependencies, shared
- transactions or resources, stale workspace state, untrusted input boundaries,
- uncertain host capability, or results that cannot be compactly synthesized
- must stay inline. A parallel child is an investigator, not a second Git owner
- or a completion authority.
-
- ## The Pattern
-
- ### 1. Identify Independent Domains
-
- Group failures by what's broken:
- - File A tests: Tool approval flow
- - File B tests: Batch completion behavior
- - File C tests: Abort functionality
-
- Each domain is independent - fixing tool approval doesn't affect abort tests.
-
- ### 2. Create Focused Agent Tasks
-
- Each agent gets:
- - **Specific scope:** One test file or subsystem
- - **Clear goal:** Make these tests pass
- - **Constraints:** Don't change other code
- - **Expected output:** Summary of what you found and fixed
-
- ### 3. Dispatch in Parallel
-
- ```typescript
- // In Claude Code / AI environment
- Task("Fix agent-tool-abort.test.ts failures")
- Task("Fix batch-completion-behavior.test.ts failures")
- Task("Fix tool-approval-race-conditions.test.ts failures")
- // All three run concurrently
- ```
-
- ### 4. Review and Integrate
-
- When agents return:
- - Read each summary
- - Verify fixes don't conflict
- - Run full test suite
- - Integrate all changes
-
- ## Agent Prompt Structure
-
- Good agent prompts are:
- 1. **Focused** - One clear problem domain
- 2. **Self-contained** - All context needed to understand the problem
- 3. **Specific about output** - What should the agent return?
-
- ```markdown
- Fix the 3 failing tests in src/agents/agent-tool-abort.test.ts:
-
- 1. "should abort tool with partial output capture" - expects 'interrupted at' in message
- 2. "should handle mixed completed and aborted tools" - fast tool aborted instead of completed
- 3. "should properly track pendingToolCount" - expects 3 results but gets 0
-
- These are timing/race condition issues. Your task:
-
- 1. Read the test file and understand what each test verifies
- 2. Identify root cause - timing issues or actual bugs?
- 3. Fix by:
- - Replacing arbitrary timeouts with event-based waiting
- - Fixing bugs in abort implementation if found
- - Adjusting test expectations if testing changed behavior
-
- Do NOT just increase timeouts - find the real issue.
-
- Return: Summary of what you found and what you fixed.
- ```
-
- ## Common Mistakes
-
- **❌ Too broad:** "Fix all the tests" - agent gets lost
- **✅ Specific:** "Fix agent-tool-abort.test.ts" - focused scope
-
- **❌ No context:** "Fix the race condition" - agent doesn't know where
- **✅ Context:** Paste the error messages and test names
-
- **❌ No constraints:** Agent might refactor everything
- **✅ Constraints:** "Do NOT change production code" or "Fix tests only"
+ ## Purpose
- **❌ Vague output:** "Fix it" - you don't know what changed
- **✅ Specific:** "Return summary of root cause and changes"
+ Use parallel children for two or more ad-hoc, bounded tasks only when their
+ independence is already credible and concurrency is worth the coordination.
+ Parallelism changes elapsed time; it does not relax evidence, ownership, or
+ completion requirements.
- ## When NOT to Use
+ ## Dispatch Gate
- **Related failures:** Fixing one might fix others - investigate together first
- **Need full context:** Understanding requires seeing entire system
- **Exploratory debugging:** You don't know what's broken yet
- **Shared state:** Agents would interfere (editing same files, using same resources)
+ Dispatch only when all are true:
- ## Real Example from Session
+ - there are `2+` distinct tasks or evidence questions;
+ - one task's result is not needed to define or start another;
+ - the tasks do not require overlapping writes or the same mutable resource;
+ - a shared root cause is unlikely based on current evidence;
+ - each result can be returned with bounded evidence and unresolved unknowns;
+ - available concurrency and expected work justify coordination cost.
- **Scenario:** 6 test failures across 3 files after major refactoring
+ Keep work inline when decomposition is still exploratory, failures may share a
+ root cause, full-system context is required, or tasks are too small to repay the
+ handoff. A written implementation plan routes to
+ `aegis:subagent-driven-development`, not this ad-hoc workflow.
- **Failures:**
- - agent-tool-abort.test.ts: 3 failures (timing issues)
- - batch-completion-behavior.test.ts: 2 failures (tools not executing)
- - tool-approval-race-conditions.test.ts: 1 failure (execution count = 0)
+ ## Context And Ownership
- **Decision:** Independent domains - abort logic separate from batch completion separate from race conditions
+ Choose the live host's context inheritance mode deliberately. Give each child
+ the minimum sufficient instructions and evidence; do not rely on accidental
+ inheritance or assume that context must never be inherited.
- **Dispatch:**
- ```
- Agent 1 → Fix agent-tool-abort.test.ts
- Agent 2 → Fix batch-completion-behavior.test.ts
- Agent 3 → Fix tool-approval-race-conditions.test.ts
- ```
+ Each task packet states:
- **Results:**
- - Agent 1: Replaced timeouts with event-based waiting
- - Agent 2: Fixed event structure bug (threadId in wrong place)
- - Agent 3: Added wait for async tool execution to complete
+ - goal and question to resolve;
+ - allowed files, systems, and side effects;
+ - known facts and evidence locations;
+ - constraints, non-goals, and stop condition;
+ - expected result shape, including unknowns and verification refs.
- **Integration:** All fixes independent, no conflicts, full suite green
+ Isolated model context does not imply an isolated filesystem, process, Git
+ repository, credential, rate limit, or external service. Prefer read-only
+ investigation. If children may edit, assign disjoint write ownership explicitly.
+ The coordinator owns staging, commits, branches, worktrees, integration, and other Git lifecycle mutations.
- **Time saved:** 3 problems solved in parallel vs sequentially
+ ## Execution
- ## Key Benefits
+ 1. Establish the minimum common baseline and record evidence for the task split.
+ 2. Dispatch one bounded task per independent domain, within host concurrency
+ limits.
+ 3. Optionally continue coordinator work that does not race child reads or writes.
+ 4. On return, check evidence freshness, unknowns, overlapping assumptions, and
+ visible workspace changes.
+ 5. Synthesize disagreements before acting. If results reveal coupling, stop
+ parallel mutation and return the work to one owner.
+ 6. For edits, run integrated verification after accepted changes are combined.
+ For read-only work, validate the synthesis against the cited sources.
- 1. **Parallelization** - Multiple investigations happen simultaneously
- 2. **Focus** - Each agent has narrow scope, less context to track
- 3. **Independence** - Agents don't interfere with each other
- 4. **Speed** - 3 problems solved in time of 1
+ The coordinator owns the concurrency budget. Children do not delegate
+ recursively unless their packet explicitly permits it. A failed, cancelled, or
+ timed-out child contributes any available partial evidence; otherwise record no
+ result and the unresolved unknowns. Retry only with a materially different
+ packet or serialize the task.
- ## Verification
+ Child output is evidence or a proposal, not a `GateDecision`, completion authority, or permission for external action.
- After agents return:
- 1. **Review each summary** - Understand what changed
- 2. **Check for conflicts** - Did agents edit same code?
- 3. **Run full suite** - Verify all fixes work together
- 4. **Spot check** - Agents can make systematic errors
+ ## Common Failure Modes
- ## Real-World Impact
+ - Separate files are treated as proof of separate root causes.
+ - Children receive broad conversation history instead of bounded task context.
+ - Multiple children edit the same owner or mutate shared services concurrently.
+ - A child report is accepted without inspecting evidence or current files.
+ - Parallel work is used for a written plan and bypasses its review checkpoints.
+ - The coordinator verifies each result alone but never checks the integrated
+ state.
- From debugging session (2025-10-03):
- - 6 failures across 3 files
- - 3 agents dispatched in parallel
- - All investigations completed concurrently
- - All fixes integrated successfully
- - Zero conflicts between agent changes
+ When any of these appears, narrow the packets, serialize the shared portion, or
+ return to the owning debugging or plan workflow.