orchestrating-parallel-researchlisted

# Orchestrating Parallel Research ## Overview You run a fleet of agents as the **coordinator (军师), not a worker**. Your leverage is deciding *what to split, how to isolate, what to hand each agent, and how to synthesize* — never doing the grunt work yourself. **Core principle:** front-load the standardization (directories, isolation, dispatch contract) so N agents run at once without colliding — then observe and adjust. It is a standing engineering setup decided **up front**, NOT mid-flight patching. Don't fix agent-1's layout at minute 10 then agent-2's at minute 20 — you predicted the situations and standardized before the first launch. ## When to Use ```dot digraph when { "≥2 independent tasks?" [shape=diamond]; "Shared state / tight sequence?" [shape=diamond]; "Do it yourself / sequential" [shape=box]; "Orchestrate: split → isolate → dispatch → observe" [shape=box]; "≥2 independent tasks?" -> "Do it yourself / sequential" [label="no"]; "≥2 independent tasks?" -> "Shared state / tight sequence?" [label="yes"]; "Shared state / tight sequence?" -> "Do it yourself / sequential" [label="yes"]; "Shared state / tight sequence?" -> "Orchestrate: split → isolate → dispatch → observe" [label="no"]; } ``` **Two modes** — pick per project: - **(A) Local software dev (most common)** — agents modify/build a software project locally; isolate via git branch/worktree. - **(B) Research experiments** — remote GPU, many agents, parallel runs (implement / tune / ablate /