dispatching-parallel-agents

Group failures by root cause into independent domains, then dispatch one agent per domain with a focused prompt containing the error messages, scope constraints, and expected output. Each agent works concurrently with isolated context, and you integrate their fixes afterward.

Use parallel agents when failures are independent—different test files, subsystems, or bugs with no shared state. Avoid parallel dispatch when failures are related, when understanding requires full system context, 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 changes.

Yes, conflicts occur if agents share state or edit the same files. Prevent this by assigning each agent a distinct problem domain and file scope, then after they return, review summaries, check for overlapping edits, and run the full test suite.

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