Parallel vs. Sequential Orchestration

Claude Code Agents: Advanced Orchestration

Chapter 3 · Parallel vs. Sequential Orchestration

Once more than one agent is involved in a task, a basic structural question arises: should they run at the same time, or one after another? This chapter covers both patterns, how to tell which one actually fits, and a hidden risk specific to running agents in parallel that's easy to overlook.

Parallel Orchestration

Launching several agents at once makes sense when their tasks are genuinely independent — neither needs the other's result to do its own job. Several research agents each investigating a different area of an unfamiliar codebase simultaneously, or a code-review agent and a documentation agent working on two entirely separate, unrelated modules at the same time, are both good fits. The benefit is straightforward: total wall-clock time is much closer to the slowest single agent's own time, rather than the sum of every agent's time added together.

Sequential Orchestration

Running agents one after another is necessary specifically when a later agent's task genuinely depends on an earlier agent's actual result. A research agent's findings feeding into a planning agent's proposal, which then feeds into a coding agent's implementation, can't be parallelized — each step needs the previous step's real output to even begin working, not just a guess at what that output might turn out to be.

How to Tell Which Pattern Fits

The deciding question for any two steps: does the second step need the first step's actual result before it can start? If yes, sequential is the only option that makes sense. If the tasks are genuinely independent, parallel is available and usually faster. A common mistake in each direction: running independent tasks sequentially "just to be safe," wasting time for no real benefit; or parallelizing tasks that turn out to have a dependency nobody noticed, leaving one agent working from incomplete or missing information because the agent it actually depended on hadn't finished yet.

Mixed Patterns: Fan-Out and Fan-In

Most real workflows aren't purely one pattern or the other. A common mixed shape: three independent research agents run in parallel (a fan-out), and once all three finish, their combined findings feed sequentially into a single planning agent (a fan-in) that couldn't reasonably start until every one of those three results was actually available.

Aspect	Parallel	Sequential
Requires a dependency?	No — tasks are independent	Yes — each step needs the prior step's real result
Total time	Roughly the slowest single agent's own time	The sum of every step's own time
Coordination risk	Hidden dependencies causing conflicts	A stalled early step blocks everything after it

Ask the dependency question for every adjacent pair explicitly

Before choosing a structure, walk through each pair of steps in the workflow and ask directly: does this step need the previous step's actual output? This simple, explicit check is what actually determines the right structure — defaulting to sequential "to be safe" or parallel "to be fast" out of habit, without asking this question, is how the two common mistakes above actually happen.

Apparent independence isn't the same as true independence

Two agents can look conceptually unrelated while still sharing a hidden, real dependency — for instance, both editing files inside the same shared module or directory, even though their actual tasks seem entirely separate on the surface. Running them in parallel in that case risks a race condition: one agent's changes conflicting with or overwriting the other's, a failure mode sequential execution simply doesn't have, since only one agent is ever touching anything at a time. Verify tasks are truly independent — not just conceptually different — before parallelizing them.

Hands-On Exercises

Exercise 1

A workflow has three steps: research a bug, write a fix, then write a changelog entry describing the fix. Explain which of these steps can run in parallel and which must run sequentially, using this chapter's own deciding question.

📄 View solution

Exercise 2

Two agents are launched in parallel to update documentation for two different features. Both features happen to be documented in the same single README file. Explain what could go wrong here, using this chapter's own warning box.

📄 View solution

Exercise 3

Describe a fan-out/fan-in workflow of your own (different from this chapter's own research-agent example), naming which steps fan out and which single step they fan into, and why that structure is appropriate.

📄 View solution

Chapter 3 Quick Reference

Parallel: independent tasks, run at once, total time is roughly the slowest single agent
Sequential: dependent tasks, run one after another, each step needs the previous step's real result
The deciding question for any two steps: does the second genuinely need the first's actual output?
Fan-out/fan-in: several parallel agents whose combined results feed into one later sequential step
Apparent independence isn't the same as true independence — shared files/state can create a hidden race-condition risk unique to parallel execution