LangGraph vs Pydantic AI (2026): Which Agent Framework Should You Use?

**LangGraph's core bet is that agents are state machines**, and that representing them explicitly as graphs makes them easier to reason about, debug, and extend. Every LangGraph program has a `StateGraph` with a typed state schema (a `TypedDict`), a set of nodes that read and write that state, and edges that route between nodes based on the current state. The graph can be cyclic — a node can route back to itself or to a previous node — which is what enables agent loops where the model calls a tool, checks the result, and decides whether to call another tool or return. This is not a metaphor: your agent control flow is literally a directed graph that you can inspect, visualize with `graph.get_graph().draw_mermaid()`, and checkpoint at any node boundary.

**Pydantic AI's core bet is that the right abstraction boundary is the Python type system.** If you define a `Result` model with Pydantic validators, the framework guarantees the agent's output conforms to that model — retry on validation failure is built in. If you define your agent's dependencies as a typed `Deps` dataclass, you inject them at run time and mock them in tests. The framework is intentionally thin: there is an `Agent`, there are `Tool`s, there is a `Result` type, and there is a run loop. That's most of it. Samuel Colvin's explicit goal was to make something that a FastAPI developer would recognize immediately — minimal magic, maximum type coverage.

**These philosophies attract different kinds of builders.** If you are building a complex multi-step pipeline where the routing logic is a first-class concern — where the agent might need to call a tool, branch based on the result, wait for human approval, and then resume hours later — LangGraph's explicit graph model pays off. The routing is visible, debuggable, and modifiable without reading the framework internals. If you are building an agent that needs to return a reliably structured response and you want your editor and mypy to tell you when you break something, Pydantic AI's type-contract model pays off.

**Neither framework is a thin wrapper around a single model provider's SDK.** Both are model-agnostic by design, both support tool calling via a unified interface, and both are actively maintained in 2026. The difference is which dimension of the problem they optimize for: LangGraph optimizes for control-flow expressiveness; Pydantic AI optimizes for type-safety and testability.

**The LangChain heritage matters for LangGraph.** Because LangGraph is built on LangChain 0.4, it inherits LangChain's integrations — hundreds of LLM providers, vector stores, document loaders, and tools. If you are already in the LangChain ecosystem, LangGraph is a natural upgrade from linear chains to cyclic agents. If you are starting fresh with no LangChain investment, you should evaluate whether you want that dependency surface or whether Pydantic AI's leaner dependency tree is preferable.

**Pydantic AI's independence from LangChain is a feature for some teams.** Pydantic itself is a near-universal Python dependency (it's in FastAPI, SQLModel, and most modern Python web stacks), but Pydantic AI the framework is a new dependency with a smaller footprint than the LangChain+LangGraph stack. For teams that have been burned by LangChain's historically unstable API surface, Pydantic AI's smaller, more opinionated design is a selling point.

**LangGraph's `StateGraph` is the central concept you need to understand.** You define a state schema (`TypedDict` with typed fields), add nodes (`graph.add_node('call_model', call_model_fn)`), add edges (`graph.add_edge('call_model', 'call_tool')`), and add conditional edges (`graph.add_conditional_edges('call_model', should_continue, {'continue': 'call_tool', 'end': END})`). Once compiled (`runnable = graph.compile()`), the graph runs as a standard LangChain runnable — you can invoke it, stream it, and batch it. The cycle 'call_model → call_tool → call_model → ... → END' is the canonical ReAct loop, and LangGraph implements it explicitly rather than hiding it inside a framework black box.

**Conditional edges are where LangGraph's power shows up.** The routing function receives the current state and returns a string key that maps to the next node. This is just Python — you can write any routing logic you want, including routing based on tool call results, error types, retry counts, or external API calls. In a pure imperative framework you'd write this as nested if/else; in LangGraph you write it as a named function that returns a routing key, and the graph visualization shows it as a labeled edge. **The graph is a documentation artifact as much as it is executable code.**

