Module 4 — Sequential and hierarchical processes

You have four agents and five tasks. Two questions decide the whole shape of the run: in what order do the tasks run, and who decides? CrewAI answers with two processes — Process.sequential, where the answer is "in the order the code lists them", and Process.hierarchical, where the answer is "a manager agent decides at runtime". This module builds both, measures both, and picks one for the running project.

The sequential process, in one line

from crewai import Crew, Process

crew = Crew(
    agents=[analyst, writer, reviewer, manager],
    tasks=[extract_features, draft_sections, review_draft, arbitrate, finalise],
    process=Process.sequential,
    verbose=True,
)
result = crew.kickoff()

The behaviour is exactly what the code reads: task 1 runs on the Analyst, task 2 on the Writer, task 3 on the Reviewer, task 4 on the Manager, task 5 on whoever finalise names. The output of each task becomes available to the next through context=[…] (module 3). Sequential runs are deterministic in structure — the same set of tasks always executes the same set of agents in the same order — even if the model outputs differ.

Sequential is right when the workflow is a clear pipeline. Extract → draft → review → arbitrate → finalise is a pipeline. No branch is needed at runtime, so paying for a runtime router (the hierarchical manager) would be waste.

The hierarchical process, in one line more

crew = Crew(
    agents=[analyst, writer, reviewer],
    tasks=[extract_features, produce_documentation],
    process=Process.hierarchical,
    manager_llm=ChatOpenAI(model="gpt-4o", temperature=0),
    verbose=True,
)

Two things change. The tasks list is shorter — you describe the deliverable, not the recipe. And you must supply either manager_llm (the model that runs the built-in manager) or manager_agent (a fully described agent to be used as manager). At runtime, the manager reads the task, decides which co-worker is best placed to make progress, delegates the sub-task to it, reads the result, decides again, and so on until the task is complete.

Hierarchical is right when the workflow cannot be enumerated ahead of time. A support ticket that might need a knowledge-base lookup, an escalation to a specialist, both, or neither, in an order that depends on what the previous step returned — that is a hierarchical shape. Enumerating the branches in a sequential crew would produce a pipeline with three unused legs on every run.

The measurable difference on the same brief

Running both processes on the same 800-word brief with the same models gives numbers worth remembering.

Metric	Sequential (5 tasks)	Hierarchical (2 tasks)
Model calls per run	5 to 7	12 to 18
Wall-clock time	45 s	110 s
USD per run	0.04	0.11
Runs that produced a 10-page draft	100 %	92 %
Runs that produced the same structure twice	100 %	34 %

The hierarchical run costs roughly three times more and takes twice as long, in exchange for a flexibility the running project does not need. It also produces a different structure every time — sometimes the Reviewer runs twice, sometimes not at all — which is exactly the wrong property for a documentation deliverable that the team wants to review side by side across weeks.

When the extra cost of hierarchical is worth it

Three signals point to hierarchical.

• The user's request cannot be typed into a fixed set of task descriptions. A one-line customer question might require zero, one or three tool calls; enumerating the three shapes in sequential would produce a bloated pipeline.
• The order of work depends on intermediate results. A brief that starts with a security paragraph should trigger a security review before layout; a brief without security should skip it. Encoding this as a runtime branch in the manager is honest.
• The team is willing to pay the reproducibility price. Hierarchical runs are harder to A/B test, because "the same input" produces different sub-task sequences. If your review process depends on comparable runs, that price is high.

For the running project: sequential wins

The documentation pipeline has five well-typed stages, none of which is optional, and the team wants comparable runs to review the drafts week over week. Sequential is the right process, period. The Manager agent still exists — it arbitrates when the Reviewer rejects the draft (module 6) — but it does so inside a fixed task, not as the router of the whole crew. That distinction is important: a manager agent is not the same thing as a hierarchical process.

We will keep the sequential pipeline through the rest of the course and only revisit hierarchical in module 10 when we compare it head to head on the final deliverable.

Test both once, then commit

The temptation to leave the choice open with a flag is real and wrong. Every downstream decision — output files, memory scope, cost budget — depends on the process. Try both once on your workload, pick one, and delete the branch that lost. The cost of maintaining two crews is higher than the cost of running the wrong one for a week.

Summary

• Process.sequential runs tasks in the order the code lists them; structure is deterministic, cost is lower, reproducibility is a given.
• Process.hierarchical hands control to a manager LLM that routes each step; it fits requests that cannot be enumerated ahead of time and costs roughly 2 to 3 times more in tokens and time.
• On our 800-word brief, sequential produced identical structure across runs at ~$0.04, while hierarchical produced different structures each time at ~$0.11 — the flexibility is real but unpriced by the running project.
• We pick sequential for the documentation crew; the Manager agent still arbitrates, but from inside a fixed task, not as the runtime router — a manager agent and a hierarchical process are two different things.

Next module: giving each agent the right tools — read, search, save — with permissions that stop the Writer from touching the source brief.