Parallel vs. sequential agents: when to use each

Quick answer

Run agents in parallel when their work is independent — each agent has what it needs to start, and neither needs the other's output to do its job. Run agents sequentially when there's a data dependency — one agent needs another's output as its primary input before it can begin. The pipeline structure follows from the dependencies in your workflow, not from a stylistic choice about speed or simplicity.

What parallel execution means

In a multi-agent system, parallel execution means two or more agents start at the same time and run concurrently. Neither is waiting for the other. Their outputs are independent, and a coordinator or downstream step will combine them when both are done.

The primary reason to run agents in parallel is speed. If you have three research agents each covering a different domain, and none of them needs the others' findings to do their work, running them one after another triples your elapsed time for no reason. Running them concurrently means all three complete in roughly the time the slowest one takes.

Parallel execution also models how real teams work. A sales team running account research doesn't have the CRM analyst wait for the LinkedIn researcher to finish before starting. Both work at the same time. The account executive reviews the combined brief.

In the Envelope schema, parallel execution is the default. Agents that do not declare a dependsOn relationship with another step will run as soon as the workflow starts and their direct inputs are available. No configuration is required to enable parallelism — you opt into sequencing, not out of it.

The coordination overhead is real but manageable. A coordinator agent needs to handle the case where parallel agents complete at different times, produce conflicting outputs, or one fails while the other succeeds. These edge cases need to be designed for — not assumed away.

What sequential execution means

Sequential execution means an agent waits for another step to complete before it starts. It has a data dependency: it needs the upstream agent's output as its input.

This is not a fallback for when you can't figure out how to parallelize. For many workflows, sequencing is the correct design — because the downstream agent genuinely cannot do useful work without the upstream output.

A classifier that routes a support ticket must see the ticket before it can classify it. A drafter that writes a customer response must see the research brief before it can write. A reviewer that checks an output for quality must have the output before it can review it. These are sequential by nature, not by preference.

In the Envelope schema, sequential dependencies are expressed with dependsOn. An agent that declares dependsOn: ["research-step"] will not start until the research-step is marked complete and its output is available in the context. This is deterministic: the ordering is enforced by the runtime, not left to timing.

Sequential pipelines are more predictable and easier to debug. If something goes wrong in step three, you know step two completed successfully. The execution trace is a chain, not a web.

The cost is time. A five-step sequential pipeline takes at least five times the latency of a single step. For workflows that are latency-sensitive — real-time responses, customer-facing actions — sequential pipelines can be too slow unless each step is genuinely required.

Decision criteria: when to use each

The right question is not "do I want this to be fast?" — it's "does this agent need what the other one produces?" There's also a prior question worth asking before settling on parallel or sequential: do you need multiple agents at all? One AI agent vs. many covers that decision first.

Use parallel execution when:

• Each agent has all the inputs it needs to start immediately
• The agents' outputs are independent — neither depends on the other's result
• The outputs will be combined or reviewed after all agents complete
• Coordination overhead (handling concurrent completions, partial failures) is manageable

Use sequential execution (dependsOn) when:

• Agent B needs Agent A's output as its primary input
• Running Agent B before Agent A would produce no useful result, or a wrong one
• The ordering is structural — it reflects the logic of the task, not just a preference
• You need a clear execution trace for auditing or debugging

Watch for these common mistakes:

False sequencing — making agents wait for each other when they don't need to, usually out of caution or habit. This adds latency without adding correctness. If Agent B only uses Agent A's output as optional context rather than required input, it may not need a hard dependency.

False parallelism — running agents concurrently when one actually needs the other's output. This produces errors or silent quality degradation: Agent B starts with incomplete inputs, produces a flawed result, and the pipeline completes successfully without flagging the problem.

Over-parallelism — running so many agents concurrently that the coordinator handling their outputs becomes a bottleneck. Parallelism shifts the constraint from the agents to the aggregation step. If the coordinator has to reconcile outputs from twelve concurrent agents, the coordination cost can exceed the savings from running them in parallel.

Worked example: the same workflow, two designs

A content repurposing workflow takes a long-form article and produces three outputs: a LinkedIn post, a Twitter/X thread, and a newsletter summary.

Design A — sequential:

1. Extractor  →  pulls the key points from the article
2. LinkedIn Writer  (dependsOn: Extractor)
3. Twitter Writer   (dependsOn: LinkedIn Writer)
4. Newsletter Writer (dependsOn: Twitter Writer)
5. Editor  (dependsOn: Newsletter Writer)

All three writers run one after another. Total time: Extractor + LinkedIn + Twitter + Newsletter + Editor.

