OpenAI Agents SDK vs LangGraph (2026): Handoffs vs Durable Graphs

Quick verdict

If you want the short version, pick by what a failed run actually costs you and by how much branching your workflow really has:

Fast triage-to-specialist agent, OpenAI-native, shipping this sprint: OpenAI Agents SDK.
Long-running, resumable, auditable workflow where a lost run means real money, a compliance gap, or a support fire: LangGraph.
Voice, realtime, or a small set of agents that mostly hand a conversation back and forth: OpenAI Agents SDK.
Cyclic, conditional, multi-branch logic that needs to pause for a human and resume days later from the exact same state: LangGraph.
Most serious production shops end up running both: OpenAI Agents SDK for the conversational front door, LangGraph (or an equivalent durable-execution layer) for the paths that touch money, long-running jobs, or audit trails.

The framing that matters more than any feature checklist: these two tools answer different questions. OpenAI Agents SDK is built around one question, who is in charge right now? Its primitives (Agents, Handoffs, Guardrails, Sessions, Tracing) exist to make that question cheap to answer and easy to reason about. LangGraph is built around a different question, what shape does this computation have? Its primitives (nodes, edges, typed state, checkpoints) exist to make that shape explicit, inspectable, and resumable. Neither question is "better." They are the right question for different failure-cost profiles.

We already cover LangGraph head-to-head against CrewAI, Mastra, and Strands Agents in a separate four-way framework comparison. This post is the deeper, two-way cut specifically against OpenAI's own SDK, because that pairing is the one we get asked about most: teams that started on OpenAI's primitives and are now deciding whether, and when, to add a durable-graph layer underneath.

At-a-glance matrix

Version numbers, star counts, and pricing figures below are directional. They were accurate to the sources we read in mid-2026 and should be re-checked against vendor pages before you cite them anywhere public.

	OpenAI Agents SDK	LangGraph
Core question	Who is in charge right now?	What shape does this computation have?
Mental model	Agents, handoffs, guardrails, sessions, tracing	Explicit graph: nodes, edges, typed shared state
Primary language	Python-first, official TypeScript/JS SDK also shipped	Python-first (TypeScript port trails in maturity)
Origin	Production-ready successor to OpenAI's experimental Swarm framework	Built by the LangChain team as a lower-level graph runtime
Best when	Triage-to-specialist handoffs, fast prototyping, OpenAI-native tools and voice	Durable, resumable, auditable, cyclic or heavily branching workflows
Weakest when	Long-running crash-resume, deep branching logic, multi-day human approval loops	Slowest first prototype, deepest observability sits behind paid LangSmith
Durable execution	Sessions track conversation history; no built-in per-step checkpoint/resume (verify against current docs)	Per-node checkpointing to a persistence layer, multiple durability modes, crash-resume
Human-in-the-loop	Guardrails validate input/output; tool-call approval gates exist, but there is no native pause-and-resume-later primitive	`interrupt()` is a first-class primitive: pause mid-graph, resume from the exact same state later
Observability	Built-in tracing for viewing, debugging, and evaluating agent runs, plus OpenAI Evals	Deepest experience through LangSmith, a separate paid product beyond a modest free tier
Model/provider options	OpenAI-native by default; docs describe reaching 100+ other models via a LiteLLM integration (verify current scope, do not treat as a blanket "provider-agnostic" claim)	Model-agnostic through LangChain's broad provider integrations
MCP support	Built in as a first-class tool source	Supported through LangChain/LangGraph MCP adapters

Two different questions

It is tempting to read "agent framework" comparisons as a feature-for-feature beauty contest: who has more integrations, more stars, more logos. That framing misses the actual decision. The honest way to compare OpenAI Agents SDK and LangGraph is to notice they were designed to answer different questions about the same underlying problem, which is: how do you get an LLM to take multiple steps, use tools, and hand off control safely.

