Introduction
I reviewed a multi-agent PR last month where three evaluators ran one after another. They had no dependency on each other. The team added two minutes of latency for no reason. The fix was a one-line parallel fan-out.
The opposite failure is worse: parallelizing a research-writer-reviewer chain where the writer needs research output. You get race conditions and garbage merges. One question tells you which pattern to use.
Pattern 1: Sequential
Use sequential orchestration when each agent needs the previous agent's output. Research feeds Writer feeds Reviewer. The writer cannot start before research finishes. The reviewer cannot start before writing finishes.
Sequential flow costs roughly 3x latency because agents run one after another. That latency is the price of correctness. You only pay it when there is a real dependency.
If agent B needs agent A's output to do its job, you must go sequential. No shortcut.
Pattern 2: Parallel
Use parallel orchestration when agents work on independent slices of the same task. Three product descriptions. Five test cases. CORE, EEAT, and Schema evaluators in the content quality pipeline.
No agent depends on another's output, so they run at once. Parallel execution can save up to 70% latency. Independence is the speedup.
The test before you code
Draw the dependency graph. For every edge between agents, ask: does B need A's output? If yes, sequential. If no, parallel.
Supervisor patterns add another axis. A supervisor coordinating workers may run workers in parallel while the supervisor itself waits for all results before the next step. Read supervisor pattern vs handoffs for when to use a central coordinator versus agent-to-agent handoffs.
Common mistakes
- Running independent evaluators sequentially because the framework default is sequential.
- Parallelizing a chain with hidden dependencies (writer "mostly" does not need research).
- Not measuring wall-clock time per pattern before committing to architecture.
- Mixing parallel and sequential in one graph without documenting which nodes fan out.
Conclusion
Stop guessing. Draw the flow. Cut latency in half on the parallel-eligible parts. Pay the 3x cost only where correctness demands it.
