dispatching-parallel-agents

Group failures by independent problem domain, then dispatch one subagent per domain in a single response so they run concurrently. Each agent gets a focused prompt with the failing test names, error messages, constraints, and an expected summary of findings and fixes.

Use parallel dispatch when failures are independent, such as different test files or subsystems with no shared state. Investigate sequentially when failures are related, when fixing one might fix others, or when understanding requires full system context.

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 changes.

Yes, if agents share state or edit the same files they can interfere. Avoid this by assigning strictly separate scopes, and after agents return, review each summary, check for overlapping edits, and run the full test suite to verify integration.

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 expectations that hide what actually changed.