Table of Contents
🌏 中文版
When choosing a multi-agent framework, the real question isn't "which one has more features" — it's "what mental model do you use to organize relationships between agents." LangGraph asks you to draw a graph — nodes are execution units, edges are transition conditions. Microsoft Agent Framework asks you to define workflows — sequential, concurrent, and handoff are all flow control structures. CrewAI asks you to do something different: describe a team.
CrewAI was open-sourced in December 2023 by João Moura, former Director of AI Engineering at Clearbit (later acquired by HubSpot). It started as a small agent he built to write his own LinkedIn posts — the process revealed that building a team of collaborating agents shouldn't be this hard. In October 2024, the company raised $18 million (led by Boldstart Ventures, Craft Ventures, and Insight Partners, with personal investments from Andrew Ng and HubSpot co-founder Dharmesh Shah). As of today, it has 57.4k GitHub stars and approximately 11.6 million weekly PyPI downloads.
1. The Role-First Core Model
CrewAI's three core abstractions are Agent, Task, and Crew. Unlike graph-based frameworks that ask you to think about nodes and edges first, CrewAI asks you to start with: what roles does this task require?
An agent definition looks like this:
from crewai import Agent
researcher = Agent(
role="Senior AI Researcher",
goal="Find the latest breakthroughs in multi-agent systems",
backstory="You have 10 years of experience in AI research, "
"specializing in agent coordination and emergent behavior.",
llm="openai/gpt-4o",
verbose=True,
)
role, goal, and backstory are the three required fields. role defines the agent's identity within the team; goal is its individual objective, influencing its decision-making direction; backstory provides context, letting the LLM understand this role's expertise and working style.
All three fields end up in the system prompt. The design assumption is: instead of precisely controlling every step of an agent's behavior with code, describe who it is and what it cares about in natural language, and let the LLM fill in the specific behavior. This is a fundamentally different level of control granularity from LangGraph's approach of defining node behavior with Python functions and controlling paths with conditional edges.
Task is what you want the agent to do:
from crewai import Task
research_task = Task(
description="Research the top 5 trends in multi-agent AI for 2026. "
"Focus on production deployments, not academic papers.",
expected_output="A structured report with trend name, evidence, "
"and adoption level for each trend.",
agent=researcher,
)
expected_output is a distinctive design choice — it doesn't just tell the agent what to do, it explicitly describes what the result should look like. This lets the framework validate outputs (guardrails) and tells downstream tasks what format of input to expect.
Crew groups agents and tasks together:
from crewai import Crew, Process
crew = Crew(
agents=[researcher, writer],
tasks=[research_task, writing_task],
process=Process.sequential,
verbose=True,
)
result = crew.kickoff()
Process.sequential is the default — tasks run in order, with each task's output automatically becoming context for the next. The other option, Process.hierarchical, adds a manager agent that decides which task goes to which agent and when a redo is needed.
2. Three Mental Models Compared
The same requirement — "research a topic, write a report, then review it" — gets modeled completely differently across the three frameworks.
LangGraph: graph-first. You define three nodes (research, write, review), connect them with edges, and use conditional edges to decide where to route when review fails. State is a typed dict flowing through the graph. Control is in your hands — you decide every path.
MAF: workflow-first. You wire three agents together using AgentGroupChat or sequential/concurrent workflows, with middleware intercepting each stage for safety checks or logging. You choose the execution mode (sequential, fan-out/fan-in, handoff); the framework handles state management and checkpointing.
CrewAI: team-first. You describe three roles — researcher, writer, editor — each with their own expertise and goals, assign tasks to them, and pick sequential or hierarchical. Interactions between agents (delegation, asking questions) happen automatically through allow_delegation=True, without you drawing edges.
This doesn't mean CrewAI has coarser control granularity — rather, the control interface is different. CrewAI delegates the details of "how agents interact" to the LLM, using natural language (role + goal + backstory) to guide behavior, rather than code to prescribe paths. This is convenient for exploratory tasks ("research this domain"), but for scenarios requiring strict flow control ("if this step fails, retry from step three, max twice"), LangGraph's conditional edges are more precise.
3. Flows — When Crews Aren't Enough
Crews handle "a group of agents collaborating on a batch of tasks," but real applications often look like: run some regular Python code to prepare data, hand it to a crew for processing, post-process the crew's output, then decide whether to run a second crew based on the results.
Flows are designed for exactly this scenario. They're an orchestration layer on top of Crews, using Python decorators to define dependencies between steps:
from crewai.flow.flow import Flow, listen, start
class ReportFlow(Flow):
@start()
def fetch_data(self):
# Regular Python: call APIs, read databases
return api.get_latest_data()
@listen(fetch_data)
def analyze(self, data):
# Hand off to a crew
crew = AnalysisCrew()
return crew.kickoff(inputs={"data": data})
@listen(analyze)
def decide_next(self, analysis):
if analysis.needs_deeper_look:
return self.deep_dive(analysis)
return analysis.summary
@start() marks entry points, @listen() monitors the output of preceding steps, @router() enables conditional branching. Flows have their own state management (supporting Pydantic models) and support @persist for state resumption across restarts.
The boundary between Flows and Crews: Crews manage collaboration between agents; Flows manage orchestration between crews and non-agent code. If you just have one group of agents doing one thing, you don't need Flows. If you have multiple crews to chain together with regular code in between and conditional routing, Flows are the entry point.
4. After Leaving LangChain
Early CrewAI was built on top of LangChain, using LangChain's chain and tool abstractions internally. This brought the benefits of LangChain's ecosystem (many ready-made integrations) but also inherited its problems: slow startup, too many abstraction layers, difficult debugging, and version conflicts.
The PyPI page now reads: "Built from scratch, independent of LangChain or any other agent framework." Version 1.x has completely removed the LangChain dependency, managing LLM calls, tool execution, and memory on its own. The practical effect is faster startup, lighter imports, and debugging without wading through LangChain's abstraction layers.
This also means CrewAI and LangGraph are now parallel choices rather than branches on the same tree. Previously, the stack was "LangChain as foundation, LangGraph for flow control, CrewAI for multi-agent"; now you choose one from the ground up.
5. The Memory System
CrewAI's memory system underwent a major redesign in 1.x: the original four types (short-term, long-term, entity, external) were consolidated into a single Memory class.
On save, the LLM automatically analyzes the content's scope, category, and importance. On retrieval, a composite score determines priority:
composite = semantic_weight × similarity + recency_weight × decay + importance_weight × importance
Default weights are semantic similarity 0.5, recency 0.3, importance 0.2. Memories are organized into a hierarchical scope structure (similar to filesystem paths, e.g., /project/alpha, /agent/researcher), and queries only search relevant branches.
The upside: users don't need to manually decide whether a memory should be short-term or long-term — the framework decides. The downside: the decision relies on the LLM, meaning each save/retrieve operation adds an extra LLM call, increasing latency and cost.
6. Open-Source vs Enterprise Feature Boundary
CrewAI's business model is open-source core + managed platform. The open-source package (MIT) includes the complete framework: Agent, Task, Crew, Flow, Memory, Tool, and Knowledge — runnable anywhere.
The commercial side is called AMP (Agent Management Platform), a hosted cloud platform. On top of open-source features, it adds:
| Feature | Open Source | AMP |
|---|---|---|
| Agent / Task / Crew / Flow definition and execution | Yes | Yes |
| CLI project creation, local execution | Yes | Yes |
| Visual Studio (drag-and-drop crew building) | No | Yes |
One-click deployment (crewai deploy create) | No | Yes |
| Real-time tracing (every agent thought, tool call, LLM completion) | No | Yes |
| Guardrails (hallucination detection, PII masking, cost caps) | Code-level task guardrails | Full UI + additional checks |
| SSO, audit logs, SOC 2 Type II | No | Enterprise plan |
| Data residency | Self-managed | Enterprise plan |
On pricing, the free plan includes 50 workflow executions per month, 1 deployed crew, and 1 user. Paid plans scale up from there, with Enterprise requiring sales contact. But the real cost driver isn't the platform fee — it's LLM token consumption. CrewAI requires you to bring your own LLM API keys, and the token costs your agents consume are entirely separate.
7. When to Use CrewAI
Good fit:
- Exploratory multi-agent tasks: Workflows like "research → analyze → write → review" where role division is clear and each role's behavior can be described well in natural language. CrewAI's role/goal/backstory is more intuitive than writing Python functions here.
- Rapid prototyping: From
crewai create flowto first results in minutes. If you want to quickly validate whether multiple agents outperform a single agent, CrewAI's scaffolding is light. - Non-engineers participating in agent design: Since the core agent definition is natural language (role, goal, backstory), PMs or domain experts can directly participate in tuning without changing code.
Not ideal for:
- Strict flow control: If your agent flow has logic like "when step A fails, go back to step C, but max two retries, then take the degradation path" — LangGraph's conditional edges are more suited than CrewAI's sequential/hierarchical.
- Latency-sensitive applications: CrewAI's delegation mechanism and memory system both make additional LLM calls, multiplying token consumption and latency in multi-agent setups. Each agent's
max_iterdefaults to 20, meaning a single task could call the LLM up to 20 times. - Type-safe inter-agent communication: LangGraph's state is a typed dict; MAF has middleware and filters — both are code-level controls. CrewAI's inter-agent communication (delegation, asking questions) runs on natural language, controllable via the text description in
expected_outputrather than a Pydantic schema.
How to decide: If you're choosing a multi-agent framework right now, ask yourself one question: are the interactions between your agents more naturally described in natural language ("hand the draft to the editor for review") or more naturally prescribed in code ("if the generate node's output score is below 0.5, go back to the retrieve node")? The former points to CrewAI; the latter to LangGraph. If you need enterprise-grade middleware, checkpointing, and compliance, start with MAF. If your problem doesn't actually need multiple agents, look at LlamaIndex or just use the model API directly. For a broader framework map, see this overview.
References
- CrewAI GitHub
- CrewAI Official Documentation
- CrewAI PyPI
- CrewAI Agents Concept
- CrewAI Crews Concept
- CrewAI Tasks Concept
- CrewAI Flows Concept
- CrewAI Memory Concept
- CrewAI Collaboration Concept
- CrewAI Wikipedia
- LangGraph: Managing Agent Workflows with Graph Structures
- Microsoft Agent Framework
- LlamaIndex
- 15 Agent Frameworks Worth Watching in 2026
Loading...