LangGraph or CrewAI: a state graph versus a team of roles

Both frameworks are MIT-licensed, both assemble agents from a model, tools and memory, and both survive production. The difference is the mental model: LangGraph asks you to describe the process as a graph with explicit state, CrewAI as a team of agents with roles and tasks. That decides what is easy in week one and what hurts six months in. A breakdown as of 29 October 2026, plus the third option people ask about less: plain code with no framework.

8 min read

Two mental models

LangGraph describes an agent as a directed graph: nodes do the work, edges define transitions, state flows between nodes and is saved at checkpoints. You write the process explicitly, including loops, branches and the points where execution should pause and ask a human. It is a low-level tool: it hides no prompts and makes no decisions for you about error handling.

CrewAI describes an agent as a team. Each agent has a role, a goal and a backstory, tasks are assigned to agents, and the crew runs them sequentially or hierarchically, where a manager agent plans and delegates. For scenarios where the process is not yet formalised that yields a working prototype in hours. For precise control of step order CrewAI offers Flows: event-driven workflows with state and branching.

Both approaches can build the same system. The question is how much code of which kind you write and where the hidden decisions end up: in your graph or inside the framework.

What we verified on 29 October 2026

So that the comparison does not become a retelling of other people's reviews, here are facts from the primary pages.

  • LangGraph: MIT licence, stable 1.0 shipped in October 2025 with no breaking changes. The 1.0 announcement lists durable execution, built-in persistence and first-class human-in-the-loop patterns. Python and JavaScript. Hosting and observability through LangSmith is a separate commercial product.
  • CrewAI: MIT licence, Python 3.10 to 3.13. The repository page lists Crews and Flows, sequential and hierarchical processes, and MCP and A2A support for tool access and delegation to remote agents. A commercial deployment platform exists.
  • What we did not find on primary pages: comparable performance figures. Every “40% faster to prototype” number in third-party reviews traces back to vendor material and is not used in this article.

Comparison on the criteria that decide in production

The criteria below come from what breaks in agents after launch: state, retries, permissions, cost, reproducibility. They matter more than first-week convenience.

LangGraph and CrewAI on six criteria
CriterionLangGraphCrewAI
Control flowExplicit graph: every transition is visible in codeCrew process or a Flow; inside a Crew the model partly decides the order
State and resumptionCheckpoints are built in: pause, resume after a restart, multi-day approvalsState exists in Flows; long pauses and resumption need your own plumbing
Human-in-the-loopFirst-class API: pause, show, edit, continueThrough task settings and Flows; less granular
Multiple agentsSubgraphs and routing; you write the codeThe framework's main scenario: roles, delegation, A2A
Learning curveHigher: you design the graph and the stateLower: roles and tasks read without preparation
ObservabilityMost detailed in LangSmith; OpenTelemetry via third-party toolsBuilt-in telemetry plus integrations with Langfuse and similar tools

Where CrewAI's convenience runs out

A team of roles describes research-style tasks well: gather information, draft, review, format. There it is acceptable for the model to decide who gets the work next. Problems start when the process has a cost of error.

  • Deterministic steps. “Check permissions, then debit, then notify” is not delegation but an order that must not be violated. In a Crew that moves into a Flow, and at that point you are already writing a graph, just with different syntax.
  • Idempotency and retries. The manager agent repeated a task after a timeout and the request was filed twice. Retry protection has to live in the process state, and in the team model that state is smeared across agents.
  • Cost. Every agent in the team reasons separately, and delegation adds model calls. Irrelevant for a prototype, the main line of the bill at ten thousand tasks a day. A per-task step limit is harder to enforce in the team model than in a graph.

What LangGraph's control costs

Control is not free. The graph has to be designed before the first node is written: what state, which transitions, where the checkpoints are. For a team without prior experience that is a week to the first working agent instead of a day, and the first version of the graph usually gets rewritten.

The checkpoint store is a database holding user state, including the content of their requests. It has to be secured and maintained like any database: access rights, encryption, retention, library updates. That is a part of operations demos never show.

