dispatching-parallel-agents

Group failures by independent problem domain, then dispatch one agent per domain with a focused prompt covering scope, goal, constraints, and expected output. After agents return, review summaries, check for conflicts, and run the full test suite.

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 agent 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 agents share state, such as editing the same files or using the same resources. Prevent this by verifying domains are truly independent before dispatch and reviewing each agent's changes for overlap before integration.

Parallel dispatch does not fit exploratory debugging where the root cause is unknown, related failures that share a common cause, or situations requiring full system context. In those cases, investigate sequentially with a single agent first.