Jesse Vincent (obra) / dispatching-parallel-agents
When should Claude split a problem across parallel subagents?
When the problems are independent enough that fixing one cannot change another.
What to remember
- Independence is the test. Related failures go to one investigator, because a single fix may clear several.
- Parallel means one message: several dispatch calls in a single response run at once, while one per response runs in sequence.
- Subagents never inherit the session's history, so the prompt has to carry the error messages, the test names and the limits.
- Integration is the main agent's job: read every summary, look for overlapping edits, run the whole suite.
01What it changes in practice
Investigating unrelated failures one after another wastes time, and doing it in one long context fills that context with several stories at once. Separate subagents keep each investigation clean and leave the main session free for coordination.
The prompt template is the useful part. A good dispatch names one test file or subsystem, pastes the actual errors, rules out the shortcut that would hide the problem, such as raising timeouts, and says what to return. The skill's worked example splits six failures across three files between three agents, each of which finds a different cause.
- Scope: one test file or subsystem.
- Goal: make those tests pass.
- Constraints: leave the rest of the code alone.
- Output: a summary of what was found and fixed.
02Where it disappoints
It cannot tell you whether two failures are related. That judgement comes before the skill runs, and a wrong call produces several agents fixing symptoms of one bug in incompatible ways.
It also assumes a harness that can start subagents and run them at the same time. Without that, the pattern turns into sequential work with extra prompts to write.
Install and first run
- Install superpowers in Claude Code with /plugin install superpowers@claude-plugins-official. It is MIT licensed, and this skill is a single SKILL.md that relies on the harness being able to start subagents.
- Group the failures by domain first, for example one test file each, and confirm that none of them depends on another.
- When the subagents report back, run the full test suite yourself. Separate fixes can still conflict, and the skill asks for spot checks because agents make systematic errors.
Questions people actually ask
- How is it different from subagent-driven-development?
- subagent-driven-development executes a written plan with a fresh subagent per task and a review after each, and it says never to run implementation subagents in parallel. This skill is for unrelated problems that can be worked on at the same time.
- When does it apply?
- Its description says two or more independent tasks with no shared state and no sequential dependency. Its examples are three or more test files failing for different root causes.
- What should each subagent return?
- A summary of the root cause and the changes made, requested in the prompt itself, so the main agent can check for conflicts before integrating.
Sources
Machine readable versions of this page