Out-of-the-box observability means LangSmith. If traces cannot go to a third-party cloud, wire a self-hosted tool through OpenTelemetry and budget for it.

The third option: no framework

One agent with three to five tools and no long pauses is a “call the model, run the tool, repeat” loop in a couple of hundred lines. Such code has no dependencies that break on upgrade, no foreign prompts inside and no abstractions to explain to a new engineer.

A framework pays off in three cases: the process must survive restarts and wait for a human for days, there are several agents handing work to each other, or the team already knows the tool and does not want to reinvent state persistence. If none of the three applies, start with code and move to LangGraph when the first multi-day pause appears.

How to choose with three questions

The decision usually fits into three questions, and they can be answered before any code is written.

  • Are there steps whose order cannot be trusted to the model? If yes, it is a graph: LangGraph or your own code. CrewAI fits only through Flows.
  • Must the process wait for a human longer than one request? If yes, you need checkpoints, which is LangGraph's strength.
  • Is the task research-like, with several roles and a tolerable cost of error? If yes, CrewAI delivers a working result fastest, and you may never need to rewrite it.

In short

LangGraph is a graph with explicit state and checkpoints; CrewAI is a team of roles with Flows for precise control. The same system can be built on either; the code will differ.
The cost of error decides: debits, permissions and irreversible actions call for a graph. Research tasks with several roles are CrewAI territory.
LangGraph's control costs a week of design and a checkpoint database that has to be secured.
One agent with a few tools and no long pauses needs no framework. Adopt one at the first multi-day pause.

Questions

Can CrewAI and LangGraph be used together?

Yes, and it happens: LangGraph holds the outer process with state and pauses, while a Crew executes one research-style node inside it. The key is an explicit boundary: state and retries live in the graph, the crew receives a task and returns a result.

Which is better for multi-agent systems?

It depends on what “multi” means. Several roles passing a draft around: CrewAI does that in hours. Several services with permissions, cost and irreversible actions: LangGraph with subgraphs, because every hand-off is written in code.

Do these frameworks lock you into one model provider?

No, both work with multiple providers, including OpenAI-compatible APIs. Lock-in appears elsewhere: for LangGraph in hosting and observability through LangSmith, for CrewAI in the commercial deployment platform. Neither is mandatory.

What to pick when the team has experience with neither?

Start with the task, not the framework: write the process out step by step and mark where the order is rigid, where a human pause is needed and where the cost of error sits. With no rigid steps and no pauses, the first option is your own code. With them, LangGraph: a week of design pays for itself with the first incident that does not happen.

Product documentation

Read next

Dify, n8n or custom development for an internal AI agent

Dify is a useful starting point for an AI application with models and knowledge. n8n starts from workflows that connect services and actions. Custom code becomes relevant when access rules, action control or operations exceed what the chosen platform can support. Test the choice on one real workflow.

AI agent platforms in 2026: what a business should choose

Eleven platforms, what each of them charges for, where its ceiling is and what actually works from Russia. Every figure comes from the vendor's own public page, checked on 6 September 2026, with the source named. No rankings and no top-ten lists: the choice depends on what you are building, not on a position in a table.

OpenAI Agent Builder is shutting down: how to migrate an agent without breaking it

OpenAI shuts down Agent Builder on 30 November 2026. There are two official paths: the Agents SDK if the agent lives in your application, and ChatGPT Workspace Agents if your staff use it inside ChatGPT. A code export exists, but it does not convert the workflow graph. So migration is mostly verification: capture real inputs before the shutdown and replay them on the new version.

How to build an AI agent: what you need beyond the prompt

The prompt and the model are the smaller part of the job. An agent becomes usable when it has tools, explicit authority boundaries, state, a log and cost control. A step-by-step breakdown of what it is made of, how to get it to production and where it breaks.

Choosing a framework for an agent with a real cost of error? We will map the process step by step and show where a graph is needed.