CrewAI Sequential vs Hierarchical Process Explained

The process parameter on a Crew looks like a small choice between two enum values. It is actually the biggest architectural decision in the framework, because it decides whether your control flow lives in your Python or inside a model's judgement.

This guide covers what each process does, the exact configuration each needs, what a manager costs in latency and tokens, and the failure mode people hit most often when they reach for hierarchical too early.

The processes documentation lists two values on the Process enum, sequential and hierarchical. Some third-party write-ups mention a third, consensual, which is not on the current page, so treat that as unconfirmed until you see it in your own version.

How does the sequential process work?

It executes your tasks in the order you defined them, and the output of one becomes context for the next. There is no coordinator deciding anything, which means the order you wrote is the order that runs, every time, for every input.

The properties that come with this are worth naming, because they are exactly what you give up later. It is deterministic in structure, cheap because there are no coordination calls, and trivially debuggable since the verbose trace matches the file you wrote.

Assign an agent to every task here. The documentation shows sequential examples with the agent named on each task, and being explicit costs you nothing while making the trace readable at a glance.

How does the hierarchical process work?

It puts a manager agent in front of your workers. The documentation describes it as organising tasks in a managerial hierarchy where work is delegated and executed through a chain of command, with the manager handling planning, delegation and validation of completion.

That manager has to come from somewhere, which is why the Crew requires one of two parameters. Pass manager_llm and the framework builds a manager for you with its own coordination prompts. Pass manager_agent and you supply the manager yourself.

Notice the task has no agent. That is the point of the mode: you are describing what needs to happen and letting the manager decide who should do it, based on the roles and goals you wrote for each worker.

It is also where the cost lives. Every manager decision is its own model call, on top of the calls the workers make, so the same work runs longer and consumes more tokens than the sequential version of it.

Do not forget to give the manager a model you chose. In a crew where every worker has an explicit llm, the manager is easy to overlook, and an unassigned manager falls back to the framework default rather than yours.

Which one should you pick?

Pick sequential unless the order of the work depends on what earlier steps discovered. If you can draw the pipeline on paper before running it, you do not need a manager, and paying a model to rediscover your own diagram on every run is a poor trade.

There is a middle path many people miss. A sequential crew can still branch if you put the branching in Python: run one crew, read the result, then choose which crew to run next. You keep the control flow where you can test it and pay for judgement only where you actually need judgement.

Before you commit to a manager, it is worth knowing what people report when hierarchical mode goes wrong. The pattern is consistent enough that it should shape how you write the manager rather than whether you use one.

What goes wrong with the manager, and how do you fix it?

The most-reported problem is over-delegation: the manager routes a request to every worker instead of only the relevant one. An independent analysis published on Towards Data Science walked through a support crew where a purely technical question was still sent to the billing specialist, whose answer then landed last and overwrote the correct one.

That write-up put numbers on it from their own setup. With an auto-created manager, a technical-only query took around 38 seconds and roughly 15,700 tokens. After replacing manager_llm with a custom manager_agent carrying explicit routing rules, the same query ran in around 24 seconds on roughly 10,000 tokens, with better output.

Those figures are one team's measurement on one crew with their own models, so treat them as a direction rather than a benchmark. The direction is the useful part: a manager you wrote yourself beats a manager the framework inferred.

Read that backstory again. It is not personality, it is a decision procedure: categorise, route, order, stop. The generic manager the framework creates has no way to know that billing should never touch an overheating laptop, because only you know your domain.

Whichever mode you choose, measure before you decide. Run the same ten inputs through both, print crew.usage_metrics each time, and compare tokens, wall clock and how often the answer was right. That comparison takes an hour and settles the argument permanently.

A decision procedure that holds up

1. Draw the pipeline first — If you can write the steps and their order on paper before running anything, build it sequential. You already have the plan a manager would be paid to produce.
2. Put branching in Python where you can — Run a crew, read the output, choose the next crew in your own code. Deterministic, testable, and free of coordination calls.
3. Reach for hierarchical when the route is genuinely unknown — Open-ended intake, tickets of mixed type, work where which specialist is needed depends on what the first look reveals.
4. Write the manager yourself — Pass manager_agent rather than manager_llm and give it explicit categorise-then-route rules, including when not to involve someone.
5. Give the manager its own model — The manager is an agent making real calls. Set its llm deliberately rather than letting it fall back to a framework default.
6. Benchmark both on the same inputs — Ten representative inputs, both modes, comparing usage_metrics and correctness. Decide with the numbers rather than the architecture diagram.

It is worth saying plainly what this decision is really about. Coordination is a genuine engineering problem, and the reason it is hard here is that you are building an org chart out of prompts and then paying per decision it makes.

If that orchestration layer is the thing you are building, this is the right problem to be deep in. If you just wanted the ticket answered, that is the case we designed Sistava around: you hire an AI Employee, tell it in plain English what to handle, and delegation and escalation come with the hire rather than being a process type you configure and tune.

For anyone staying with the framework, the useful summary is that sequential is a default and hierarchical is a decision. Sequential costs you nothing to try and tells you honestly whether your problem really needs judgement in the middle of it.

Frequently asked questions

The instinct to reach for a manager is understandable, because a hierarchy is how we organise human teams. Agents are not people though, and every layer of judgement you add is a layer that can be wrong in a way your own code would not be. Start flat, measure, and add coordination only where the measurement says you need it.

Sources

• CrewAI documentation, Processes
• CrewAI documentation, Crews
• CrewAI documentation, Tasks
• CrewAI documentation, Agents
• Towards Data Science, Why CrewAI's Manager-Worker Architecture Fails and How to Fix It