LangChain vs LangGraph vs OpenAI Agents SDK vs Pydantic AI

Bottom line

The useful distinction is not which framework can call a tool. All four can support tool-using applications. The decision is where control lives after the first model response: in a high-level agent loop, an explicit state graph, a compact SDK runner, or a typed application service.

LangChain is the broadest starting point when a team values integrations and conventional agent abstractions. LangGraph is the strongest fit when execution must pause, resume, branch, persist state, or expose a human review point. OpenAI Agents SDK is attractive when a Python team wants a deliberately small set of primitives around agents, tools, handoffs, guardrails, sessions, and tracing. Pydantic AI fits teams that want model calls and agent dependencies to behave like typed application code.

Semantic Kernel and AgentScope are useful reference points even though they are not in the four-product headline. Semantic Kernel deserves attention in Microsoft-oriented .NET and Python estates. AgentScope is relevant when multi-agent visibility and experimentation matter. Neither should be added merely to make a shortlist look complete.

Compare the responsibility boundary

Framework	Primary abstraction	State and control	Strongest fit	Team still owns
LangChain	High-level agents, tools, middleware, integrations	Agent loop with configurable middleware and integrations	Teams that want a broad ecosystem and fast composition	Task design, persistence choices, evaluation, deployment
LangGraph	Nodes, edges, shared state, checkpoints	Explicit graph transitions, durable execution, interruption	Long-running or reviewable workflows	Graph design, state schema, failure policy, operating model
OpenAI Agents SDK	Agent, Runner, tools, handoffs, guardrails	Managed loop, sessions, tracing, handoff patterns	Python teams using OpenAI capabilities and a compact runtime	Tool safety, test sets, model cost, application deployment
Pydantic AI	Typed agents, dependencies, tools, outputs	Python control flow with validation and typed context	Typed services and structured business outputs	Persistence, orchestration conventions, deployment, monitoring

This table describes product direction from official documentation reviewed on July 11, 2026. It is not a benchmark. A framework can support a capability without making that capability inexpensive or operationally complete.

When LangChain is the pragmatic choice

LangChain makes sense when the first constraint is integration breadth. A team may need to switch model providers, connect retrieval components, expose tools, add middleware, and use familiar abstractions without designing a graph immediately. Its value is compositional reach, not that every integration will behave consistently under production load.

The risk is accidental architecture. A prototype can accumulate chains, agents, callbacks, and provider-specific behavior before the team has defined state or failure semantics. If a run can last minutes, mutate external systems, or require approval, treat persistence and interruption as first-class design work. At that point LangGraph may become the clearer runtime beneath or beside LangChain components.

When LangGraph earns its complexity

LangGraph’s official documentation positions it as a low-level orchestration framework for long-running, stateful agents. Its graph consists of state, nodes, and edges. That is more ceremony than a simple agent loop, but the ceremony makes transitions inspectable.

Choose it when a workflow must recover after failure, wait for a person, preserve state across steps, stream progress, or route through deterministic branches. Do not choose it because graphs look architectural. A short extraction or support-drafting task may be easier to understand as ordinary application code.

A good LangGraph design has a compact state schema and named transition rules. A weak one stores an unbounded transcript, hides side effects inside nodes, and treats every model decision as an edge. The framework cannot rescue a workflow whose state has no owner.

When OpenAI Agents SDK is enough

OpenAI Agents SDK intentionally exposes few primitives. Agents carry instructions and tools; handoffs or agents-as-tools coordinate specialists; guardrails validate inputs or outputs; sessions carry working context; tracing records runs. This can be enough for substantial applications without introducing a separate graph model.

The SDK is a strong fit when the team already uses Python and OpenAI models, wants built-in tracing, and prefers to express orchestration in code. It is less attractive when provider neutrality is mandatory or when the application needs a vendor-independent execution layer. The official SDK supports customization, but architectural portability is broader than swapping a model client.

Guardrails also need careful interpretation. A guardrail is a mechanism for validation, not proof that a workflow is safe. Tool permissions, credential scope, sandboxing, and post-action verification remain application concerns.

When Pydantic AI fits the codebase

Pydantic AI treats agent development as typed Python application development. Dependencies can be injected, tool arguments validated, and outputs represented as models. This is especially useful when an agent’s result must enter a business process rather than end as prose.

Choose it when structured outputs and testable Python interfaces are more important than a visual orchestration model. It can also reduce the temptation to pass loosely shaped dictionaries through every stage. The tradeoff is that teams must still choose how runs persist, retry, queue, and deploy. Type safety catches malformed data; it does not establish factual correctness.

A selection exercise that exposes the answer

Write one representative run as a sequence of observable events. Include model calls, tool calls, state changes, approvals, retries, and the final side effect. Then answer five questions:

1. Must a run resume after process failure or a long human delay?
2. Does the team need an explicit graph that reviewers can inspect?
3. Are typed inputs and outputs central to the surrounding service?
4. Is the application committed to OpenAI’s runtime capabilities, or must the runtime remain provider-neutral?
5. How will a failed tool call be retried without repeating a successful side effect?

If durable state and interruption dominate, start with LangGraph. If typed service boundaries dominate, test Pydantic AI. If a compact OpenAI-oriented runtime is acceptable, test the Agents SDK. If integration breadth and higher-level composition dominate, start with LangChain and define the point where graph orchestration becomes necessary.

Build a fair framework trial

