dispatching-parallel-agents

Group failures by independent problem domain, then dispatch one agent per domain with a focused prompt covering scope, constraints, and expected output. After agents return, review summaries, check for conflicting edits, 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 full system context is needed, 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 root cause summary.

Yes, agents can conflict if they edit the same files or share state. Prevent this by assigning strictly independent domains, then verify after completion by reviewing each summary and running the full test suite to catch integration issues.

Common mistakes include overly broad scopes like fixing all tests at once, missing context such as error messages, absent constraints that let agents refactor unrelated code, and vague output requirements that hide what actually changed.