OpenAI Agents SDK asks "who is in charge right now?" Every unit of work is an Agent: an LLM configured with instructions, a model, a set of tools, and optional guardrails. When an agent decides it is not the right one to continue, it performs a Handoff, a specialized tool call that transfers the conversation to a different agent. This is the classic triage pattern: a router agent listens, decides who should own the next turn, and hands off. It is a deliberately minimal set of primitives, and that minimalism is the point, not a limitation waiting to be filled in.
LangGraph asks "what shape does this computation have?" You define nodes (units of work), edges (control flow, including conditional and cyclic edges), and a typed shared state object that flows through the graph. Because the shape is explicit and declared up front, LangGraph can checkpoint state at each node and resume from a known point after a crash, a timeout, or a human pause. Durability and human-in-the-loop are not features bolted onto a chat loop; they fall out naturally from having an explicit graph to checkpoint.

Neither approach is more "advanced." A triage-and-specialist support bot genuinely does not need a typed graph with cyclic edges; the OpenAI Agents SDK model maps to the actual shape of that problem more directly and ships faster. A claims-processing workflow that has to survive a server restart three days into a multi-step approval process genuinely does need an explicit, checkpointed graph; forcing that into a chain of handoffs means you end up hand-rolling your own state machine on top of a framework that was not designed to be one.

Deep dive: OpenAI Agents SDK

The OpenAI Agents SDK is the production-ready successor to Swarm, OpenAI's earlier experimental multi-agent framework. It keeps Swarm's lightweight philosophy (small number of primitives, minimal abstraction) and hardens it with the pieces a real deployment needs: guardrails, sessions, and tracing. Per the official docs (openai.github.io/openai-agents-python), the primitives are:

Agents. An LLM configured with instructions, a model, a list of tools, and optional guardrails and handoff targets. This is the fundamental unit of the SDK, and most systems are built from a small number of them.
Handoffs. A specialized tool call that lets one agent transfer control of the conversation to another agent. This is also how the SDK implements "agents-as-tools": an orchestrating agent can either fully hand off, or call a specialist agent as a callable tool and keep the result inline without giving up control.
Guardrails. Configurable safety checks that run on input and output, in parallel with the main agent logic, so you can validate or block content without slowing the primary path. This is the SDK's main answer to "what stops the agent from doing something it should not."
Sessions. Automatic conversation history management across multiple agent runs, so you do not have to manually thread the transcript through every handoff and every turn.
Tracing. Built-in tracking of agent runs so you can view, debug, and optimize your workflows, and hook into OpenAI's evaluation, fine-tuning, and distillation tooling from the same trace data.

Beyond the five core primitives, the SDK ships first-class Model Context Protocol (MCP) support for pulling in external tools, sandbox and computer-use style tools for agents that need to act on a filesystem or a UI, human-in-the-loop via tool-approval gates (an agent can be configured to pause and require explicit approval before it calls a specific tool), and a realtime API path for voice agents. There is also an official TypeScript/JavaScript SDK alongside the Python one, which matters if your product team is not primarily in Python.

Strengths. The primitive set is small enough to hold in your head, which means the time from "idea" to "working triage agent" is short. Handoffs map directly onto how support and sales teams already think about escalation and routing. Guardrails running in parallel with the main loop are a clean way to add input/output validation without restructuring your agent logic. Tracing, evals, and the rest of the OpenAI platform are one integration away rather than a separate vendor decision. Realtime voice and computer-use tooling are genuinely ahead of most competing frameworks if that is part of your product.

Trade-offs. The SDK does not give you an explicit, typed state object that the framework itself checkpoints step by step. Sessions manage conversation history, which is not the same thing as a durable execution engine that can resume a half-finished multi-step job after a process crash. Human-in-the-loop is expressed as tool-call approval gates, which works well for "pause before this one dangerous action" but is a different shape from "pause the entire workflow, store it, and let someone resume it next week." And while the docs describe reaching many other model providers through a LiteLLM integration, the SDK's deepest, most native experience (Responses API features, built-in tools, realtime voice) is OpenAI-specific; treat the multi-provider story as available, not as proof there is no practical lock-in.

Choose OpenAI Agents SDK if your workflow is mostly conversational turns and triage-to-specialist handoffs, a lost or restarted run is annoying rather than dangerous, you are already committed to OpenAI's models and platform, and you want the shortest path from prototype to a working production agent.

Deep dive: LangGraph

LangGraph, from the LangChain team, is the more explicit and, for Python teams that care about correctness under failure, more production-hardened of the two.

