Choosing between crewai sequential vs hierarchical process changes how your multi-agent system spends tokens, fails, and scales. This piece compares both process types across the dimensions that matter when you ship.
How CrewAI processes actually work
In CrewAI, a Crew executes a list of Task objects under a Process. The two built-in process types are sequential and hierarchical. They are not interchangeable wrappers; they change control flow.
Sequential process
With Process.sequential, tasks run in the order they are added to the crew. Each task is bound to a specific Agent. The output of task i is fed to task i+1 if the downstream task expects a context. There is no intermediary that decides what to do next.
from crewai import Agent, Task, Crew, Process
researcher = Agent(role="researcher", goal="find facts", llm="gpt-4o-mini")
writer = Agent(role="writer", goal="draft post", llm="gpt-4o-mini")
task1 = Task(description="Collect stats on EV sales", agent=researcher)
task2 = Task(description="Write a blog from context", agent=writer)
crew = Crew(
agents=[researcher, writer],
tasks=[task1, task2],
process=Process.sequential,
)
result = crew.kickoff()The execution is a straight line. If task1 fails, the crew stops.
Hierarchical process
With Process.hierarchical, you designate a manager_llm. CrewAI spins up a manager agent that receives the full task list and decides which crew member should handle each step. The manager can re-plan, skip, or repeat tasks based on intermediate results.
crew = Crew(
agents=[researcher, writer],
tasks=[task1, task2],
process=Process.hierarchical,
manager_llm="gpt-4o",
)You do not assign agent on each Task when using hierarchical—the manager does. If you do, they are treated as capabilities available to the manager, not fixed bindings.
Head-to-head dimensions
Capabilities
Sequential crews encode a fixed DAG of depth one: a chain. They support explicit context passing and async execution per task, but cannot alter order at runtime. If your workflow is “scrape → summarize → post”, that is a perfect fit.
Hierarchical crews provide dynamic task selection. The manager LLM reads task descriptions and agent roles, then emits a delegation. This unlocks conditional branching (“if sentiment is negative, run mitigation task”) without hard-coding it. It also enables self-correction: the manager can see a weak output and re-assign.
Price/cost model
Sequential cost is the sum of prompt + completion tokens for each task, plus any tool calls. It is predictable. You can estimate a ceiling before run.
Hierarchical adds the manager’s reasoning tokens on top of every step. The manager typically uses a stronger model (e.g., gpt-4o vs gpt-4o-mini for workers) because delegation requires reliable function calling. Each delegation cycle is at least one extra LLM round trip. In loose specs, the manager may loop. When backing these agents with an OpenRouter-class gateway like n4n.ai, per-token usage metering exposes the delegation overhead so you can spot runaway manager spins.
Latency/throughput
When evaluating crewai sequential vs hierarchical process for latency, the control plane matters. Sequential latency is Σ(task_latency). No extra control plane. Throughput is bounded by the slowest task and your concurrency settings.
Hierarchical latency includes manager think time before every worker call. For a 5-task crew, expect 5+ manager round trips. The manager may also serialize tasks that could have been parallel in sequential if you had split them. Real-world effect: hierarchical feels slower per task even if it saves steps in complex flows.
Ergonomics
Sequential is declarative and debuggable. You read the task list top-down and know exactly what ran. Logs map 1:1 to code.
Hierarchical hides control flow inside the manager’s prompt. You must inspect the manager’s emitted tool calls to understand why task2 ran before task1. Tuning requires editing the manager system prompt or swapping manager_llm. For new engineers, hierarchical feels magical until it isn’t.
Ecosystem
Both share CrewAI’s tool ecosystem, memory, and callbacks. Hierarchical imposes an extra constraint: the manager_llm must support structured outputs or function calling well. Weak models produce malformed delegation JSON and crash the crew. Sequential works with any chat model.
Limits
Sequential breaks when the order is data-dependent. It also has no built-in retry across tasks; a bad intermediate output poisons downstream tasks.
Hierarchical is bounded by manager quality and max iterations. If the manager loops (common with vague tasks), you hit timeout or token caps. It is also non-deterministic across runs unless you pin temperature to 0 and the model behaves.
Comparison table
| Dimension | Sequential | Hierarchical |
|---|---|---|
| Capabilities | Fixed order, explicit context passing | Dynamic delegation, conditional branching, self-correction |
| Cost model | Predictable sum of task tokens | Task tokens + manager reasoning tokens per step |
| Latency | Linear sum of task times | Linear + manager round trip per step |
| Ergonomics | Readable, 1:1 with code | Opaque control flow, prompt tuning needed |
| Ecosystem | Any chat model | Requires function-calling capable manager_llm |
| Limits | Brittle to order changes, no cross-task retry | Manager loops, non-determinism, model dependency |
Code-level differences that bite
When you switch a crew from sequential to hierarchical, remove agent= from tasks or the framework will warn. The manager expects to assign. Also, verbose=True is mandatory in hierarchical during dev—the manager’s delegation trace is your only visibility.
# Sequential: agent bound
task = Task(description="...", agent=researcher)
# Hierarchical: no agent, manager picks
task = Task(description="...")Another gotcha: hierarchical crews ignore task.context if you manually set it; the manager builds context from prior outputs it selected.
Which to choose
The crewai sequential vs hierarchical process trade-off is ultimately about determinism versus adaptive planning. Verdict by use case:
Use sequential when:
- The pipeline is a known sequence (ETL with LLM steps, doc generation from fixed inputs).
- You need reproducible outputs and audit trails.
- Cost per run is tracked to a strict budget.
- You are on a weak or cheap model that cannot reliably delegate.
Use hierarchical when:
- Task order depends on runtime data (e.g., “investigate alert, then decide remediation”).
- You are prototyping and do not want to hard-code orchestration.
- The problem benefits from a planner (multi-step research, open-ended coding).
- You can afford a stronger manager model and accept variance.
For most production systems I ship, I start with sequential and refactor to hierarchical only when the conditional logic grows ugly. The token tax is real, but the flexibility saves code. If you route both through a gateway that meters per token and supports fallback, the hierarchical overhead becomes a measurable line item rather than a surprise.
Pick sequential for determinism, hierarchical for ambiguity.