dispatching-parallel-agents

Group failures by independent problem domain, then dispatch one subagent per domain in the same response so they run concurrently. Each agent gets a focused prompt with the specific test file, error messages, constraints, and expected output summary.

Use parallel agents when failures are independent, such as different test files or subsystems with no shared state. Avoid parallel dispatch when failures are related, when fixing one might fix others, or when agents would edit the same files.

A good prompt is focused on one problem domain, self-contained with pasted error messages and test names, explicit about constraints like not changing production code, and specific about the expected output such as a summary of root cause and fixes.

Conflicts happen when domains are not truly independent and agents edit the same code or share state. After agents return, review each summary, check for overlapping edits, and run the full test suite to verify the fixes integrate cleanly.

Avoid parallel dispatch for related failures, exploratory debugging where the root cause is unknown, situations requiring full system context, or any work involving shared state where agents would interfere with each other.