Strengths. The graph model gives you durable execution with per-node checkpointing and multiple durability modes, so a crashed, interrupted, or timed-out run can resume from its last known point rather than restart from zero. Its interrupt() primitive makes human-in-the-loop pauses (approval steps, manual review, escalation to a person) a first-class, resumable pattern rather than a workaround built on top of a chat loop. Because state is typed and explicit, cyclic and heavily conditional control flow (retry loops, multi-stage approval chains, branching that depends on upstream results) is straightforward to express correctly. Observability through LangSmith is the deepest available for this kind of workflow.

Trade-offs. LangGraph has a steeper path to a first working prototype: you are writing more explicit structure up front, which pays off later but slows the initial demo compared to wiring up a couple of agents and a handoff. The richest observability experience is tied to LangSmith, a paid product beyond a modest free tier, so factor that into total cost rather than assuming the framework itself is the whole bill. The official TypeScript port exists but trails the Python library in maturity, so a TS-first team will feel more friction here than in the OpenAI Agents SDK's JS SDK.

Choose LangGraph if you are Python-first, a failed or lost workflow run is expensive or dangerous (payments, claims, healthcare, anything regulated or audited), and you need durable, resumable state and mature, native human-in-the-loop rather than a tool-approval gate bolted onto a chat loop.

Production durability and human-in-the-loop: what actually happens when it breaks

This is the section that decides most real architecture debates, because it is the one that shows up during an incident rather than a demo.

The process crashes mid-run. In LangGraph, the last completed node's checkpoint is on disk (or in whatever persistence layer you configured); on restart, the graph resumes from that checkpoint rather than replaying from the start. In OpenAI Agents SDK, Sessions preserve the conversation history, so an agent can pick the conversation back up, but there is no built-in mechanism that guarantees a partially completed multi-step tool call resumes exactly where it left off; you are more likely to be re-running the current turn than resuming a checkpointed step.
A human needs to approve step 4 of 9, and might not respond for two days. LangGraph's interrupt() is designed for exactly this: the graph pauses, state is durably stored, and it resumes cleanly whenever the approval arrives, even much later. The SDK's tool-approval gates work well for "confirm before this one action fires," but were not designed for a multi-day pause across an entire workflow; you would be building that durability yourself on top of Sessions.
The workflow needs to retry a step, then loop back two steps if the retry also fails. This is a cyclic-edge problem, and it is close to LangGraph's home turf: express it as a conditional edge back to an earlier node. In the SDK's model, this kind of branching logic lives in your own orchestration code around agents and handoffs, since handoffs are a one-directional transfer of control rather than a graph you can loop.
You need an audit trail proving exactly which state the system was in when a decision was made. LangGraph's typed, checkpointed state is close to an audit log by construction. The SDK's tracing gives you a strong view of what the agents did and why, but it is a trace of agent behavior, not a durable, replayable state snapshot at every step.

None of this makes the SDK "worse." A triage agent that routes a support ticket to the right specialist mostly does not have step 4-of-9, multi-day-pause problems. It has "did the right agent pick this up, and can I see the trace." The mismatch only bites when a workflow that started simple grows branches, stakes, and duration without anyone deciding to add a durability layer.

Total cost of ownership

Neither framework's core is where your money goes. Model three layers: the framework itself, the observability tooling, and the model/token spend. Figures below are directional and should be re-verified on vendor pages before you quote them externally.

	OpenAI Agents SDK	LangGraph
Framework cost	Open source, no separate framework fee	Open source core, no separate framework fee
Observability	Built-in tracing included with API usage; OpenAI Evals for evaluation runs	LangSmith free tier (~5k traces/mo reported), then usage-based paid tiers (~$39/seat/mo entry, plus trace volume)
Model spend	Tied to OpenAI model pricing; multi-provider routing possible via LiteLLM but the deepest features stay OpenAI-native	Model-agnostic; spend follows whichever provider(s) you route to across LangChain's integrations
Durability tax	Low by default; you pay in engineering time if you later need to bolt on checkpointing yourself	Paid upfront in design time and a persistence store (Postgres or equivalent) for checkpoints
Cost shape to watch	Token spend concentrated on one provider; re-architecture cost if you outgrow handoffs into a durable-graph need	LangSmith trace volume and seats scale with usage; persistence store is another piece of infra to run and back up