**LangGraph 0.5 added first-class support for subgraphs** — a node in one graph can itself be a compiled graph. This enables multi-agent architectures where a supervisor graph routes tasks to specialized subgraphs (a research agent, a writing agent, a review agent), each with their own state and nodes. The subgraph pattern is documented at https://langchain-ai.github.io/langgraph/concepts/multi_agent/ and is the recommended pattern for complex multi-agent systems in 2026.

**Pydantic AI's control flow model is simpler and more linear.** An `Agent` has a system prompt, a result type, and a list of tools. When you call `agent.run(user_prompt, deps=deps)`, the framework runs a loop: send messages to the model, check if the model called a tool, execute the tool, append the result, repeat until the model returns a final response that validates against the result type. You don't define the loop explicitly — the framework handles it. This is the right default for 80% of agents, but it means you are working within the framework's loop model rather than defining your own.

**Pydantic AI does support branching via tools that themselves spawn sub-agents**, but this is compositional rather than graph-based — you write a tool function that calls another `Agent.run()`, which is clean Python but does not give you the visualization, checkpoint, or routing-logic separation that LangGraph provides. For simple agents this is a non-issue; for complex multi-step pipelines where the routing logic needs to evolve independently of the node logic, the difference matters.

**Streaming events from LangGraph** are node-level: you can stream the output of each node as it completes, not just final token output. `astream_events()` gives you `on_chat_model_start`, `on_chat_model_stream`, `on_tool_start`, `on_tool_end`, and `on_chain_end` events — enough to build a real-time UI that shows the agent's step-by-step progress. Pydantic AI's streaming is token-level for the final response and is adding event-level streaming in 0.4.x, but as of June 2026 it is less mature than LangGraph's.

**Pydantic AI's structured-output story is the best in the agent framework class in 2026.** You define your result type as a Pydantic model: `class AnalysisResult(BaseModel): sentiment: Literal['positive','negative','neutral']; score: float = Field(ge=0, le=1); summary: str`. Pass that to the agent: `agent = Agent(model, result_type=AnalysisResult)`. The framework instructs the model to produce output conforming to that schema, validates the response with full Pydantic validation (including validators, ge/le constraints, regex patterns), and **retries automatically if validation fails** — up to a configurable `retries` count with a corrective message to the model explaining what was wrong. This retry-on-validation-failure loop is baked in at the framework level, not something you wire up yourself.

**The type safety extends through the entire call chain.** Your tool functions are annotated with Python types. Your dependency container is a typed dataclass. Your result model is a Pydantic model. When you call `result = await agent.run(prompt, deps=deps)`, the return value `result.data` is typed as `AnalysisResult` — your editor autocompletes its fields, mypy validates usage, and the entire chain is statically checkable. **This is genuinely rare in the agent framework space** — most frameworks return `dict` or `Any` at some boundary.

**LangGraph's type safety is partial.** The state schema is a `TypedDict`, which provides editor hints but not Pydantic-level validation — there is no validator that rejects a state update if the field value doesn't match a constraint. Output parsing is typically done via LangChain's `.with_structured_output(MyModel)` on the LLM object, which does use Pydantic under the hood, but the integration point is the LLM call, not the graph boundary. In LangGraph 0.5, state annotations can include `Annotated[Type, operator]` reducers (for merging state updates), which is powerful for multi-agent state management but is not the same as Pydantic validation.

**For structured-output agents** — agents whose entire job is to take unstructured input and return a validated structured response — Pydantic AI is the more natural choice. The `result_type` pattern maps directly to the problem. For orchestration agents — agents that run multi-step pipelines, call multiple tools, branch based on results, and eventually synthesize a final answer — LangGraph's state + graph model is a better fit even if the type safety is less strict.

**Pydantic AI's validators run on tool arguments too.** When the model calls a tool, the tool's function signature (with type annotations and Pydantic Field validators) is the validation layer for the arguments. If the model passes an out-of-range value, the validator fires before your tool code runs, and the error is fed back to the model for correction. This closes the loop on structured data flow through the entire agent, not just the final response.

