In CrewAI hierarchical mode, what does the manager LLM actually do?
CrewAI's manager LLM is a live coordinator. It routes Tasks to Agents, brokers delegation between Agents, and validates outputs against each Task's expected_output during the run.
Think of an editor running a small newsroom. The editor does not write the articles themselves; they read the assignment slip, pick the reporter best suited to it, and pass the work along. When the reporter needs a quote from the data-team colleague, the editor introduces them. When the draft comes back, the editor reads it against the original brief and decides whether to send it back for changes or move it forward. The editor is not just there at the morning meeting; they stay in the loop all day. Without them, every reporter would just file whatever they felt like writing.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
CrewAI's Hierarchical Process is often introduced as 'the mode where a manager LLM coordinates the crew,' which is true but slippery. The natural follow-up question. 'coordinates how, exactly?'. Is where most newcomers get stuck. Some assume the manager is a setup-time prompt builder. Others assume it routes once and then steps out. Both are wrong.
This deep dive pins down what the manager_llm actually does during a run, why it has to be a strong model, and how the design compares to the equivalent primitive in AutoGen and LangGraph.
The three runtime jobs of manager_llm
When you set process=Process.hierarchical and supply a manager_llm, CrewAI does not assign Tasks to Agents at construction time. Instead, on each Task in crew.tasks, the manager LLM is prompted with the Task spec, the full Agent roster, and the running context, and asked to make three decisions across the lifecycle of that Task.
Routing
The manager reads the Task's description and expected_output plus each Agent's role, goal, backstory, and registered tools, then picks the Agent best matched. This is the most visible job and the one most people associate with the name 'manager.'
Delegation
When the picked Agent realises mid-task that it needs a fact another Agent owns, it does not call that Agent directly. It uses the delegate or ask_question tools surfaced by CrewAI, which route the sub-question through the manager. The manager picks the target Agent, frames the sub-instruction, collects the response, and hands it back. Agents do not have peer to peer channels.
Validation
When the chosen Agent returns its output, the manager compares it against the Task's expected_output and decides whether the Task is done. If the output is off-shape or off-substance, the manager can request a revision, re-route to another Agent, or fail the Task. This makes expected_output more than documentation. It is the live acceptance criterion.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
from crewai import Agent, Task, Crew, Process
researcher = Agent(role="Researcher", goal="Find primary sources",
backstory="You read papers and cite them precisely.",
tools=[search_tool])
writer = Agent(role="Writer", goal="Draft clear explanations",
backstory="You turn research into 200-word summaries.")
brief = Task(
description="Summarise the GenAI OpenTelemetry conventions.",
expected_output="A 200-word summary with at least 3 citation URLs.",
)
crew = Crew(
agents=[researcher, writer],
tasks=[brief],
process=Process.hierarchical,
manager_llm="claude-opus-4-7",
)
result = crew.kickoff()| Aspect | Sequential Process | Hierarchical Process |
|---|---|---|
| Task to Agent mapping | Pre-assigned in code | Decided at runtime by manager_llm |
| Delegation between agents | Not first-class | Brokered by manager via `delegate` tool |
| Output validation | Manual / downstream | Manager checks against `expected_output` |
| Orchestrator cost | Zero. No manager | One manager LLM call per routing decision |
| Best fit | Linear pipelines with known assignment | Dynamic routing across a roster |
Real products, models, and research that use this idea.
- CrewAI's own documentation positions Hierarchical Process as the upgrade path from Sequential when Task to Agent routing is non-trivial.
- Teams running CrewAI in production commonly pair Claude Opus 4.7 or GPT-5.5 as the `manager_llm` with Sonnet 4.6 or Haiku-class workers. The orchestrator pays the premium.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you write an `expected_output` that the manager can validate reliably?
Shape-first: name a structure (JSON schema, fixed sections, count of items), success criteria, and explicit failure modes. Avoid subjective words like 'thorough' or 'high-quality'.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Skimping on the manager_llm by pointing it at a cheap model and then blaming the worker agents when the crew makes bad routing decisions or rubber-stamps weak output.
60 second bullets to scan on the way to the call.
What are the three runtime responsibilities of the manager LLM?
Why must expected_output be precise enough to act as an acceptance test?
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.