Picking the wrong topology for a multi-agent system will quietly bankrupt your API budget or leave you staring at a timeout at 2 a.m. The decision between sequential vs parallel multi-agent workflows determines whether agents share context through a tight chain or operate as independent workers that converge later. Get it wrong and you either serialize work that could be concurrent or create race conditions that no single log can explain.
Capabilities
Sequential pipelines
A sequential workflow chains agents so that the output of step N is the only input to step N+1. This forces a deterministic order and makes it trivial to insert a validator or a human checkpoint between stages.
from openai import OpenAI
client = OpenAI()
def sequential_extract_summarize(topic):
facts = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role":"user","content":f"List verified facts about {topic}"}]
).choices[0].message.content
summary = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role":"user","content":f"Compress to 3 bullets: {facts}"}]
).choices[0].message.content
return summary
Parallel fan-out
Parallel workflows launch multiple agents against the same or different inputs and reconcile their outputs in a reducer. Dependencies are explicit only at the merge boundary.
import asyncio
from openai import AsyncOpenAI
aclient = AsyncOpenAI()
async def parallel_ask(queries):
async def one(q):
return await aclient.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role":"user","content":q}]
).choices[0].message.content
return await asyncio.gather(*(one(q) for q in queries))
Sequential excels at multi-stage reasoning where each stage narrows the problem. Parallel excels at breadth-first collection: scraping N sources, classifying M tickets, or generating diverse candidates for later ranking.
Price and cost model
Sequential steps usually retransmit prior context. If agent A produces 2k tokens and agent B consumes them, you pay input tokens for that 2k again plus B’s system prompt. Over a 5-stage chain, prompt prefix duplication can dominate spend.
Parallel calls isolate context. Each worker carries only its own prompt and input. A reducer may need to ingest all outputs, but you avoid per-stage prefix tax.
If you route through an OpenAI-compatible gateway such as n4n.ai, per-token metering applies uniformly, and provider cache-control hints can be forwarded to avoid recomputing shared system prefixes across sequential steps. That turns a repeated 1k-token system prompt into a cached read after the first call.
Parallel can still cost more in absolute requests because you fire N completions instead of one chained call, but each is smaller. Budget sequentially when context reuse is unavoidable; budget parallel when tasks are independent and you can keep prompts lean.
Latency and throughput
Sequential latency is the arithmetic sum of each agent’s time-to-first-token plus network round trips. A three-agent chain at 1.5s each is ~4.5s minimum, ignoring retries.
Parallel latency is the slowest worker plus reducer time. Same three agents run in ~1.5s. Throughput scales with your concurrency limit, not chain depth.
Reality check: most providers rate-limit by requests per minute. A parallel fan-out of 50 agents can trip 429s instantly. You need backoff or a gateway that performs automatic fallback when a provider is degraded. Sequential is self-throttling by nature.
Ergonomics and debugging
Sequential code reads top-to-bottom. A failure in stage two is a stack trace with a clear line number. You can print intermediate artifacts to a file and inspect the exact handoff.
Parallel demands correlation IDs, async tracing, and a merge function that handles missing results. A silent timeout in one of eight workers produces a partial reducer input that may pass unit tests but corrupts production.
# minimal correlation
import uuid
async def traced_one(q):
cid = uuid.uuid4().hex[:8]
try:
return await one(q)
except Exception as e:
return {"cid": cid, "error": str(e)}
If your team is small and on-call is you, sequential reduces cognitive load. If you already run async services, parallel is just another queue.
Ecosystem and tooling
Sequential patterns are native to LangGraph, Temporal, and even bash pipes. You can wrap each agent in a container and call it via HTTP.
Parallel needs an event loop or distributed queue. Ray, Celery, or asyncio manage the fan-out. Observability tools like OpenTelemetry span aggregation become mandatory at scale.
Both topologies work with any OpenAI-compatible endpoint. The gateway you choose should honor client routing directives so you can pin a sequential chain to a single provider for reproducibility while letting parallel workers spread across models.
Limits and failure modes
Sequential suffers head-of-line blocking. One slow provider stalls the entire pipeline. A malformed output at stage one propagates and may cause cascading parse errors.
Parallel suffers partial failure. If three of ten workers fail, your reducer must decide whether to proceed with seven or fail the batch. Without idempotent design, retrying the whole fan-out wastes tokens.
Rate limits are the universal ceiling. Sequential hits them slowly; parallel hits them fast.
Head-to-head summary
| Dimension | Sequential | Parallel |
|---|---|---|
| Capabilities | Strict dependency chain, inline validation | Independent fan-out, reducer reconciliation |
| Cost model | Token amplification from context reuse | Isolated prompts, lower redundant prefix cost |
| Latency | Sum of step times | Max of worker times + reduce |
| Throughput | Limited by chain depth | Limited by concurrency quota |
| Ergonomics | Linear code, easy debug | Async traces, correlation IDs |
| Ecosystem | LangGraph, pipes, simple scripts | Ray, Celery, asyncio, queues |
| Limits | Cascading failure, head-of-line block | Partial failure, rate-limit spikes |
The table above contrasts sequential vs parallel multi-agent workflows directly across the dimensions that matter in production.
Which to choose
Use sequential when
- Agents have hard data dependencies (extract → validate → format).
- You need a human approval gate between steps.
- Debugging time costs more than compute; you want line-number clarity.
- Your volume is low and provider rate limits are tight.
Use parallel when
- Subtasks are independent: bulk classification, multi-source retrieval, candidate generation.
- End-to-end latency SLAs are aggressive (sub-3s with many agents).
- You already operate async infra and can handle partial results.
- You can design a reducer that degrades gracefully.
Hybrid patterns
A coordinator agent plans a task, then spawns parallel workers for independent branches, then sequentially verifies their merged output. This is the most common production shape: parallel for breadth, sequential for correctness.
Pick the topology that matches your dependency graph, not your framework’s demo. Sequential vs parallel multi-agent workflows is a trade between determinism and speed; most systems need both at different layers.