The practical TCO lesson: teams that start on the SDK and stay small pay almost nothing extra for orchestration, because tracing and evals are already inside the OpenAI bill. Teams that need LangGraph's durability are not paying for the graph itself; they are paying for LangSmith's observability tier and for running a persistence layer, in exchange for not having to build crash-resume and audit logging by hand. Budget for the layer you actually need rather than defaulting to the heavier one "to be safe," and rather than staying on the lighter one past the point where a lost run starts costing real money.

Security and ownership

For regulated teams in Australia and Singapore, this section is often what actually decides the build.

Input/output validation. OpenAI Agents SDK's Guardrails run in parallel with the main agent loop specifically so you can validate or block content without adding latency to the happy path; this is a clean, native pattern for prompt-injection and output-safety checks. LangGraph does not ship an equivalent named primitive, but the same checks are straightforward to express as their own graph nodes, gaining the same benefit of being explicit and inspectable in the graph's state.
Human approval as a security control, not just a UX nicety. If your compliance posture requires a documented human sign-off before a high-stakes action, LangGraph's interrupt() gives you a durable, auditable pause that survives restarts and long delays. The SDK's tool-approval gates cover the "confirm before this action" case well; if you need the pause itself to be durable across days, plan to build that persistence layer yourself or add LangGraph underneath the specific paths that need it.
Secrets and blast radius. Neither framework should be the thing holding long-lived credentials. The safer pattern regardless of framework choice is a control plane that holds secrets and a sandbox (or the SDK's own sandboxed/computer-use tools) that runs model-directed actions with minimal standing access. This is a runtime and architecture decision that sits above either framework.
Data residency and vendor exposure. Running the OpenAI Agents SDK ties your trace and conversation data more tightly to OpenAI's platform by default, even with multi-provider model routing available. LangGraph is more provider-neutral for model calls, but your observability data still leaves your boundary if you use hosted LangSmith, so check where trace data is stored either way before committing an AU/SG regulated workload to either stack.
Ownership if the vendor changes terms. Both have open-source cores, which protects your reasoning and orchestration logic. Your real exposure in both cases is the hosted observability layer (OpenAI's platform tracing, or LangSmith), not the framework code itself.

Migration path: OpenAI Agents SDK to LangGraph

The most common real-world pattern is not "choose once," it is "start on the SDK, then move the paths that earned it onto a durable graph." Here is the shape of that migration when it happens:

Identify the paths that actually need durability. Not every agent in your system needs to move. Triage, FAQ handling, and short conversational flows usually do not. Anything money-adjacent (payments, refunds, claims), long-running (multi-day approvals, batch processing), or subject to audit (regulated decisions, anything a compliance team will ask about later) is the migration candidate.
Re-express agents and handoffs as nodes and edges. Each Agent typically becomes one or more graph nodes. A Handoff becomes a conditional edge that routes to the next node based on the current state, rather than a tool call that transfers a conversation. This is a genuine re-architecture of the orchestration layer, not a config change, because the mental models differ: "who is in charge" becomes "what state are we in and where do we go next."
Turn Guardrails into validation nodes. Input/output checks that ran in parallel with an agent become their own nodes (or node-level validation) in the graph, keeping the same intent but making the check part of the explicit, checkpointed flow.
Turn Sessions into checkpointed state. Conversation history that Sessions tracked automatically becomes part of LangGraph's typed state object, now checkpointed at every node so it survives crashes and long pauses.
Decide what happens to tracing. Some teams run both in parallel during the transition, OpenAI's built-in tracing on the SDK-based agents that remain, LangSmith on the newly migrated graph paths, until the migration is complete and they consolidate onto one observability tool.
Keep the front door thin. A pragmatic hybrid many teams land on: OpenAI Agents SDK stays as the conversational entry point and triage layer, and it hands off (via a tool call to a service you control) into a LangGraph-orchestrated workflow for anything durable, auditable, or long-running. This avoids a full rewrite and keeps the fast-to-ship SDK where it is strongest.

The cutover rule in one sentence: start on OpenAI Agents SDK while triage-to-specialist handoffs and fast, OpenAI-native loops are enough to cover your workflow; move the specific paths that are money-adjacent, long-running, audit-sensitive, or need resume-after-crash onto LangGraph, or onto an equivalent durable-execution layer such as a Temporal-class workflow engine, rather than re-architecting everything on day one.

Choose X if

Choose OpenAI Agents SDK if: your workflow is mostly triage, routing, and specialist handoffs, you want the fastest path from prototype to a working production agent, you are already OpenAI-native, and a lost run is a retry, not an incident.
Choose LangGraph if: you are Python-first, run workflows where a lost or corrupted run is expensive, need native multi-day human-in-the-loop pauses, and want an explicit, checkpointed, auditable state at every step.
Choose both if: you have a conversational front door that benefits from fast handoffs and a small number of paths underneath that are genuinely durability-critical. This is the most common production shape we see, not a compromise.

FAQ

Is one of these clearly the better framework? No. They are built to answer different questions. OpenAI Agents SDK is the right shape for "who should handle this conversation right now." LangGraph is the right shape for "what state is this workflow in, and can we prove it, resume it, and pause it for a human." Picking based on features rather than that question usually leads to the wrong tool.

Can I use the OpenAI Agents SDK with other model providers? The docs describe reaching a wide range of other models through a LiteLLM integration, and the SDK is not hard-locked to OpenAI models alone. That said, its deepest and most native capabilities (Responses API features, built-in tools, realtime voice) are OpenAI-specific, so treat multi-provider support as available rather than as proof there is no practical lock-in. Verify current scope against the official docs before committing.

Does LangGraph replace the OpenAI Agents SDK, or sit alongside it? In most real deployments, alongside. Teams commonly keep the SDK as the fast, conversational front door and add LangGraph underneath specifically for the paths that need durable, resumable, auditable execution. Treating this as an either/or decision usually means over-building the simple paths or under-building the critical ones.

Is LangGraph's human-in-the-loop actually different from the SDK's guardrails? Yes. Guardrails validate input and output around an agent's turn and can gate a specific tool call behind approval. LangGraph's interrupt() pauses the entire graph, durably, and can resume from that exact paused state hours or days later. They solve adjacent but different problems; do not assume one substitutes for the other.

What does "durable execution" actually buy us if we never expect a crash? It is less about crashes than about time. Any workflow with a human approval step that might take a day, a retry policy, or a step that legitimately runs for hours needs the same guarantee a crash-resume system needs: pick up exactly where you left off. If any step in your flow can plausibly take longer than a single request-response cycle, you are already in durable-execution territory whether or not anything crashes.

Who can build production agents on either of these for us? Cipher Projects designs and ships production agents on both OpenAI Agents SDK and LangGraph, including the migration path between them when a workflow outgrows handoffs and needs durable, auditable execution. Australian-led with engineering across Australia and Vietnam, serving teams in Australia, Singapore, and worldwide on project-scoped engagements.

We are mid-build on the SDK and worried we picked wrong. What now? Probably nothing drastic. Most SDK builds do not need a full LangGraph rewrite; they need one or two specific paths (usually the ones touching money, long-running jobs, or audit requirements) lifted out and re-architected as a durable graph, while the rest of the system keeps its fast, handoff-based front door.

Conclusion

OpenAI Agents SDK and LangGraph are not competing to win the same race. The SDK is the fastest way to get a well-behaved, OpenAI-native, multi-agent system with handoffs, guardrails, sessions, and tracing into production. LangGraph is the way to get a workflow that can pause for a human, survive a crash, and prove exactly what state it was in when a decision was made. Pick by asking which question matters more for the workflow in front of you, who is in charge right now, or what shape does this computation have, and do not be surprised if the honest answer, for a system with more than one workflow in it, is both.

If your OpenAI Agents SDK prototype is starting to grow the kind of branching, long-running, or audit-sensitive paths that a chat loop was never designed to carry, that gap between "the demo hands off cleanly" and "the workflow survives a Friday-afternoon crash three steps into a human approval" is exactly where an engineering-led migration pays for itself.