Who Decides What Your CrewAI Crew Does Next?

Sequential or hierarchical is the one switch that most changes how a CrewAI crew behaves, and flipping it without thinking can quietly triple your token bill.

In this article: You will learn the real difference between Process.sequential and Process.hierarchical in CrewAI, the validation requirement that catches almost everyone on their first hierarchical run, and the cost trade-off nobody mentions until the invoice arrives. By the end you will have a concrete rule for when each process is the honest choice.

A two-line change inside a Crew definition does not look like an architectural decision. You flip process=Process.sequential to process=Process.hierarchical, run it again, and expect a slightly smarter version of the same crew. What you get is a different machine: different execution path, different cost curve, and a validation error that stops some readers cold on the first run.

This is the one CrewAI knob most likely to surprise you. People reach for hierarchical because it sounds more advanced. Some discover the cost when their bill arrives. Others discover it when their crew refuses to start because a single required field is missing. The fix in both cases is the same: understand what the Process actually controls before you choose one.

So let us name the choice plainly. A Crew's process decides who chooses what happens next. Sequential means you decided at design time. Hierarchical means a manager LLM decides at runtime. Everything else, including the cost trade-off and the gotcha, follows from that single distinction.

The two processes, in one breath

Process.sequential runs your tasks in list order. The output of each task flows forward as context for the next, every task needs an agent assigned to it, and the whole thing is as predictable as the list you wrote. You are the planner; the crew just executes.

Process.hierarchical hands planning to a manager. You no longer pre-assign tasks to agents. Instead, a manager looks at the tasks and the available agents, delegates each piece to whoever fits, reviews the results, and validates that the work is done. The manager is either one that CrewAI builds for you from a manager_llm, or a custom manager_agent you define. You describe the team and the goals; the manager decides the choreography at runtime.

That is the whole distinction. One is a script you wrote; the other is a manager you hired.

Sequential: predictable and easy to debug

Sequential is the default for a reason. When something goes wrong, you know exactly where: task two got bad input from task one, or task three's expected_output was too vague. The execution path is the list. There is no surprise about who did what.

A minimal sequential crew reads like a recipe:

from crewai import Crew, Process

@crew
def crew(self) -> Crew:
    return Crew(
        agents=self.agents,
        tasks=self.tasks,
        process=Process.sequential,
        verbose=True,
    )

Each task's output feeds the next automatically. If you want to be explicit about which earlier outputs a task should see rather than relying on list order, you set the context parameter on the task to a list of the tasks it depends on. For a straight pipeline you rarely need to do so; for anything branchier, being explicit pays off.

The cost model is easy to reason about, too. You pay for each agent to do its task once, in order. There is no extra coordinating brain sitting on top, burning tokens to decide what comes next. For most crews, especially anything with a known shape, sequential is not a fallback. It is the right answer.

Hierarchical: a manager who delegates and reviews

Hierarchical earns its place when you genuinely do not know the path in advance. You have a pool of specialists and a goal, and you want something to decide at runtime which specialist handles which piece, possibly looping back when the work is not good enough. That "something" is the manager.

You can let CrewAI create the manager for you by naming a model:

from crewai import Crew, Process

crew = Crew(
    agents=[bug_investigator, fix_author, test_runner_specialist],
    tasks=[fix_the_bug],
    process=Process.hierarchical,
    manager_llm="gpt-4o",
    planning=True,
)

Notice what changed. The tasks are no longer each glued to an agent; the manager assigns them. The manager_llm names the model that does the managing. The planning=True flag asks the crew to draft a plan before executing, which pairs naturally with hierarchical work because the manager benefits from thinking through the approach before delegating.

When you want real control over how the manager behaves, define it yourself as a regular agent and pass it as manager_agent:

from crewai import Agent, Crew, Process

manager = Agent(
    role="Engineering Lead",  # ①
    goal="Get the failing test passing by delegating to the right specialist and reviewing their work",  # ②
    backstory=(
        "You run a small maintenance team. You assign work based on each "
        "engineer's strength, check what comes back, and send it back for "
        "another pass if it is not right."
    ),
    allow_delegation=True,  # ③
)

crew = Crew(
    agents=[bug_investigator, fix_author, test_runner_specialist],  # ④
    tasks=[fix_the_bug],
    manager_agent=manager,  # ⑤
    process=Process.hierarchical,  # ⑥
)

