The rule
Parallelism is for breadth, not for vibes. Spawn a fleet when the work genuinely fans out — many folders to inventory, many dimensions to review. One tight agent beats five vague ones, and the dispatcher stays accountable for the merged result.
When to run it
Large sweeps (audit a codebase, inventory a drive), independent perspectives (design reviews), or work that exceeds one context window.
The play
1. Scout inline first: cheap listing commands to learn the shape of the work before spawning anything. 2. Give each worker a self-contained brief: exact paths, exact deliverable schema, explicit budgets ("view at most 10 images"), and the hard exclusions restated. 3. Prefer pipelines to barriers — let item B start stage two while item A is still in stage one. 4. Verify adversarially: findings that matter get a second pass trying to refute them before you act. 5. Reconcile centrally: the dispatcher merges outputs, resolves conflicts, and owns the final answer — workers never act on production directly. 6. Watch the budget like cash: if a fleet blows its limit, halve the scope and add hard caps before rerunning.
Where it breaks
Unscoped workers grazing through terabytes, duplicate work because the dispatcher also did the task, and merged reports nobody verified. The fleet is leverage, not magic.