**A practical callout for teams migrating from ad-hoc prompting**: if your current agent code has a lot of `json.loads(response.content)` calls followed by `.get('field', default)` defensive code, Pydantic AI's `result_type` pattern will cut that boilerplate dramatically. The structured output is guaranteed at the framework level — you don't write parsing and fallback code, you write a Pydantic model.

**Human-in-the-loop is a first-class primitive in LangGraph, and this is one of its most distinctive capabilities.** LangGraph's `interrupt()` function (introduced in LangGraph 0.2 and matured in 0.5) lets any node pause execution, surface information to a human reviewer, and wait for a response — then resume from exactly where it paused, with the full graph state intact. The mechanism uses the checkpointing system under the hood: when `interrupt()` is called, the current state is checkpointed, the run is suspended, and the thread ID is returned to the caller. When the human provides input (via `Command(resume=human_input)`), the graph resumes from the checkpoint. **No external queue, no polling loop — the graph handles it natively.**

**The practical implications of this are large.** You can build agents that draft an email and wait for approval before sending. You can build agents that flag low-confidence tool calls for human review. You can build agents that pause on ambiguous inputs and ask a clarifying question through a UI, then resume when the user responds. All of this without building a separate state machine around the agent — the agent's graph IS the state machine. The LangGraph docs cover the interrupt pattern in depth at https://langchain-ai.github.io/langgraph/concepts/human_in_the_loop/.

**Pydantic AI does not have a built-in human-in-the-loop primitive.** If you need approval gates in a Pydantic AI agent, you build them yourself: call the agent, inspect the result, route to a human reviewer in your application layer, and call the agent again with the additional context. This is perfectly workable for simple approval flows, but for complex workflows with multiple potential interrupt points, multiple reviewer types, and resume semantics, you are building infrastructure that LangGraph provides out of the box.

**LangGraph's interrupt supports multiple interrupt types.** You can interrupt before a node, after a node, or at a specific point inside a node. You can interrupt to request approval, to request additional information, or to correct the agent's plan before it continues. The `NodeInterrupt` exception (raise it inside any node) gives you fine-grained control. Multiple interrupts can be queued before the graph is resumed, which supports batch approval workflows.

**For enterprise workflows where human oversight is a compliance requirement** — financial transactions, medical recommendations, legal document generation — LangGraph's interrupt/checkpoint architecture is not optional. You need auditability (which checkpoint provides), human approval gates (which interrupt provides), and resume semantics (which the thread/state model provides). Pydantic AI can be made to work for these use cases but requires substantially more scaffolding.

