What must you configure on a CrewAI Crew before Process.hierarchical will run?
answer
- hierarchical needs a boss
- two spellings, pick one
- not one of the workers
- routing quality follows manager model
- construction fails, no silent fallback
basics
~20 sA hierarchical CrewAI crew needs a manager: either manager_llm, from which CrewAI builds a default manager agent, or manager_agent, your own Agent. Supplying neither fails validation, and the manager agent must not also appear in the crew's agents list.
solid answer
~50 s`Process.hierarchical` requires a coordinator, so CrewAI validates that exactly one of two knobs is present. `manager_llm` gives CrewAI a model and lets it construct a default manager agent for you — the fastest path, and fine when you only need generic coordination. `manager_agent` lets you pass an `Agent` you wrote, so you control its role, goal, backstory and LLM; use it when the delegation prompt itself needs domain framing, for example a manager that knows a compliance step must always run last. Either way CrewAI equips the manager with delegation capability so it can hand work to coworkers and ask them questions. Two rules bite in practice: constructing a hierarchical crew with neither field set raises a validation error rather than silently degrading to sequential, and your `manager_agent` should be kept out of the `agents` list — it coordinates the crew, it is not one of the workers it delegates to.
code
python · 18 linesfrom crewai import Agent, Crew, Task, Process
researcher = Agent(role="Researcher", goal="Find facts", backstory="Careful analyst")
writer = Agent(role="Writer", goal="Draft copy", backstory="Concise editor")
manager = Agent(
role="Delivery Manager",
goal="Assign each task to the best specialist and verify the result",
backstory="You coordinate specialists; you never do the work yourself.",
llm="gpt-4o",
)
crew = Crew(
agents=[researcher, writer], # manager is NOT in this list
tasks=[Task(description="Produce a brief on {topic}", expected_output="200 words")],
process=Process.hierarchical,
manager_agent=manager,
)go deeper
Remember that hierarchical mode needs a manager and that you declare it with manager_llm or manager_agent on the Crew. Saying 'it needs a manager or it will not run' already answers the screening version of this question.
Explain the difference between the two knobs: manager_llm makes CrewAI build a default manager on that model, manager_agent supplies your own with a role, goal and backstory. Mention that the manager stays out of the agents list.
Talk about manager model choice as a cost and quality decision, about writing manager backstories in coordination language so it delegates rather than works, and about bounding re-delegation loops before they eat a run's budget.
Own the policy angle: the manager prompt is where routing rules live, so treat it as governed configuration — reviewed, versioned and evaluated — rather than incidental prose, and decide fleet-wide which crews may improvise routing at all.
## Why the manager is a configuration concern Under `Process.hierarchical`, the entity that decides which agent does what is itself an LLM-backed agent. That agent has to come from somewhere, and CrewAI deliberately refuses to guess: it will not silently promote the first agent in your list, and it will not fall back to sequential. You declare the manager, or the crew does not construct. ## manager_llm — the default manager Setting `manager_llm` on the `Crew` hands CrewAI a model (an identifier such as `"gpt-4o"`, or an LLM object) and asks it to build the manager for you. CrewAI creates an agent whose role is coordination, attaches the delegation tooling, and runs it on that model. This is the right default when: - coordination is generic — read task, pick specialist, check result; - you want the manager on a different (often stronger, or cheaper) model than the workers; - you are prototyping and do not yet know what the manager should be told. The manager model choice matters more than people expect. Routing is a reasoning task performed on every step; a weak manager model produces confidently wrong delegations across the entire run, and because the manager speaks first, its mistakes poison what every worker sees. ## manager_agent — your own manager Setting `manager_agent` passes a fully-specified `Agent`. Now the manager's role, goal and backstory are yours, which is how you encode policy into the coordination layer: *always send legal review to the compliance specialist*, *never accept an answer without a source*, *stop after the summary is produced*. You also control its LLM and its verbosity independently of the workers. Use it when generic coordination is producing the wrong routing, or when the manager needs domain vocabulary to tell two similar-sounding specialists apart. Keep two constraints in mind: 1. **Do not also list the manager in `agents`.** The `agents` list is the pool the manager delegates *to*. Putting the manager in it invites the coordinator to delegate to itself, and CrewAI treats manager and workers as distinct roles. 2. **Set exactly one of the two.** Providing `manager_agent` makes `manager_llm` redundant — the agent already carries its own LLM. ## What the manager can do at run time Whichever route you took, the manager is given delegation capability: it can hand a task to a named coworker and it can ask a coworker a question without transferring the whole task. That second ability is what makes hierarchical crews chatty — a manager that interrogates two specialists before assigning work burns tokens before any real work begins. Tasks in a hierarchical crew therefore need not name an agent. If you leave `agent` unset, the manager chooses. If you set it, you have pinned that step and the manager's discretion shrinks accordingly. ## Failure modes to be ready for - **Construction error.** Hierarchical with no manager configured fails validation at construction. Candidates who claim it degrades to sequential are guessing. - **Manager loops.** A manager that keeps re-delegating the same task because it dislikes the result will burn the run's budget. Bound it with per-agent iteration limits and a crew-level `max_rpm`, and inspect `CrewOutput.token_usage` afterwards. - **Role confusion.** A manager whose backstory reads like a worker's ('you are a senior researcher') will try to do the work itself instead of delegating. Write manager backstories in coordination language. - **Wrong pool.** If a specialist the manager needs is not in `agents`, it cannot be delegated to at all; the manager will improvise with whoever is available rather than error. ## Interview framing The crisp answer is: hierarchical needs a manager, `manager_llm` asks CrewAI to make one, `manager_agent` supplies your own, neither is not an option, and the manager is not one of the workers. Everything else — model choice, backstory framing, loop bounding — is the senior layer on top of that. ## Version note Describes the CrewAI 0.x `Crew` API; the `manager_llm` / `manager_agent` pair and the hierarchical validation have been stable across the 0.x line.
- When would you pay for a stronger model on manager_llm than on the workers?When routing is the hard part. The manager makes a reasoning decision on every step and its mistakes cascade — a mis-delegated task wastes the worker's whole loop. If your specialists are narrow and their prompts are tight, a cheap worker model with an expensive manager often beats the reverse for the same total spend.
- What happens if a task in a hierarchical crew does specify an agent?That step is pinned to the named agent and the manager's routing discretion for it disappears; the manager still frames and reviews the work. It is a useful escape hatch for a step that must always run on one specialist, but if most tasks are pinned you are paying manager overhead for routing you already hard-coded.
- How do you stop a manager from re-delegating the same task indefinitely?Bound both ends. Per-agent iteration limits cap how long any single worker loop can run, `max_rpm` on the crew caps request rate so a runaway is slow and visible rather than expensive, and a manager backstory that states an explicit acceptance criterion gives it a reason to stop. Then check `CrewOutput.token_usage` to confirm the loop actually closed.
saying these in an interview costs you the question
- Says a hierarchical crew silently falls back to sequential without a manager
- Thinks the first agent in the agents list becomes the manager
- Puts the manager_agent inside the crew's agents list
- Sets both manager_llm and manager_agent expecting them to combine
- Assumes the manager executes tasks itself instead of delegating