Key takeaways
- LangGraph fits workflows that need persistence, checkpointing, crash recovery, and fine-grained execution control. That control requires more upfront design.
- OpenAI Agents SDK fits tightly scoped assistants and delegation workflows. It supplies the agent loop and lifecycle, plus built-in tracing across key runtime events.
The useful question in LangGraph vs OpenAI Agent SDK is not which framework has the longest feature list. It is which parts of the runtime your application needs to expose and own. Agent systems can require different orchestration, state, permissions, recovery, deployment, and evaluation even when they all call models and tools. Framework selection is therefore a runtime-ownership decision, not a general popularity contest.
Use one real workflow. Mark where its loop can pause, which side effects require approval, what state must survive, and how recovery should behave after a failure. Then test the runtime at those boundaries. This puts the decision in the application, where supplied behavior may be useful leverage or a control surface the team needs to own.
What are the key differences between LangGraph and OpenAI Agent SDK?
The key difference is runtime ownership across the loop, approvals, state, and recovery.
| Control surface | LangGraph mechanism | OpenAI Agents SDK mechanism | Deciding application condition |
|---|---|---|---|
| Workflow and loop shape | LangGraph is positioned for complex agents that require precision. It supports persistence, checkpointing, crash recovery, and fine-grained execution-flow control, with more upfront design. | The SDK provides the agent loop and lifecycle. It is positioned for tightly scoped assistants and delegation workflows. | Decide whether the application needs a precisely designed, persistence-heavy workflow or a supplied loop for a scoped assistant or delegation flow. |
| Pause and approval control | An interrupt pauses at an interrupt() call and stores workflow state under a stable thread_id in the configured checkpointer. | Tool visibility is separate from human approval checks. Guardrails check requests and outputs. Approvals pause risky side effects, while lifecycle callbacks support logging, tracing, and audit events. | This surface is decisive when work must pause for approval and later continue from stored workflow state. It also matters when tool access and approval checks must remain separate. |
| State and failure recovery | LangGraph separates pending task writes from committed checkpoints and saves a checkpoint after a step's writes are applied. Completed writes from parallel nodes can remain attached to an in-progress checkpoint, and a later run can recover from the last committed checkpoint at the step boundary. | A sandboxed workspace can isolate risky or stateful work, with scoped files, command execution, artifacts, and resumable workspace state. | Choose according to whether you need explicit step-boundary recovery or isolated, resumable workspace state. A resumable sandbox does not by itself establish durable execution or completed-action recovery. |
Why use OpenAI Agents SDK?
OpenAI Agents SDK is a strong fit when the application centers on a scoped assistant, explicit business tools, specialist delegation, and built-in visibility into the agent run. Its built-in traces cover model calls, tools, agents, guardrails, and handoffs. That gives these runtime events a shared tracing mechanism instead of leaving each one as an unrelated application concern.
The tool boundary is also concrete. Business actions such as searching flights or creating tickets can be explicit tools with typed inputs and predictable outputs. The application can decide which tools the agent sees separately from whether a human approval must pause a risky side effect. Guardrails check requests and outputs, while lifecycle callbacks can support logging, tracing, and audit events.
For a scoped assistant, list the business actions that should cross an explicit tool boundary. Flight search and ticket creation are separate actions, and each can have its own typed inputs and predictable outputs. Then decide which tools are visible and which risky side effects need approval. The execution model treats those as separate controls.
For multi-agent routing, the SDK can use specialist agents instead of one massive agent. A handoff_description supports the routing decision by describing the specialist for the handoff. This is a specific delegation mechanism, not a claim that more agents automatically produce a better system.
Those built-in pieces matter most when they match the shape of the application. If the central problem is a long-running workflow with explicit checkpoints and recovery at step boundaries, the decision returns to how much of the runtime your team wants to design and own.
Which parts of the runtime should your team own?
Own the parts whose behavior must stay explicit when the workflow pauses, fails, or changes. The answer can differ across orchestration, state, permissions, recovery, deployment, and evaluation. Two applications may both call a model and a tool while needing very different harnesses around those calls.
A short tool-calling loop may only need a supplied lifecycle, a small set of typed tools, and traces over the run. A workflow that must pause for approval, survive a restart, or coordinate several agents over multiple hours has a different runtime requirement. A framework suited to the short loop can be a poor fit for the longer workflow.
Start with the failure and control questions your application already creates. Does approval need durable state? Must recovery happen from an explicit step boundary? Does the application need isolated workspace state, or a designed graph with checkpoints? The answers tell you whether the framework should supply the loop or expose more of it for application-level design.
Deployment and evaluation belong on the same ownership map. They can differ between agent applications just as orchestration, state, permissions, and recovery can. A short loop and a multi-hour workflow should not inherit the same runtime design merely because both use model calls and tools.
This is the same boundary we use when thinking about an agent loop and the wider agent harness. The model call is only one part of the system. State, tools, permissions, execution, and recovery determine what the application can control when ordinary execution stops being ordinary.
Provider coupling is only part of the operational cost
Provider coupling matters, but it is not the whole operating model. Provider-native SDKs offer tighter model integration and simpler setup, with the tradeoff of vendor lock-in. Independent frameworks such as LangGraph provide model flexibility while adding abstraction layers. Neither fact settles the choice without the application's runtime requirements.
The operational boundary extends beyond the orchestration primitive. Authentication, retries, observability, memory, and integrations remain part of the application around it. A clean agent loop does not make those five concerns disappear. They still affect what the team must run, inspect, and recover.
This changes how to read the usual flexibility argument. Model flexibility can matter when the application needs it, but the added abstraction layer is still part of the system. Tighter provider integration can simplify setup, but the resulting coupling is also part of the system. The relevant cost is the complete operating surface, not one framework characteristic viewed alone.
Map that surface before comparing implementation effort. Record where authentication lives, how retries behave, what observability captures, what memory preserves, and which integrations can cause external effects. Then mark whether the framework owns each concern, exposes a mechanism for it, or leaves it to application code. That inventory does not produce a universal winner. It shows the work your team is accepting with either choice.
Keep the provider question beside that inventory. Tighter integration and simpler setup are one tradeoff. Model flexibility and an additional abstraction layer are another. Authentication, retries, observability, memory, and integrations remain operational concerns in either case, so the framework label cannot stand in for an operations plan.
The next boundary is more demanding because a normal demo rarely reveals it. A runtime can preserve conversation state and still leave the status of external actions unclear after a crash.
Durable execution has to survive the bad moments
Saved chat history is not durable execution. Session memory does not establish which actions completed or whether a retry would duplicate a side effect. A durable agent needs an execution journal, idempotent tool boundaries, versioned prompts and tools, durable human approvals, and recovery tests.
Test those properties by crashing the runtime at the boundaries where state and external effects can separate. Use one representative workflow and force these seven failures:
- Crash after the model response arrives but before the following state transition.
- Crash after an external API reports success but before completion is recorded.
- Crash after a file or state write.
- Crash after a human approval is given.
- Crash while a trace is being exported.
- Crash while prompts or tools rotate to a new version.
- Crash while an outbound message is queued.
For every crash, inspect the execution journal and the recovered workflow state. Determine which actions completed and whether the retry repeats an external effect. Check that the approval remains durable and that the resumed run uses the intended prompt and tool versions.
Do not stop after a successful restart. A durable run must preserve more than conversation history. The journal must show completed actions, approvals must remain durable, and the active prompt and tool versions must remain identifiable through recovery. The idempotent tool boundary is part of the required design at the point where a retry could repeat a side effect.
Run this test against the actual mechanism you plan to ship. For LangGraph, that may include its committed checkpoints, pending writes, and recovery at a step boundary. For the OpenAI Agents SDK, resumable sandbox state is useful for scoped files, commands, and artifacts, but it is not evidence that every external action has durable completion records. The crash test exposes what the surrounding application still has to provide.
Prompt injection and data leakage remain concrete tool risks
Recovery is only useful if the resumed system still respects its data and action boundaries. Prompt injection happens when malicious content in untrusted text or data tries to override the AI system's instructions. The resulting behavior can include private-data exfiltration through downstream tools, misaligned actions, or other unintended changes.
That threat path has two important forms. In the first, malicious content influences the model and the model uses a downstream tool in a way the application did not intend. This is why tool visibility and human approvals are separate controls in the OpenAI execution model. A tool can be visible while a risky side effect still requires an approval pause.
In the second form, no attacker is required. An agent can send more private data to a connected MCP than the user intended. Guardrails can limit the information placed in context, but they do not provide full control over what the model shares with connected MCPs. A guardrail is therefore one control boundary, not a complete guarantee against private-data leakage.
The framework comparison cannot collapse these risks into a feature checkmark. Traces can cover model calls, tools, agents, guardrails, and handoffs. Lifecycle callbacks can support audit events. Those mechanisms improve what the application can record, while the documented leakage boundary still remains. Visibility into an event and control over the data sent during that event are distinct system properties.
Keep the security review attached to the real tool and data path. Identify the untrusted input, the private data available in context, the connected MCP, the downstream action, and the approval point for risky effects. This does not prove that either framework prevents prompt injection. It exposes where the application must enforce permissions and where a model still has room to share or act.
CrewAI and Google ADK start from different project assumptions
There is no useful universal answer to which AI agent SDK is “best.” For this decision, best means that the runtime mechanisms fit the workflow and its failure boundaries. LangGraph and the OpenAI Agents SDK are not the only starting points, but adjacent options begin with different project assumptions.
The OpenAI Agents SDK is an MIT-licensed multi-agent workflow SDK. Its recognizable fit signal in this comparison is a scoped assistant or delegation workflow with a supplied loop, lifecycle, and built-in tracing. LangGraph is positioned for complex agents requiring precision, with persistence and fine-grained execution control that require more upfront design.
CrewAI is an MIT-licensed multi-agent orchestration framework positioned for rapid prototyping of role-based agent workflows. Its fit signal is the role-based prototype, not a documented winner relationship with either framework in the main comparison.
Google ADK is an Apache 2.0 agent-development framework positioned for GCP-native teams seeking an opinionated agent runtime. Its fit signal is the GCP-native, opinionated starting point. That is a different project assumption from choosing LangGraph for a persistence-heavy workflow or choosing the OpenAI Agents SDK for a scoped assistant and delegation.
The license labels also answer a narrower question without deciding runtime fit. The OpenAI Agents SDK and CrewAI are MIT-licensed. Google ADK uses Apache 2.0. Runtime ownership, recovery behavior, and the project's starting assumptions still require their own decision.
These descriptions establish project fit and licensing, not equivalent performance. They do not support conclusions about current latency, cost, maintenance burden, or implementation effort across matching applications.
Apply the Control-Surface Fit Matrix to one workflow you intend to run. Then execute the seven deliberate crashes before you commit to its runtime. Our AI agent framework selection guide places more options against control and recovery questions.