① The manager is an ordinary Agent, so its role frames how it presents itself when delegating. ② The goal is the manager's whole job description: delegate, review, and drive the work to a passing test. ③ allow_delegation=True is what lets this agent hand pieces of the work to the specialists below it. ④ The specialists go in the agents list; the manager is deliberately not among them. ⑤ Passing the agent as manager_agent is what installs it above the others as the coordinator. ⑥ Process.hierarchical is the switch that activates manager-driven delegation in the first place.

Note: The full extracted listing at code/crewai/part-3-sequential-vs-hierarchical/listings/01-custom-manager-crew.py shows the parts elided here.

A custom manager lets you shape the delegation style, the standards it holds work to, and the model it runs on. The model choice matters more than it sounds, because the manager is involved in every decision the crew makes.

The gotcha that stops first-time users

Hierarchical requires a manager. If you set process=Process.hierarchical and forget both manager_llm and manager_agent, the crew fails at validation when you call kickoff(). This is the single most common first encounter with hierarchical mode: people copy the process= line, run it, and hit the error. Set one of the two, always. And do not assign your custom manager into the agents list; it goes in manager_agent, and CrewAI slots it above the others.

The trade-off nobody mentions until the bill arrives

Here is the part that turns a casual switch into a real decision. The manager is not free. It is an extra LLM that reasons about every delegation, reads every result, and decides every next step, so a hierarchical crew makes substantially more model calls than the sequential version of the same work. The docs steer you toward capable models like GPT-4 for the manager precisely because a weak manager delegates badly and loops needlessly, and a strong one is expensive per call. Either way, you are paying for a coordinator that sequential simply does not have.

The trade is this. Sequential gives you predictability and a low, legible cost, at the price of having to know the workflow yourself. Hierarchical gives you runtime flexibility and genuine delegation, at the price of more tokens, a harder-to-trace execution path, and a dependency on the manager model's judgment. The mistake is reaching for hierarchical because it sounds more advanced. Most crews have a knowable shape, and for those, the manager is overhead you are paying for nothing.

A useful rule: stay sequential until you can name the specific decision you want made at runtime that you cannot make at design time. If you can name it, hierarchical is justified. If you cannot, you are about to pay a manager to read a list you already wrote.

A worked decision

Make it concrete. Consider a small bug-fixing crew: an investigator, a fix author, and a test runner. The work has a known shape. Find the bug, propose a fix, run the tests. That is a sequential pipeline, and forcing a manager onto it would add cost and a coordinating layer for a path we already know start to finish. Sequential is the honest choice.

The hierarchical version is worth picturing anyway, because it shows when you would switch. Imagine the crew grows. Now several kinds of failure exist, such as a logic bug, a flaky test, or a dependency mismatch, with a roster of specialists for each. You no longer know in advance which specialist a given failure needs. So you hand the crew a manager and a single goal, "get the suite passing," and let it diagnose the failure type, delegate to the right specialist, check the result, and loop if the tests still fail. That is a real runtime decision that you cannot make when you write the code, because it depends on which test is broken today. That is hierarchical earning its cost.

Do this today

• Audit any hierarchical crew you have today for whether you can name the specific runtime decision the manager is making. If you cannot, switch it to Process.sequential and reclaim those tokens.
• In every hierarchical crew, set either manager_llm or manager_agent immediately, never both empty. This is the validation error that catches first-time users.
• Pick the manager model deliberately. A weak manager delegates badly and loops needlessly. The docs recommend a capable model such as gpt-4o here, because the manager touches every decision.
• For a sequential crew that needs explicit task wiring, use the context parameter on each task to list the upstream tasks whose output should be visible, rather than relying purely on list order.
• If hierarchical is justified, pair it with planning=True so the manager drafts an approach before delegating, instead of inventing the choreography on the fly.

The one switch worth understanding

The Process choice looks like a line of configuration. It behaves like an architectural decision. Sequential is a script you wrote and can debug step by step. Hierarchical is a manager you hired who decides who does what next, at the price of an extra LLM in the loop.

Reach for hierarchical when you can name the runtime decision the manager is making. Stay sequential when you cannot. Most CrewAI work, especially anything with a knowable shape, belongs in the sequential column, and the surprise in your monthly bill is the lesson nobody wants to learn twice.

Pick the process for the shape of the work, not the sophistication of the word. The team you describe will run faster, cost less, and be easier to debug for it.

---

This is Part 3 of "Building with CrewAI," an eleven-part guide to building production-ready multi-agent systems with CrewAI.