This works, but the sequencing between the three writers is false. Twitter Writer doesn't need LinkedIn Writer's output — it's using the Extractor's output, the same as LinkedIn Writer. The chain between writers is an artefact of building the pipeline step by step, not a real dependency.

Design B — parallel writers:

1. Extractor
2a. LinkedIn Writer  (dependsOn: Extractor)
2b. Twitter Writer   (dependsOn: Extractor)
2c. Newsletter Writer (dependsOn: Extractor)
3. Editor  (dependsOn: 2a, 2b, 2c)

All three writers start as soon as the Extractor finishes. The Editor waits for all three to complete, then reviews them together. Total time: Extractor + max(LinkedIn, Twitter, Newsletter) + Editor.

On a typical run, Design B is 30–50% faster with identical output quality. The Editor step actually benefits from reviewing all three outputs together — it can check consistency across formats, which Design A's Editor couldn't do because it reviewed them sequentially without the full set.

The real dependency structure was always: Extractor → Writers → Editor. The parallelism between writers wasn't an optimisation added later; it was the correct design from the start, once the dependencies were mapped accurately.

For more on how dependsOn and reportsTo work together at the agent level, see sub-agent design: the five components every agent needs.

Where Envelope fits

Envelope's workspace maps the dependency structure of your workflow visually as you design. Agents without declared dependencies appear as concurrent branches; agents with dependsOn relationships appear as sequential steps. The structure you see is the structure the runtime will execute.

When you export your design as a .envelope.json file, the dependsOn fields encode exactly which agents wait for which — so the runtime doesn't have to infer execution order from anything other than the spec. The pipeline is explicit, not implicit.

For a broader introduction to how agents in a multi-agent system are structured — roles, models, tools, and reporting lines — see the anatomy of a multi-agent.

Design your AI agents in Envelope

Envelope turns a plain-language description of your workflow into a complete AI agent system — agents with named roles, model assignments, tool access, handoffs, and human review gates. Free to start, no code required.

Start designing →

Frequently asked questions

When should agents run in parallel vs. in sequence?

Run agents in parallel when their work is independent — neither needs the other's output to do its job. Use sequential execution (dependsOn) when one agent genuinely needs another's output as its primary input before it can begin. The decision is determined by the data dependencies in your workflow, not by preference for speed or simplicity.

What is a dependsOn relationship in a multi-agent pipeline?

A dependsOn declaration tells the runtime: do not start this agent until the named step has completed and its output is available. It creates a hard sequencing constraint. Without it, agents run concurrently by default. dependsOn is the mechanism for sequential pipelines in the Envelope schema.

Does running agents in parallel always make things faster?

Usually yes, when the parallelism is genuine — the agents have independent inputs and outputs. But parallel execution shifts the constraint to the aggregation step: the coordinator that combines outputs from concurrent agents. If that step is expensive, or if too many concurrent agents create coordination overhead, the speed benefit shrinks. Map the actual bottleneck before assuming parallelism solves it.

What happens if one agent in a parallel group fails?

That depends on how the coordinator or pipeline is designed to handle partial completion. A common pattern is: if any parallel agent fails, hold the dependent downstream step and surface the failure for review — rather than proceeding with incomplete inputs. This is a gate pattern. How your pipeline handles partial failures is a design decision, not a runtime default — it should be specified when you design the system.

Can an agent have dependencies on multiple upstream steps?

Yes. An agent can declare dependsOn: ["step-a", "step-b"], which means it waits for both to complete before starting. This is how the aggregation step works in a parallel group — the Editor in the worked example above waits for all three writers before it starts reviewing. Multiple dependencies compose cleanly.

What is "false sequencing" and why does it matter?

False sequencing is when you put agents in a sequential chain even though there is no real data dependency between them — usually because you built the pipeline step by step without mapping dependencies first. It adds latency without adding correctness. Auditing your pipeline for false sequencing — asking "does this step actually need the previous step's output?" — is one of the fastest ways to reduce pipeline run time.

How do I visualise the execution order of my pipeline before building it?

Draw it as a directed graph first: each agent is a node, each dependsOn relationship is a directed edge. Agents with no incoming edges run immediately (or concurrently). Agents with incoming edges wait. The critical path — the longest chain of sequential dependencies — is your minimum possible elapsed time. Anything off the critical path is a candidate for parallelism.

Does Envelope enforce execution order automatically?

Yes. When you export a spec with dependsOn fields, any conforming runtime reads those fields and enforces the order — agents on the critical path run in sequence, agents without dependencies run concurrently. You don't configure execution logic separately from the spec; the spec is the execution logic.