In CrewAI, what changes when a Crew runs Process.hierarchical instead of Process.sequential?

## The Crew object In CrewAI a `Crew` is the unit you actually execute. You construct it with a list of `agents`, a list of `tasks`, and a `process`, plus optional switches such as `verbose`, `memory`, `planning`, `max_rpm` and `cache`. Calling `crew.kickoff()` runs the whole thing and returns a `CrewOutput`. The `process` argument is the single biggest behavioural lever on that object, because it decides *who chooses what happens next*. ## Process.sequential `Process.sequential` is the default and the simplest model. The runtime iterates the `tasks` list in declaration order. Each task is executed by the agent bound to it, and the output of preceding work is passed forward as context, so a later task can build on an earlier one (you can override what a task sees by setting its explicit context). When the last task finishes, its output becomes the crew's headline result. Properties worth stating in an interview: - **Deterministic ordering.** The list *is* the plan. Reading the code tells you the execution order. - **Predictable cost.** Total tokens are roughly the sum of each agent's own loop; there is no coordinator overhead. - **Every task needs an agent.** Ordering is yours to get right; nothing re-plans if a task's output is poor. - **Sequential means sequential.** It is not parallelism. Fan-out inside a sequential crew comes from marking individual tasks async, not from the process itself. ## Process.hierarchical `Process.hierarchical` introduces a manager. Because that manager needs a brain, CrewAI validates at construction time that you supplied either `manager_llm` (a model identifier or LLM object, from which CrewAI creates a default manager agent) or `manager_agent` (an `Agent` you wrote yourself). Constructing a hierarchical crew with neither fails. At run time the manager, not the list, drives the work. It receives the task, selects a coworker from the crew's `agents`, and uses the delegation tools CrewAI attaches to it to hand work over or to ask a coworker a question. The worker runs its own loop, returns a result, and the manager evaluates it before continuing. Tasks in a hierarchical crew therefore do not have to name an agent — assignment is the manager's job. What this buys you: - **Dynamic routing.** The right specialist can be chosen from the task text rather than hard-wired. - **A review step.** The manager can reject weak output and re-delegate, which sequential mode never does on its own. - **A single point of coordination** for crews where you genuinely cannot precompute the order. What it costs you: - **Extra LLM calls per task** — at minimum a delegation decision and a review, often more when the manager asks clarifying questions. On a four-task crew this can double the run's token bill. - **Latency**, because manager turns are serialized in front of and behind every worker turn. - **Nondeterminism.** Two runs of the same inputs can route differently, which makes reproducing a bug harder and makes evaluation noisier. - **A new failure mode**: the manager mis-delegates, loops on the same coworker, or accepts an answer the specialist hedged. ## Choosing between them The honest default is sequential. Most production CrewAI crews are a pipeline — research, then analyse, then write — and a pipeline expressed as an ordered list is cheaper, faster, easier to test and easier to debug than the same pipeline expressed as a manager's improvisation. Reach for hierarchical when the assignment genuinely depends on content the code cannot see ahead of time, or when you want an explicit review gate in the loop and are willing to pay for it. A useful framing for an interviewer: *sequential puts the plan in your code; hierarchical puts the plan in a prompt.* Anything in a prompt is subject to model drift, prompt injection through retrieved content, and token cost that scales with how chatty the manager is. ## Debugging each With sequential, a bad result localises to one task: read that task's output and its context. With hierarchical, you first have to establish *which agent actually did the work* — turn on `verbose`, write a run log with `output_log_file`, and inspect `CrewOutput.tasks_output` and `CrewOutput.token_usage`. A manager that spends most of the budget talking to itself is a common and easily missed symptom. ## Version note This describes the CrewAI 0.x `Crew`/`Process` API. The `Process` enum's supported members in practice are `sequential` and `hierarchical`; do not promise consensus-style processes in an interview.