Sequential vs Hierarchical Crew Processes
CrewAI's process field chooses how a crew schedules work: a fixed pipeline (Process.sequential) or a manager-led team (Process.hierarchical).
Use this cheatsheet when you decide between static ownership and dynamic delegation.
How to Use This Cheatsheet
- Start from section A if you are choosing a default for a new crew.
- Use B when implementing hierarchical managers and validation loops.
- Use C when debugging cost, thrash, or unclear ownership.
- Prefer sequential until a product requirement forces dynamic assignment or manager review.
A - Decision Snapshot
| Criterion | Sequential | Hierarchical |
|---|---|---|
| Default | Yes (Process.sequential) | Opt-in (Process.hierarchical) |
| Task order | Fixed list order | Manager plans / assigns |
| Task owner | Set via task.agent | Manager allocates by capability |
| Extra config | None | Requires manager_llm or manager_agent |
| Best for | Known pipelines (research → write) | Variable routing, review, rework |
| Cost profile | One pass per task (plus tools) | Manager tokens + possible rework |
| Debuggability | High (linear logs) | Medium (delegation noise) |
| Failure mode | Weak handoff / vague expected_output | Manager thrash / mis-assignment |
Rule of thumb: if you can draw the pipeline on one line, use sequential. If a human PM would reassign tickets mid-project, consider hierarchical.
B - Implementation Cheatsheet
Sequential essentials
from crewai import Crew, Process
crew = Crew(
agents=[researcher, writer],
tasks=[research_task, write_task], # order matters
process=Process.sequential,
)| Knob | Guidance |
|---|---|
| Task list order | Defines execution order |
Task.context | Explicit upstream outputs (do not rely on vibes) |
Task.agent | Required ownership clarity |
planning=True | Optional pre-pass; still sequential execution |
Hierarchical essentials
from crewai import Crew, Process
crew = Crew(
agents=[researcher, writer, reviewer],
tasks=[research_task, write_task, review_task],
process=Process.hierarchical,
manager_llm="gpt-4o", # or manager_agent=custom_manager
)| Knob | Guidance |
|---|---|
manager_llm | Auto manager powered by this model |
manager_agent | Custom manager with its own role/goal/tools |
| Worker roles | Must be distinguishable or assignment is random theater |
| Validation | Manager reviews outcomes before proceeding - budget for it |
Side-by-side kickoff
| Step | Sequential | Hierarchical |
|---|---|---|
| 1 | Run task 1 with its agent | Manager interprets backlog |
| 2 | Feed outputs forward | Delegate to workers |
| 3 | Run task N | Review / possibly rework |
| 4 | Return CrewOutput | Return CrewOutput |
C - Choose Sequential When
- The workflow is a stable assembly line (ingest → analyze → draft → format).
- Each task has an obvious owner and tool set.
- You need cheap, linear logs for evals and CI.
- Latency and token budgets are tight.
- You can express dependencies with
context=[...].
D - Choose Hierarchical When
- Work must be routed based on intermediate findings.
- You need a reviewer/manager role that is not just another pipeline step.
- Task ownership should change without rewriting the task list every time.
- Specialists are many and the "who does this?" decision is non-trivial.
- You accept higher cost for coordination quality.
E - Hybrid Patterns (Without Lying to Yourself)
| Pattern | How | Caution |
|---|---|---|
| Sequential + planning | planning=True on sequential crew | Planning annotates; it is not full management |
| Sequential review task | Final critic agent with fixed owner | Cheaper than hierarchical; less flexible |
| Hierarchical for phase 1 only | Separate crews | Clearer than one mega-crew with mixed modes |
| Flow orchestration | CrewAI Flows around crews | Use when product needs state/chat, not only process enum |
F - Cost, Risk, and Ops
| Concern | Sequential | Hierarchical |
|---|---|---|
| Token cost | Lower baseline | Manager + possible retries |
| Latency | Predictable stages | Variable |
| Eval design | Per-task golden outputs | Include manager decision quality |
| Stuck loops | Bad task specs / tools | Bad manager prompts + worker overlap |
| Observability | Task callbacks enough | Log delegations and validation verdicts |
G - Quick Failure Diagnosis
| Symptom | Likely process issue | Fix |
|---|---|---|
| Writer ignores research | Missing context or weak expected_output | Sequential handoff repair |
| Endless "I'll reassign" chatter | Hierarchical thrash | Sharper worker goals; better manager goal; caps |
| Same agent does everything | Overlapping roles | Differentiate tools and goals |
| Bill shock | Manager rework loops | Cap iterations; switch hot paths to sequential |
| Non-deterministic owners | Hierarchical without distinct skills | Make roles non-substitutable |
FAQs
Is sequential always faster?
Usually yes for the same task set, because you skip manager planning and review turns. Tool latency can still dominate either mode.
Can I set process per task?
Process is a crew-level strategy. Split into multiple crews or use Flows if phases need different coordination styles.
Do hierarchical crews ignore task.agent?
Treat hierarchical as manager-driven allocation and validation. Design workers so the manager has clear choices; verify current assignment behavior at build for your version.
Is manager_agent better than manager_llm?
Use manager_agent when you need a crafted manager role, tools, or model. Use manager_llm for a quick default manager.
Does allow_delegation replace hierarchical?
No. Delegation is a worker capability. Hierarchical is a crew process with an explicit manager.
Should demos use hierarchical to look impressive?
No. Demos should use sequential unless you are showcasing management itself.
How does planning interact with hierarchical?
Planning can add a pre-pass; hierarchical still owns coordination. Measure combined cost before enabling both.
What process should CI use?
Sequential with fixed seeds/inputs when possible. Hierarchical evals need extra assertions on assignment and review.
Can hierarchical fix vague tasks?
No. Managers amplify ambiguity. Clarify description and expected_output first.
When should I leave Crew processes for Flows?
When you need multi-turn chat sessions, branching product logic, or durable state beyond a single crew kickoff.
Related
- The CrewAI Mental Model: Roles, Tasks, and Crews - building blocks
- CrewAI Basics - first sequential crew
- Defining Agent Roles, Goals, and Backstories - worker clarity
- Debugging a Crew That Won't Converge on an Answer - thrash fixes
- CrewAI Best Practices - scoping checklist
- The CrewAI Chat API for Interactive Crew Sessions - multi-turn product surface
Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana
@solana/web3.js+@solana/spl-token.