Use the same three tasks in each candidate. One should complete successfully, one should encounter a recoverable tool failure, and one should require human refusal or correction. Instrument model requests, tool arguments, outputs, state transitions, latency, and token cost. Restart the process midway through the long task. Change a tool schema. Feed an invalid structured result.

Score the framework on how clearly the team can explain the run, not on the fewest lines in a quickstart. Record how much application code is required for idempotency, persistence, authorization, and tests. The winning prototype is the one whose failures are easiest to reproduce and whose ownership boundary is easiest to describe.

Limitations and verification notes

Framework APIs move quickly. Semantic Kernel documentation, for example, marks some orchestration capabilities as experimental or language-specific. Hosted tracing and deployment products may have terms separate from open-source framework licenses. Model usage is also a separate cost from framework code.

Before adoption, verify the current release, license, supported language, model compatibility, persistence backend, tracing behavior, and data handling in the official sources. Do not infer production readiness from GitHub stars or a successful notebook.

State, retries, and side effects

The most revealing implementation question is how a framework represents a run after something fails. A model call can usually be retried. A tool call may not be safe to repeat. Sending an email, filing a ticket, charging a card, or merging a change creates an external state that the framework cannot roll back by itself.

Define an operation identifier before a side effect and store the result independently of the model transcript. On resume, the application checks that record before acting again. LangGraph checkpoints can help preserve workflow state, but the node still needs idempotency. An Agents SDK session can preserve conversation context, but a session is not a transaction ledger. Typed Pydantic output can validate the requested action, but application code must authorize and record it. LangChain middleware can intercept behavior, but the underlying tool needs a safe contract.

Test retry semantics explicitly. Stop the process after a tool succeeds but before the agent receives the result. Restart from persisted state and observe whether the tool runs twice. Repeat the test at each consequential boundary. This exercise often matters more than the framework’s happy-path ergonomics.

Observability and evaluation fit

Framework-specific tracing is useful because it understands native objects, but keep a portable event model as well. At minimum record run ID, parent step, model, tool, sanitized arguments, result status, latency, token usage, state transition, and approval. Export or mirror the events to a system the operations team already owns.

LangGraph integrates closely with LangSmith for graph-aware traces and evaluation. OpenAI Agents SDK includes built-in tracing and connects naturally to OpenAI’s evaluation tools. Pydantic AI documents instrumentation within its typed Python ecosystem. LangChain has middleware and observability integrations. Compare what is available in the open-source package with what requires a hosted service, and verify retention and pricing separately.

Create evaluations outside the framework. The same task record should run against each candidate and produce a normalized result. Otherwise a migration also discards the evidence used to justify the original choice.

Security review questions

Ask how tools are registered, described, enabled, and scoped per run. Determine whether untrusted content can influence tool selection or arguments. Review how secrets enter the runtime and whether traces may capture them. Confirm that a user identity and authorization context remain available through handoffs, graph nodes, background work, and resumed sessions.

Guardrails and middleware are appropriate places for policy checks, but policy should not depend only on another model call. Enforce deterministic limits for allowed domains, file paths, command classes, spending, and data access. Require a fresh authorization decision at the tool boundary.

For multi-agent systems, decide whether a specialist receives the full transcript or only a task-specific context package. Handoffs can improve specialization while increasing data exposure. Record which agent saw which source and why.

Migration and lock-in

Framework migration is easiest when the application owns tool schemas, task records, domain models, and evaluation cases. Keep provider clients and framework objects behind small adapters. Avoid storing only opaque serialized runtime state if long-term portability matters.

Run a migration drill before committing. Rebuild one representative task in the second-choice framework and count the code that must change. If tools, permissions, and evaluations transfer cleanly, lock-in is bounded. If business rules are embedded across callbacks or graph nodes, budget for that coupling honestly.

Provider-specific features may still be worth using. Lock-in is a trade, not an automatic failure. The team should be able to name what it receives in exchange: lower implementation effort, better tracing, a managed sandbox, or access to a required model capability.

Cost model

Framework license cost is usually a small part of agent ownership. Estimate model tokens, repeated planning steps, tool infrastructure, vector or state storage, trace retention, sandbox compute, engineering maintenance, and human review. Graphs with many model-driven nodes may cost more than a compact loop. A high-level agent may retry invisibly unless limits are configured.

Track cost per verified successful task, not cost per request. Include failures and reviewer time. Set budgets for steps, tokens, wall-clock duration, and tool calls in the runtime. A framework is easier to operate when those budgets are visible and enforceable.

Procurement and maintenance record

For every candidate, record the open-source license, current maintainers, release cadence, security reporting process, supported Python or .NET versions, model-provider compatibility, and any hosted services the architecture assumes. Identify which capabilities are stable and which are experimental.

Schedule a quarterly review after adoption. Re-run the task set, inspect deprecated APIs, review trace retention, and confirm that tool permissions still match the workflow. Framework evolution is normal; unmanaged evolution is the risk.

Source record

The comparison used the official LangChain and LangGraph documentation, OpenAI Agents SDK documentation, Pydantic AI documentation, and Microsoft Semantic Kernel documentation. Sources were reviewed July 11, 2026. Claims are limited to documented architecture and interfaces; no independent latency or accuracy benchmark is claimed.

Decision

Choose the smallest runtime that makes failure, state, and review explicit for the actual workflow. A high-level loop is not immature when the task is short. A graph is not over-engineering when a run must survive interruption. Typed outputs are not enough when the underlying facts are wrong. The durable advantage comes from an execution model the team can test and operate after the demo is gone.