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

If you only remember one thing: Pydantic AI is a great default; LangGraph is what you graduate to. Reach for Pydantic AI when the agent is basically "prompt in, tools, structured result out." Reach for LangGraph when your workflow is a real state machine — it pauses for human approval, recovers from a crashed server mid-run, fans out into parallel branches, or needs an audit trail of every step.

Both are Python-first, both are actively maintained (LangGraph hit v1.0 in late 2025 and is now on the 1.2.x line; Pydantic AI shipped its v2 in June 2026), and — worth saying up front — they aren't mutually exclusive. Plenty of teams run a Pydantic AI agent *as a node inside* a LangGraph graph. But when you're choosing the primary framework, the decision is about workflow shape.

To make the comparison fair I picked a task both frameworks should handle well: a support-ticket triage agent. It takes a ticket, calls one tool (look up the customer's paying tier), and returns a structured result — a category, a 1–5 priority, and a needs_human flag. Here it is in Pydantic AI:

from dataclasses import dataclass
from pydantic import BaseModel, Field
from pydantic_ai import Agent, RunContext
from pydantic_ai.models.test import TestModel

class Triage(BaseModel):
    category: str = Field(description="billing | technical | account | other")
    priority: int = Field(ge=1, le=5)
    needs_human: bool

@dataclass
class Deps:
    customer_id: str

agent = Agent(
    TestModel(),            # in prod: 'openai:gpt-4o' / 'anthropic:...'
    deps_type=Deps,
    output_type=Triage,     # <- this is the whole "structured output" story
    system_prompt="Triage the support ticket. Use tools when useful.",
)

@agent.tool
def customer_tier(ctx: RunContext[Deps]) -> str:
    """Look up the paying tier of the current customer."""
    return {"c_1": "enterprise", "c_2": "free"}.get(ctx.deps.customer_id, "unknown")

result = agent.run_sync("I was charged twice!", deps=Deps(customer_id="c_1"))
print(type(result.output).__name__, result.output)

Run it and the output is already a validated object — not a dict, not a string you have to parse:

output type : Triage
validated   : category='a' priority=1 needs_human=False
is Triage   : True

(The values are dummies because TestModel doesn't run a real LLM — but note priority=1 still satisfies the ge=1, le=5 constraint. The framework guarantees the shape.) You declare output_type=Triage and Pydantic AI handles the tool-call round-trip to coerce the model's output into a validated Triage for you. That's the entire mechanism.

Now the same agent in LangGraph. Because LangGraph is a graph framework, you describe the workflow as nodes and edges — a model node, a tool node, and the routing between them:

class State(TypedDict):
    messages: Annotated[list, add_messages]
    customer_id: str
    result: Triage | None

def call_model(state):
    return {"messages": [model.invoke(state["messages"])]}

def run_tool(state):
    call = state["messages"][-1].tool_calls[0]
    out = customer_tier(**call["args"])
    return {"messages": [ToolMessage(content=out, tool_call_id=call["id"])]}

def finalize(state):
    # LangGraph does NOT validate for you — you parse the text yourself.
    return {"result": Triage(**json.loads(state["messages"][-1].content))}

def route(state):
    return "tools" if state["messages"][-1].tool_calls else "final"

g = StateGraph(State)
g.add_node("model", call_model)
g.add_node("tools", run_tool)
g.add_node("final", finalize)
g.add_edge(START, "model")
g.add_conditional_edges("model", route, {"tools": "tools", "final": "final"})
g.add_edge("tools", "model")
g.add_edge("final", END)
app = g.compile(checkpointer=MemorySaver())   # <- durability, for free

Both agents above actually run — I executed them offline with each framework's fake/test model so no LLM was called. Here's everything I measured, on Python 3.14, fresh virtual environments:

Two footnotes on the install numbers, because they're the most surprising and the most misread:

• \* Pydantic AI has two packages. pip install pydantic-ai-slim gives you the core in 21 packages / 45 MB — but no model provider; you add exactly the ones you need (pydantic-ai-slim[openai], [anthropic], etc.). The slim package won't even let you *reference* 'openai:gpt-4o' until you install that extra — I hit that ImportError in testing. That's a deliberate, honest trade-off: small by default, you opt in.
• \*\* The plain `pip install pydantic-ai` is heavy. It's the batteries-included meta-package that pulls every model provider — OpenAI, Anthropic, Google, Groq, Mistral, Cohere and more — landing at 102 packages / 217 MB. If you care about footprint (serverless, containers), install pydantic-ai-slim[your-provider], not pydantic-ai.
• LangGraph's 56 MB also excludes a provider. LangGraph depends on langchain-core but not on any LLM client — you add langchain-openai / langchain-anthropic separately, same as Pydantic AI's extras. So the fair, provider-free comparison is 45 MB (Pydantic AI slim) vs 56 MB (LangGraph) — closer than the headline 217 MB number suggests.

This is Pydantic AI's home turf, and it shows. Because it's built by the team behind Pydantic, validation isn't a bolt-on — it *is* the framework. You define your result as a BaseModel, pass it as output_type, and every run comes back as a validated instance or raises. Constraints like priority: int = Field(ge=1, le=5) are enforced automatically.

In LangGraph, structured output is your job. In my triage graph the model returns text, and the finalize node has to json.loads it and construct the Triage itself. LangChain does offer model.with_structured_output(Triage) to push that into the model call, but it's an extra step you wire up — not the default posture of the framework. If your agent's main deliverable is *a well-shaped object your code can trust*, Pydantic AI gets you there with dramatically less glue.

Here's the thing that made the extra LangGraph code worth it. I compiled the graph with checkpointer=MemorySaver() and ran one ticket. Then I asked the graph how much state it had saved:

output type : Triage
validated   : category='billing' priority=4 needs_human=True
is Triage   : True
checkpoints : 6 saved states

Six checkpoints from a single run — one after every super-step. That's LangGraph's whole reason to exist: the state is persisted at each step, so if your process crashes between the tool call and the final answer, you resume from the last checkpoint instead of restarting the whole (paid) LLM conversation. Swap MemorySaver for a Postgres or SQLite checkpointer and that durability survives an actual server restart. This is also what powers human-in-the-loop: you can pause the graph, wait hours or days for an approval, and resume exactly where it stopped.

Pydantic AI's v2 does have a durable-execution story too — but it's opt-in and delegates to external durable engines (DBOS, Prefect, Temporal) via its capability layer, rather than shipping a built-in checkpointer. If durability is the *core* of your problem, LangGraph makes it the default; with Pydantic AI you assemble it.

Strip away the hype and it comes down to workflow shape. Ask yourself: *is my agent a function, or a process?*

• It's a function — input goes in, a few tools fire, a structured answer comes out, done in one turn. → Pydantic AI. You'll write less code, get validated output for free, and ship faster.
• It's a process — it waits on humans, runs for minutes to days, branches in parallel, retries on failure, and you need to see every step. → LangGraph. The graph and checkpointer are exactly the machinery you'd otherwise hand-build (badly).
• You're not sure yet — start with Pydantic AI. It's the lower-commitment choice, and if you outgrow it you can wrap a Pydantic AI agent as a node inside a LangGraph graph later without throwing work away.

That last point matters: this isn't a religious war. The frameworks compose. The mistake is reaching for LangGraph's graph ceremony for what is really a single-turn structured-output task, or trying to bolt durable, resumable, human-in-the-loop state onto a framework that treats a run as one function call. Match the tool to the shape of the work.