LangGraph vs Pydantic AI

LangGraph and Pydantic AI can both build serious agent systems, yet they approach the problem from different directions. LangGraph is a graph-based orchestration framework for stateful, controllable workflows. Pydantic AI is a Python agent framework from the Pydantic team. It emphasizes typed agents and structured outputs, adds dependency injection and validation, and aims for a developer experience aligned with modern Python application code.

The official LangGraph overview explains LangGraph's role in orchestrating stateful agent workflows. The official Pydantic AI documentation explains Pydantic AI's typed agent framework. The practical choice depends on whether the hard part of the system is workflow control or typed agent construction.

The short answer

Choose LangGraph when the workflow needs explicit state, branching, loops, persistence, human review, or multi-agent orchestration. Choose Pydantic AI when the core need is typed Python agents with strong schema validation and structured results, built with dependency injection into maintainable application code.

These are not mutually exclusive in every architecture, but they occupy different mental models. LangGraph asks, "How does state move through this workflow?" Pydantic AI asks, "How do we define this agent cleanly, from its typed dependencies and tools to its validated outputs?"

What each framework is

LangGraph models agent workflows as graphs. Nodes perform work, edges route execution, and state moves through the graph. Developers get explicit control over the shape of the workflow, which matters once the process turns complex. A research workflow may loop until sources are sufficient. A claims workflow branches on missing documents. A legal review workflow pauses for human approval. A customer support workflow might retry a failed tool call, escalate to a person, or resume after an external event. The framework is strongest when the agent system behaves like a stateful workflow rather than a single model call.

Pydantic AI takes a different starting point: typed application development. It uses concepts familiar to Python teams that already rely on Pydantic: schemas with type hints, and validation of structured data. The docs walk through agents, tools and dependencies first, then model interactions and typed outputs.

The payoff is developer discipline. When an agent must return a structured object, call typed tools, or operate with explicit dependencies, Pydantic AI makes the code easier to validate and reason about. That value rises when agent output feeds another system rather than only a human reader. The point goes beyond output parsing; the goal is agent code that reads like well-structured Python application code.

How they differ

The difference surfaces during design. A diagram full of branches and checkpoints, where work loops back, points toward LangGraph, which speaks directly to that shape. A system whose central worry is a validated return object and typed tool dependencies points toward Pydantic AI instead.

The two mental models look different even at a glance:

When to choose each

Reach for LangGraph in workflows where the execution path matters. Multi-step research agents and multi-agent coordination are good examples. So are human-in-the-loop review systems and business workflows with routing and retries. Any process that needs durable state, with observability around its transitions, belongs here too.

LangGraph earns its place when the team needs to say, "Here are the states, here are the allowed transitions, and here is what happens when a node fails."

Reach for Pydantic AI when correctness at the agent interface matters. Good examples include:

• Agents that must return structured, validated data.
• Python services where type hints and Pydantic models are already standard.
• Tool-heavy agents that benefit from explicit dependencies.
• Workflows where model output feeds deterministic downstream code.
• Teams that want agent definitions to feel like normal Python application code.

Pydantic AI fits teams that value typed contracts around model behavior. Those contracts do not make the model deterministic, but they do make the application boundary clearer.

Combining the two is possible when the architecture justifies it. A LangGraph node could call code that uses a typed agent pattern, or a Pydantic AI agent could sit inside a larger workflow system. The decision should be deliberate, because every added framework layer brings more dependencies and abstractions, and widens the debugging surface. For most teams the cleaner answer is to pick the framework that matches the dominant complexity. If the workflow is the hard part, start with LangGraph. If typed agent interfaces are the hard part, start with Pydantic AI.

Pydantic AI supports TypeSafe's Jev directly

Pydantic AI ships a TypeSafeModel class for Jev, TypeSafe's model for typed questions (model id typesafe:jev-latest). Jev answers yes/no, pick-one and score questions and never writes free text. Each field of your output type comes back with an answer and a confidence score.

The catch is the str field. In the words of the Pydantic AI docs, "Jev does not write text, so a route with a str field escalates to a language model".

You wire that up with FallbackModel, so typed fields go to Jev and free-text fields go to a model that can write. The same page lists three limits. A pick-one question takes at most 255 options, and a score at most 10 levels. Context is capped at 32,000 tokens for the state plus the longest question.

For the framework choice, this counts toward Pydantic AI when the work is mostly classification: routing, labelling, triage, yes/no checks. If most of an agent's output is typed values, Pydantic AI already knows how to hand them to Jev. It does not change the orchestration argument. A workflow full of branches and human checkpoints still points to LangGraph. How to use Jev covers how to ask it good questions.

Common mistakes and adoption

Three errors recur. The first is reaching for LangGraph to fix structured output validation. A graph does not automatically make outputs safe or typed. Validation stays the team's job, through schemas and tests.

The second is reaching for Pydantic AI to fix workflow state. A typed agent can be well designed and still sit inside a messy orchestration loop when the process itself is never modeled.

The third is confusing validation with truth. A Pydantic model validates shape, not factual correctness. Retrieval and source checks still matter, and so do evals and human review.

A useful starting move is to draw two sketches. The workflow sketch shows the states and where they branch, loop or wait for a person. The data contract sketch shows inputs and outputs, plus the tools and validation rules between them. Whichever sketch carries more complexity points to the framework worth evaluating first.

When the workflow sketch is the source of risk, build a small LangGraph graph that includes at least one branch, one failure path, and one state persistence concern. When the data contract sketch carries the risk, build a small Pydantic AI agent. It should return the exact structured object downstream code needs and fail safely on ambiguous input.

At XY Space, orchestration tooling is usually chosen by the operational shape of the system. LangGraph wins when a client needs a visible workflow engine for agent behavior. Pydantic AI wins when a Python system needs typed agent boundaries and structured outputs that downstream code can trust after validation and review.

Sources

• LangGraph overview
• Pydantic AI documentation
• Pydantic AI: TypeSafe (Jev)