Parallel Sub-Agents: Run 5 Tasks at Once

Parallelism works only when ownership is explicit

Spawning five workers is easy. Merging five workers that all touched the same responsibility is where teams lose time. Parallel sub-agents help only when each branch has a bounded question or write scope.

The main agent should keep the critical path local, delegate non-blocking slices, and integrate only the pieces that materially advance the goal.

When This Pattern Fits

• You have several independent questions or code changes that do not share the same write set.
• The main rollout is blocked by breadth, not by one deeply sequential problem.
• You want faster progress without turning every task into manual coordination overhead.

Reference Workflow

Keep the immediate blocking task on the main thread.

Delegate bounded side tasks with explicit ownership and outputs.

Let workers run in parallel while the main agent continues useful local work.

Merge completed results only after checking that ownership boundaries held.

Step 1: Split by responsibility, not by file count

A good worker owns a concrete module, route, or question. “Take half the repository” is not a delegation strategy. The branch should be small enough that the worker knows exactly when it is done.

[
  { "worker": "A", "owns": "billing API routes" },
  { "worker": "B", "owns": "admin dashboard copy updates" },
  { "worker": "C", "owns": "search indexing verification" }
]

Step 2: Do not delegate the next blocking step

If the main agent cannot proceed until a result comes back, that task usually belongs on the critical path and should stay local. Delegation shines on sidecar tasks that unblock later stages without stalling the present one.

Step 3: Merge with a contract, not with hope

Every worker should return changed files, assumptions, and unresolved risks. That gives the main agent a deterministic handoff instead of a vague “done” signal.

Preflight Checklist

• Assign each worker a disjoint write scope whenever possible.
• Tell workers they are not alone in the codebase and must not revert unrelated edits.
• Reuse existing workers for follow-up questions when context matters.
• Measure whether delegation shortened the critical path, not just whether more work happened in parallel.

Troubleshooting

How many workers should I spawn?

Only as many as you have genuinely independent branches. More workers than clear ownership boundaries usually creates merge cost instead of speed.

What if two workers need the same file?

That is a warning sign. Either keep the task local or restructure ownership so one worker owns the file and the other returns analysis only.

When should I wait for a worker immediately?

Only when the next critical-path action truly depends on that result. Waiting by reflex kills the value of delegation.

Next Steps

• Multi-Agent Orchestration — See the broader control loop around worker delegation.
• Memory System Deep Dive — Keep each worker context bounded.
• Architecture Walkthrough — Trace where worker execution lives in the runtime.

---

Last updated: April 14, 2026 · Hermes Agent v0.8