The problem this decision solves
Most frameworks can demonstrate a chatbot that calls tools. Far fewer remain dependable once work must survive a restart, pause for approval, and leave an operational record.
The frameworks in this comparison optimize for different problems. Some favour rapid prototypes, some conversational collaboration between agents, and others close integration with a model or cloud platform. The useful question is not which framework has the most momentum. It is which execution model fits the system you are responsible for operating.
Evaluation criteria
State and durability
Can a workflow checkpoint, recover after a failure, and resume without reconstructing its state by hand?
Observability
Can operators trace node transitions, tool calls, decisions, latency, and failure paths?
Control model
Are agents composed through explicit graphs, role-based crews, conversations, or hand-offs—and does that model fit the work?
Model portability
Can the platform change models without requiring the application to be redesigned?
Human intervention
Can execution pause at a defined point, present context for approval, and resume cleanly?
Deployment fit
Can the runtime be operated as an ordinary service inside the organization’s existing infrastructure and controls?
The field
The following is a practical positioning of the main options I considered. Framework capabilities move quickly, so each choice should be validated against the current product and deployment requirements before procurement.
LangGraph
Recommended for controlled workflowsAgents, tools, checkpoints, and approval steps are represented as nodes in a directed graph. Conditional edges make control flow explicit and reviewable.
Strengths
- Explicit state and execution paths
- Durable checkpoints and resumable workflows
- Native interrupt points for human review
- Model-provider flexibility
- Detailed per-node tracing
Trade-offs
- Requires state and graph design up front
- Higher learning curve than role-based tools
- More machinery than a small assistant needs
- Nodes must be designed for safe re-execution
CrewAI
Role-based crewsA direct way to express agents as roles with goals, tools, and delegated tasks. It is approachable for business-process prototypes and smaller multi-agent workflows.
Strengths
- Low barrier to a working prototype
- Intuitive role and task model
- Model-provider flexibility
Trade-offs
- Less explicit control over complex branching
- Durability requires more deliberate design
- Operational behaviour can become implicit as workflows grow
Microsoft Agent Framework
Microsoft ecosystemA natural candidate for teams invested in Microsoft’s application and cloud stack, particularly where Python and .NET interoperability matters.
Strengths
- Strong enterprise integration story
- Python and .NET support
- Good fit for Azure-standardized teams
Trade-offs
- Most value is realized inside the Microsoft ecosystem
- Conversation-led state can be harder to audit than an explicit graph
- Teams should confirm current maturity for their use case
OpenAI Agents SDK
Handoffs and toolsA concise, opinionated model for tools, guardrails, tracing, and hand-offs between agents. It suits teams that want a direct path on the OpenAI platform.
Strengths
- Fast path from idea to working agent
- Clear hand-off model
- Built-in tracing and guardrail primitives
Trade-offs
- Tighter coupling to one model platform
- Durable application state remains an architectural responsibility
- Hand-offs are less expressive than graphs for complex branches
Google ADK
Google Cloud ecosystemA code-first framework aligned with Gemini and Vertex AI, with useful multimodal and agent-interoperability capabilities.
Strengths
- Strong multimodal capabilities
- Good fit for Vertex AI deployments
- Support for agent interoperability patterns
Trade-offs
- Best fit is within Google Cloud
- Teams should validate operational maturity for their workload
- Less compelling for a cloud-neutral platform
Claude Agent SDK
Anthropic ecosystemA focused SDK for Claude-based agents, tool use, and context management. It is most attractive when Claude is an intentional platform commitment.
Strengths
- Strong tool-use model
- Natural fit for Claude-centred applications
- Useful integration with MCP-based tools
Trade-offs
- Coupled to the Claude model platform
- Durable orchestration still needs deliberate design
- Less direct for complex graph topologies
Side by side
| Option | Control model | Best fit | Primary concern |
|---|---|---|---|
| LangGraph | Directed graph | Durable, branching workflows | Up-front design effort |
| CrewAI | Role-based crew | Fast multi-agent prototypes | Implicit behaviour at scale |
| Microsoft Agent Framework | Agents and conversations | Microsoft-aligned estates | Ecosystem dependence |
| OpenAI Agents SDK | Agent hand-offs | OpenAI-centred products | Platform coupling |
| Google ADK | Agent hierarchy | Gemini and Vertex AI | Cloud fit |
| Claude Agent SDK | Agent and tool loop | Claude-centred products | Platform coupling |
Why LangGraph
The graph is inspectable
The topology exposes nodes, edges, and conditional branches directly. An architect can review the control flow in the code instead of reverse-engineering it from prompts and conversation history.
Recovery is part of the model
A checkpointer records state between nodes so a long-running workflow can resume after interruption. Replay is not deterministic reproduction: nodes after the selected checkpoint execute again, so idempotency still matters.
Operations can see each step
Per-node traces make tool calls, branches, interrupts, latency, and errors visible as distinct events instead of one opaque application request.
The model provider remains replaceable
The orchestration layer can work across providers and local models, reducing the cost of changing the model behind a workflow.
The extra design work is not overhead when the workflow is consequential. It is where the operating model becomes explicit.
Reference architecture
The framework should sit inside normal production controls, not beside them. A typical deployment keeps orchestration, state, telemetry, events, and downstream tools as separate operational concerns.
Every node transition should emit a trace span. The checkpointer preserves workflow state; it does not remove the need for idempotent tools and explicit failure handling.
Adoption checklist
- Map the graph before implementation: nodes, edges, decisions, and interrupt points.
- Design the state schema and reducers with the same care as an event contract.
- Choose and size the checkpoint store for concurrent, long-running sessions.
- Add tracing before the first pilot so failure paths are visible from day one.
- Pause by default before financial, irreversible, or customer-facing actions.
- Load-test failure branches, including termination during node execution.
- Pilot one bounded workflow before generalizing the pattern across teams.