CrewAI Process.sequential vs Process.hierarchical: a guide

The choice between crewai process.sequential vs process.hierarchical determines whether your multi-agent system runs as a fixed pipeline or a managed task board. Sequential crews execute tasks in a strict order, passing context forward; hierarchical crews inject a manager agent that dynamically delegates work to subordinates. Get this wrong and you either overpay for a manager that adds nothing or ship a brittle linear chain that can’t handle branching requirements.

Sequential: One Pass, Linear Dependency

Process.sequential is the default. You define a list of Task objects, and CrewAI runs them in the order they appear in the tasks argument. The output of task i is appended to the shared context for task i+1. There is no intermediary reasoning step that decides what to do—the control flow is your Python list.

This is ideal when the dependency graph is a straight line: research → draft → edit → publish. You know the shape of the work at author time.

from crewai import Crew, Process, Agent, Task

researcher = Agent(role="researcher", llm="openai/gpt-4o-mini")
writer = Agent(role="writer", llm="openai/gpt-4o-mini")

tasks = [
    Task(description="Collect facts on X", agent=researcher),
    Task(description="Write report using facts", agent=writer),
]

crew = Crew(
    agents=[researcher, writer],
    tasks=tasks,
    process=Process.sequential,
)
result = crew.kickoff()

The ergonomic win is obvious: the crew’s execution model is read directly off the task list. Debugging is a matter of inspecting each task’s output after a run.

Hierarchical: Manager-Agent Fan-Out

Process.hierarchical replaces the linear loop with a manager agent. You must pass manager_llm (or a full manager_agent). The manager receives the full task list and decides which worker agent should handle which task, in what order, and whether to re-assign on failure. It is closer to a runtime scheduler than a static pipeline.

from crewai import Crew, Process, Agent, Task

researcher = Agent(role="researcher", llm="openai/gpt-4o-mini")
writer = Agent(role="writer", llm="openai/gpt-4o-mini")

tasks = [
    Task(description="Investigate topic X"),
    Task(description="Produce final article"),
]

crew = Crew(
    agents=[researcher, writer],
    tasks=tasks,
    process=Process.hierarchical,
    manager_llm="openai/gpt-4o",
)
result = crew.kickoff()

Note that tasks no longer need an explicit agent binding—the manager makes that call. This buys flexibility: if the manager judges the writer underqualified for a subtask, it can route to the researcher first. But you’ve introduced a non-deterministic control plane that itself consumes tokens and latency.

Cost Model and Token Accounting

Sequential crews incur token cost equal to the sum of system prompts, task prompts, and outputs across the chain. There is no hidden overhead. If a task fails and you retry, you pay for the retry only.

Hierarchical crews add the manager’s system prompt on every delegation cycle, plus the manager’s reasoning output (often a JSON or natural-language plan) and its evaluation of worker results. In practice, expect 1.5–3× the LLM calls of an equivalent sequential crew, because the manager re-reads context before each assignment. If you front your agent traffic with n4n.ai, its per-token usage metering makes this overhead visible down to the manager call—and its forwarding of provider cache-control hints can trim repeat manager prompts if you mark them cacheable.

Neither process changes the underlying model pricing; the difference is purely architectural multiplier.

Latency and Throughput

Sequential latency is the critical-path sum: T1 + T2 + ... + Tn plus crew overhead. It is predictable and shrinks when you swap in faster models.

Hierarchical latency is Σ(manager_think + worker_exec) with serialization between steps—the manager rarely parallelizes worker calls in current CrewAI releases. You also inherit manager timeout risk: a vague task description can send the manager into a re-plan loop. Throughput suffers accordingly. If a provider rate-limits the manager mid-loop, the whole crew blocks; an inference gateway with automatic fallback when a provider is degraded (such as n4n.ai’s single OpenAI-compatible endpoint) can mask that stall, but the fan-out still amplifies total request count.

Ergonomics and Code Structure

Sequential is declarative and boring in the best way. The tasks list is the spec. New engineers read the crew and understand execution instantly.

Hierarchical demands more upfront design: you must choose a manager model capable of planning, write tasks without hard-coded agent assignment, and accept that the run log will contain manager monologues. Tooling like LangSmith or simple stdout logging becomes mandatory because a failure may be in the manager’s routing, not the worker.

# Sequential: agent bound at task level
Task(description="Write section", agent=writer)

# Hierarchical: agent omitted, manager decides
Task(description="Write section")  # manager picks writer or researcher

The second form is cleaner if your agent roster changes at runtime, but it hides intent from the code reviewer.

Ecosystem and Tooling

Both processes share CrewAI’s agent, task, and tool primitives. Any Agent with tools=[] works in either. The hierarchical path, however, requires the manager LLM to support function-calling or structured output reliably; weak models produce malformed delegation and the crew errors out. The ecosystem of examples leans sequential—most published recipes avoid the manager tax unless the problem is genuinely open-ended.

Limits and Failure Modes

Sequential fails loudly when a later task needs something earlier task didn’t produce. Because there’s no replanner, you get a truncated output or an exception. The fix is code change.

Hierarchical fails silently or loops: the manager may decide a task is “done” prematurely, or repeatedly reassign the same task hoping for a better result. Rate limits hit harder because of call multiplication. There is also a subtle limit—CrewAI’s hierarchical manager does not currently enforce global task dependencies beyond its own reasoning, so complex DAGs can be mis-scheduled.

Head-to-Head Comparison

Which to Choose

Use Process.sequential when:

• Your workflow is a known sequence (extract → transform → load, draft → review → ship).
• Token budget is tight and you can’t justify a planner model.
• You need deterministic runs for regression testing or compliance.
• Your team is small and wants the crew logic visible in the task list.

Use Process.hierarchical when:

• Tasks are interdependent but the order isn’t known until inputs are seen (e.g., triage incoming tickets, then assign to specialist agents).
• You have a robust manager model (GPT-4-class or better) and can eat the extra latency.
• The agent roster is dynamic or you want runtime load-balancing across workers.
• You’re prototyping an org-like system where a “lead” agent improves output quality by overseeing subordinates.

For most production pipelines that aren’t research demos, crewai process.sequential vs process.hierarchical resolves to sequential by default—add the manager only when the linearity of your problem breaks. The hierarchical tax is real, but for genuinely open-ended multi-agent coordination it’s the only built-in option that doesn’t force you to hand-roll a scheduler.