Parallel vs. Sequential Execution

How to decide whether subtasks should run one after another or all at once, and what breaks when you get it wrong.

Agentic Architecture·Lesson 4 of 6·7 min

Once a task is decomposed into subtasks, you still have to decide how to schedule them. The decision is almost always a dependency question, not a preference question: if subtask B needs the output of subtask A, they must run sequentially. If two subtasks are independent of each other, running them in parallel is usually strictly better — same result, less wall-clock time.

The dependency test

Before parallelizing anything, ask: does this step's input depend on another step's output? If yes, that's a sequential edge and no amount of infrastructure lets you skip it — the data literally doesn't exist yet. Prompt chaining is sequential by definition because each step depends on the last. Sectioning-style parallelization is safe specifically because the sections were chosen to be independent in the first place; the independence is what licenses the parallel execution, not the other way around.

A subtler version of this shows up when subtasks look independent but actually share a hidden dependency — for example, two subagents each trying to write to the same file, or two subagents each expected to make the "final" decision on something only one of them should decide. These aren't data dependencies in the obvious sense, but they're still dependencies, and running them in parallel produces race conditions or contradictory outputs rather than a speedup.

Cost and latency tradeoffs

Parallel execution reduces wall-clock latency but does not reduce total token spend — if anything it can increase it, since parallel subagents each carry their own context overhead rather than sharing one growing context. Voting-style parallelization is the clearest example: running the same task five times for consensus costs roughly five times the tokens of running it once, in exchange for higher confidence in the result. That tradeoff is worth it when the cost of a wrong answer is high and single-pass reliability is shaky; it's wasteful when a single well-prompted call is already reliable enough.

Sequential chains, by contrast, tend to be more token-efficient per subtask but pay for that in latency — the total time is the sum of every step, not the max of the slowest one.

Exam trap A scenario presents subtasks that appear independent on the surface (e.g., "have three subagents each update a shared summary document") and asks whether they should run in parallel. The trap is treating apparent task-independence as sufficient justification for parallelism when there's a shared, mutable resource underneath. The correct answer recognizes the write conflict and either sequences the updates or has a single agent own the merge step — independence of the task description is not the same as independence of the actual side effects.

Scenario: A code review agent needs to check a pull request for security issues, style violations, and performance regressions. These three checks read the same diff but write to entirely separate output sections and don't depend on each other's findings. This is a clean case for sectioning-style parallelization — dispatch three subagents at once, each scoped to one concern, and merge their independent outputs. Contrast this with a task where step two needs to know whether step one found any security issues before deciding whether to run at all — that dependency forces sequencing.

Rate limits and resource contention

Parallel execution is not free of constraints even when the tasks are logically independent. Firing off a large number of concurrent API calls can hit rate limits, and a system that fans out to, say, fifty parallel subagents for a task that only needed five may spend more time backing off from throttling than it saves in wall-clock latency. Practical parallel designs cap concurrency deliberately — batching parallel calls in groups, or bounding the number of simultaneous workers an orchestrator will dispatch at once — rather than assuming "independent" means "safe to run all at once with no limit."

The same caution applies to shared external resources beyond the model API itself: a database, a file system, or a third-party service with its own rate limits. Two subagents can be logically independent in terms of the data they read and write, yet still compete for the same underlying resource capacity, degrading each other's latency even without a correctness bug.

When sequential is simply safer

Beyond hard dependencies, there are cases where sequential execution is the pragmatic choice even without a strict data dependency: when subtasks are cheap enough that parallel infrastructure adds more complexity than it saves, when debugging a single linear trace is significantly easier than reconciling five concurrent traces, or when the task is exploratory and you expect to change your approach after seeing the first result. The exam frames this as a judgment call weighing latency savings against complexity and debuggability, not a rule that independent tasks must always be parallelized.

Exam trap A scenario shows subtasks that are independent and asks whether to parallelize, with "always parallelize independent tasks to save time" offered as a tempting general rule. Independence is necessary but not sufficient — rate limits, shared downstream resources, and the added complexity of reconciling concurrent results are all legitimate reasons to keep independent work sequential. The exam expects you to weigh the tradeoff rather than apply parallelization as a blanket default.

Try it

Take a multi-part task with at least one real dependency (for example: fetch data, then analyze it, then two independent summaries of the analysis for different audiences). Implement it with the dependent steps sequential and the two summaries dispatched in parallel via separate API calls fired concurrently. Time the parallel portion against running those same two summary calls sequentially to see the latency difference directly.