dispatching-parallel-agentslisted

# Dispatching Parallel Agents Run independent work concurrently instead of in series. The win is wall-clock; the risk is collision — so this applies only when the pieces genuinely don't touch each other. ## When to use - Two or more pieces of work that are **provably independent**: disjoint files, disjoint state, and no "B needs A's result." - **Skip** when tasks share a file or dependency (sequence them — `executing-plans`), when one needs another's output, or when the whole thing is quick inline. ## The independence test — confirm before fanning out Check every pair; if any fails, group them into one agent or sequence them instead: - **Files** — they edit disjoint paths. Two agents on the same file race. - **State** — disjoint ports, databases, fixtures. If they run a server or migrations, isolate each (`using-git-worktrees`). - **Order** — none consumes another's output. A dependency is a sequence, not a fan-out. ## The dispatch packet (per agent) Each agent starts cold — hand it everything, never your session history: - **Scope** — the exact problem and files this agent owns, and what it must NOT touch. - **Objective + deliverable** — what "done" means, and the precise shape to report back, so results reconcile. - **Constraints** — name the tier to run at (omit it and the agent silently inherits the session's costliest one), the quality rules, and "stay in scope; report out-of-scope rather than reaching." - **Isolation** — if it builds or runs anything, its own w