**A note on LangGraph Studio**: LangGraph AI ships LangGraph Studio (https://studio.langchain.com), a desktop debugging tool that visualizes the graph, shows state at each node, and lets you replay or modify runs. The Studio integrates with the interrupt/checkpoint system — you can inspect a paused run, modify its state, and resume it. This is not available for Pydantic AI, which relies on Logfire traces for observability but does not have an equivalent interactive graph debugger.

**LangGraph has a built-in, first-class checkpointing system that is one of its most production-relevant features.** A checkpointer is a backend-agnostic store for graph state: it writes the full state after every node execution, indexed by `thread_id` and `checkpoint_id`. LangGraph 0.5 ships three built-in checkpointer backends: `SqliteSaver` (for development and single-server deployments), `AsyncPostgresSaver` (for production with `psycopg3`), and `RedisSaver` (for high-throughput distributed deployments). The API is identical across all three — swap backends by changing one import. **This means your agent automatically gains persistence, resumability, and multi-turn memory** with zero application-level persistence code.

**Thread-level memory** in LangGraph works via the `thread_id` parameter: pass the same `thread_id` across multiple invocations and the agent has access to all prior state in that thread. This is the correct abstraction for conversational agents: each conversation is a thread, and the agent's state accumulates across turns. For cross-thread memory (facts learned in one conversation that should be available in all future conversations), LangGraph 0.5 introduced the `MemorySaver` with cross-thread namespace support — you write facts to a shared namespace and all threads can read them.

**LangGraph's checkpointing also enables time-travel debugging.** Every state snapshot is stored, so you can roll back to any prior checkpoint (`graph.get_state_history(config)` gives you the full history), replay a run from a specific node, and branch an alternate execution from any historical state. This is invaluable for debugging complex agent failures — instead of trying to reproduce the failure condition, you load the checkpoint and replay from the point of failure.

**Pydantic AI does not have a built-in checkpointer.** Conversation history (`message_history`) is passed explicitly to each `agent.run()` call — you maintain the list of `ModelMessage` objects and pass them in. This is simple and explicit, which is the Pydantic AI philosophy, but it means you are responsible for storing and retrieving conversation history. For a simple chatbot backed by a database, this is a few lines of code. For a multi-step pipeline that needs to survive process restarts, you are building a persistence layer that LangGraph provides.

**The practical gap here** is most visible for long-running agents. An agent that runs for 30 minutes, calls 50 tools, and might need to resume after a process restart: LangGraph handles this natively via checkpointing. Pydantic AI requires you to build a persistence strategy, a resume protocol, and a state reconstruction layer. Teams building workflows that run longer than a single HTTP request lifespan should weight this difference heavily.

**LangGraph's persistence layer also enables multi-agent memory sharing.** In a multi-agent LangGraph setup (supervisor + subgraphs), all agents operate on the same checkpointed state, so information gathered by one subgraph is immediately available to all others. In Pydantic AI, information sharing between agents is via explicit function arguments — which is clean but manual. For complex multi-agent workflows where agents need to build on each other's work, LangGraph's shared state model reduces coordination overhead.

**Both LangGraph and Pydantic AI support OpenAI, Anthropic Claude, Google Gemini, Groq, and Ollama** out of the box in their 2026 versions. Both expose tool calling (function calling) through a unified interface — you define a tool once and it works regardless of which underlying model you switch to. **Model-switching is a genuine one-line change in both frameworks** for the standard providers: change the model string and nothing else in your agent code needs to change.

**LangGraph inherits LangChain's model integrations**, which are the most comprehensive in the Python ecosystem. Any model with a LangChain integration (and there are hundreds) works as a LangGraph node. This includes every major cloud provider, dozens of local inference backends (Ollama, LM Studio, vLLM), and specialty providers. The downside of this breadth is that integration quality varies — the tier-1 providers (OpenAI, Anthropic, Google) have first-class support, the tier-2 providers have community-maintained integrations of varying quality.

**Pydantic AI's model support is narrower but deeper.** The framework ships first-class, vendor-maintained integrations for OpenAI, Anthropic, Google (Gemini + Vertex AI), Groq, Mistral, Cohere, and Ollama as of 0.4.x. Each integration is tested against the live API in CI. The narrower surface means higher quality — edge cases like streaming tool calls, vision inputs, and structured-output mode are explicitly tested for each supported provider.

**Model fallback and routing** is an application-layer concern in both frameworks — neither has built-in failover (e.g., 'if GPT-4o fails, retry with Claude'). In LangGraph you'd implement this as a conditional edge that catches exceptions and routes to a fallback model node. In Pydantic AI you'd wrap `agent.run()` in a try/except and instantiate a second agent with a different model. Both approaches work; neither is ergonomic enough to qualify as a 'feature.' For production reliability you probably want a gateway like LiteLLM in front of both.

**Cost tracking per model** is an area where Pydantic AI has a slight edge. `result.usage()` returns a `Usage` object with `requests`, `request_tokens`, `response_tokens`, and `total_tokens` — directly from the run result, no external tracing needed. LangGraph's per-call token usage is available via callbacks and LangSmith, but there is no clean `result.usage` equivalent built into the framework primitives. For teams that need per-call cost attribution in the application layer (not just in a tracing dashboard), Pydantic AI's approach is more convenient.

**Both frameworks support multi-modal inputs** (images, audio where the underlying model supports it) by passing the appropriate message types to the model. Neither framework has special handling for multi-modal beyond forwarding the right content types — the complexity lives in the model provider's API, not the framework.

**Testing is where Pydantic AI's design philosophy delivers the most tangible day-to-day developer benefit.** The dependency injection pattern — where your agent's external dependencies (database connections, HTTP clients, API keys) are declared as a typed `Deps` dataclass and injected at `agent.run(deps=deps)` — means testing is exactly the same as writing a FastAPI test: provide a mock `Deps` instance, run the agent, assert on the result. No monkey-patching, no environment variable overrides, no framework-internal mocking required.

**Pydantic AI ships `TestModel` and `FunctionModel`** as first-class test utilities (https://ai.pydantic.dev/testing-evals/). `TestModel` is a fake LLM that returns deterministic, configurable responses — use it when you want to test the agent's tool-call handling logic without burning real API tokens. `FunctionModel` lets you supply a Python function as the 'model' — give it the conversation history and return any `ModelResponse` you want. Together, these make it possible to write fully hermetic unit tests for agents: zero API calls, zero network, deterministic, fast. **This is the most important testing feature in the agent framework space in 2026 and it is unique to Pydantic AI.**

**A concrete example**: an agent that fetches a URL, summarizes the content, and stores the summary in a database. In Pydantic AI, your `Deps` dataclass has `http_client: httpx.AsyncClient` and `db: DatabaseConnection` fields. In your unit test, you inject `MockHttpClient` and `MockDatabase`. You use `FunctionModel` to return a deterministic summary. The test runs in milliseconds, asserts on the database write, and never touches the network or a real model. In LangGraph, achieving the same level of isolation requires patching `langchain_core` internals or wrapping every external call in an injectable function — doable but not supported as a first-class framework pattern.

**LangGraph's testing story relies on standard Python mocking patterns.** The `@pytest.mark.asyncio` + `unittest.mock.patch` + LangChain's `FakeListChatModel` (a simple fake that returns canned messages) is the common approach. `FakeListChatModel` is functional — you give it a list of responses and it returns them in order — but it does not have the structured-output validation awareness of Pydantic AI's `TestModel`. If your agent uses `.with_structured_output(MyModel)`, your test needs to account for that parsing layer, which `FakeListChatModel` does not handle automatically.

**Integration testing** (testing the full agent against a live model and real tool calls) is similar in both frameworks: you run the agent with real credentials against a test fixture and assert on the result. LangGraph has a slight edge here because LangSmith (see the observability section) captures the full trace of the integration test run, making debugging failures easier than stepping through Pydantic AI traces in Logfire.

**For teams with high code-quality standards — type coverage requirements, hermetic CI, test coverage gates** — Pydantic AI's testing infrastructure makes agents first-class citizens of the codebase rather than special-case code that is hard to test cleanly. If your team already uses pytest + mypy + Pydantic V2 throughout the stack, Pydantic AI slots in with minimal friction. LangGraph's testing story is adequate but not differentiated.

**LangGraph integrates natively with LangSmith** (https://www.langchain.com/langsmith), the observability and evaluation platform from LangChain AI. Set `LANGCHAIN_TRACING_V2=true` and `LANGCHAIN_API_KEY` in your environment and every LangGraph run is automatically traced — full message history, tool calls, node transitions, latency per node, token counts, and the complete state at each checkpoint. No code changes required. The trace appears in the LangSmith dashboard as an interactive timeline where you can expand any step and see the exact inputs and outputs.

**LangSmith pricing**: the free tier covers up to 5,000 traces per month with 14-day retention. Beyond that, it is $0.005 per trace (approximately — see https://www.langchain.com/langsmith for current pricing). For a production agent running 100 traces/day (30 tools calls per trace average), you are at ~3,000 traces/month — comfortably within the free tier. At 1,000 traces/day you are at ~$150/month. The pricing is per trace (one agent invocation = one trace), not per span or per token, which makes costs predictable. **LangSmith is the most mature observability platform for LangChain-based agents** and its tight integration with LangGraph (including state visualization and time-travel replay) is a genuine competitive advantage.

**LangSmith also ships an evaluation framework** (datasets, experiments, LLM-as-judge scoring) that integrates directly with LangGraph traces. You can create a dataset from production traces (flagging interesting examples), run your agent on the dataset with a new prompt or model version, and compare results side-by-side. For teams doing systematic agent quality improvement, this evaluation loop is valuable. There is no Pydantic AI equivalent — Pydantic AI's evaluation story is 'use your own framework, here are the primitives.'

**Pydantic AI integrates natively with Pydantic Logfire** (https://pydantic.dev/logfire), the observability platform from the Pydantic team. Logfire is an OpenTelemetry-based tracing platform with a strong Python integration story — it captures Pydantic model validations, tool calls, agent runs, and HTTP client calls (via httpx instrumentation) in a unified trace. The `logfire.instrument_pydantic_ai()` one-liner enables instrumentation across all agents in your application.

**Logfire's pricing model** is consumption-based (bytes ingested + storage), with a generous free tier for small teams. As of June 2026, Logfire is newer and smaller than LangSmith — the dashboard is clean and the traces are readable, but the specialized agent debugging features (state diff between steps, time-travel replay, agent-specific evaluation tools) are not as mature as LangSmith's. Logfire's strength is the broader OpenTelemetry ecosystem — if you already have OpenTelemetry infrastructure, Logfire integrates with your existing stack more cleanly than LangSmith.

**Both frameworks support OpenTelemetry export** beyond their native platforms. LangGraph via LangChain callbacks, Pydantic AI via Logfire's OTel export. If you are running a centralized OTel backend (Jaeger, Tempo, Honeycomb, Datadog APM), you can send traces from both frameworks there. For teams with existing observability infrastructure, neither framework requires you to adopt a new tracing platform — but both have native platforms that are worth evaluating, especially LangSmith for LangGraph.

**Pick LangGraph when your agent's control flow is a first-class engineering concern.** If you are building a multi-step pipeline where routing logic is complex — branch on tool results, retry on failure, escalate to human on low confidence, merge parallel sub-agents — LangGraph's explicit graph model pays for its complexity. The graph is inspectable, the routing logic is named and isolated from the node logic, and the checkpointing is built in. You are not just getting an orchestration framework; you are getting a complete agent runtime with persistence, visualization, and human-in-the-loop semantics.

**Pick LangGraph when human-in-the-loop or long-running persistence are requirements.** These are not features you can easily retrofit onto a framework that does not have them. If your agent needs to pause and wait for human approval, or if it runs for minutes-to-hours and needs to survive process restarts, LangGraph's interrupt/checkpoint system is not optional. Build on LangGraph from the start for these use cases rather than building the infrastructure yourself on top of Pydantic AI.

**Pick Pydantic AI when type safety and testability are your top priorities.** If your team has strong mypy discipline, existing Pydantic V2 usage, and high unit test coverage requirements, Pydantic AI fits naturally into your quality practices. **The `TestModel` + `FunctionModel` + typed `Deps` injection pattern is the best-in-class testing story for agents in 2026**, and it will pay dividends every sprint in terms of fast, reliable CI. LangGraph's testing story is adequate but you will build more scaffolding yourself.

**Pick Pydantic AI when structured output is the core deliverable.** Classification pipelines, extraction pipelines, structured report generation, API response validation — workloads where the agent's entire job is to convert unstructured input into a validated structured output are what Pydantic AI was designed for. The result_type + retry-on-validation loop is cleaner than anything you can build on LangGraph without adding LangChain's structured output layer explicitly.

**For simple conversational agents or single-step tool-use agents, Pydantic AI's lower complexity is a net win.** LangGraph's graph model introduces boilerplate (define state, add nodes, add edges, compile) that is not justified if your agent is a single 'call model, maybe call a tool, return result' loop. Pydantic AI's `Agent(model, tools=[...], result_type=MyResult)` is the right amount of framework for that use case.

**The 'use both' answer is also valid.** Nothing prevents a LangGraph node from instantiating and running a Pydantic AI agent for a specific subtask — call a Pydantic AI agent for structured extraction within a LangGraph node that handles the broader orchestration. This hybrid pattern lets you use each framework where it is strongest: LangGraph for complex control flow and persistence, Pydantic AI for type-safe structured output on specific nodes. **The two frameworks are composable, not mutually exclusive.**