LangGraph, CrewAI, and Dapr address overlapping parts of agent orchestration, but they do not impose the same operating model. Compare the state you must preserve, the failures you must recover from, and the infrastructure you are willing to run.
This is a documentation-based comparison. No head-to-head latency, recovery-rate, or developer-productivity benchmark was run for this article. The accompanying worksheet is designed to make your own comparison reproducible.
What each system documents
| System | Documented building blocks | Configuration that matters |
|---|---|---|
| LangGraph | Graph-state checkpointers and cross-thread stores | Choose a persistence backend and identify each thread correctly |
| CrewAI Flows | Stateful event-driven flow methods and @persist | Decide what state is persisted and how a run is resumed or forked |
| Dapr Workflow / Dapr Agents | Durable workflow execution, activities, and agent integration | Operate the workflow runtime and its supporting state infrastructure |
LangGraph’s persistence guide distinguishes thread-scoped checkpoints from cross-thread stores. Its in-memory saver loses checkpoints on process restart; persistence must match the failure you want to survive.
CrewAI’s Flows documentation provides persistence at class or method scope and describes resuming or forking saved state. It would be incorrect to describe CrewAI as having no persistence merely because an introductory example keeps state in memory.
Dapr Workflow records completed workflow steps and supports recovery across interruptions. Dapr Agents builds agent capabilities on that infrastructure. Durable orchestration still needs correctly designed application activities.
Choose according to the work you already have
LangGraph is a candidate when you want explicit graph transitions and control over application state in code. Plan checkpoint storage, retention, and operational visibility as part of the implementation rather than treating a working notebook as a production deployment.
CrewAI is a candidate when role-oriented tasks and event-driven Flows match the team’s mental model. Review the actual flow behavior and persistence boundaries; a role description does not itself define transaction or retry semantics.
Dapr is a candidate when durable workflows and service infrastructure are central to the system, particularly if your team already operates Dapr. Include the operational cost of runtime configuration, state services, monitoring, and upgrades in the decision.
These are starting points. A strong existing team workflow can outweigh an attractive feature comparison. Prototype the same business operation in your shortlist before committing.
Use the same failure experiment for every candidate
Download framework-recovery.csv. Every result starts as not run. Populate it with the framework version, storage configuration, repository revision, and an evidence link after executing the case.
Use a synthetic task that creates a draft record with an application idempotency key. It should have a deterministic acceptance check and no real outbound messages.
| Interruption | Required observation |
|---|---|
| Before the activity starts | The task can resume without losing its input |
| After the external write, before checkpoint persistence | Reconciliation avoids creating a second logical record |
| After checkpoint persistence | Resume does not repeat a completed effect unnecessarily |
| Duplicate task submission | One logical task remains identifiable |
| Cancellation during execution | Final state distinguishes canceled, completed, and uncertain work |
| Process restart with the configured store | Recovery uses persisted state rather than an in-memory object |
Record the actual database or mock-service state. A framework status of “completed” is insufficient if the side effect happened twice.
Separate persistence from correctness
Saving state answers where the workflow can resume. Authorization answers whether an operation is allowed. Idempotency and reconciliation answer what happens when execution is repeated or its outcome is uncertain. None of these can replace the others.
For each candidate, collect a trace that joins the workflow ID, task ID, operation key, attempt number, and final artifact. Check which component owns retry policy. Independent retries at the SDK, worker, and queue layers can multiply attempts even when each layer has a reasonable local limit.
Score correctness before convenience. Then compare implementation effort, observability, deployment footprint, dependency changes, and steady-state cost. Keep failed cases visible. Report an outcome as “passed this case under this configuration,” not a universal recovery percentage.
A practical selection rule
Choose the candidate that satisfies your required failure cases with an operating model your team can maintain. If none does, simplify the workflow or repair the application boundary before changing frameworks.
The multi-agent architecture guide provides a task contract and budget example that can be used across all three. That contract makes it easier to change implementations without changing what success means.
Revision note
Updated October 20, 2026. Removed unsupported recovery percentages, development-speed claims, and the claim that only one framework is production-ready. Added primary-source distinctions and a common failure experiment with no fabricated results.
Primary sources
Checked October 20, 2026: langgraph durability; crewai flows; dapr workflow; dapr agents.