LangGraph vs Pydantic AI: Which Scales Better in Production?

For a production agent, LangGraph scales better when durable workflow orchestration is the problem you need to own. Pydantic AI scales better when a typed Python agent, clear tool contracts, and a conventional application service are the centre of gravity. Neither framework is a universal production winner, and neither replaces the work of defining permissions, idempotency, approvals, evaluations, and operating ownership.

That distinction matters because teams often compare framework features before they have defined the workflow. A model that proposes a CRM update is relatively easy to prototype. A system that selects the correct tenant-scoped record, preserves an approval across a browser refresh, retries safely after a timeout, and proves what changed is a production system. The framework should fit that system, not the demo.

“Scale” is more than concurrent requests

For agent systems, scale has at least four meanings:

• Run volume: How many requests and tool calls the service can handle.
• Workflow lifetime: Whether a run must survive minutes, days, failures, deployments, and approval delays.
• Workflow complexity: How many branches, compensating actions, and exception paths are part of the job.
• Ownership complexity: How easily engineers can understand, test, change, and operate the system as the product grows.

No framework documentation establishes a universal winner on throughput, latency, reliability, or cost. Those depend on the model, prompts, tools, databases, traffic pattern, and deployment architecture. Treat “which scales better” as an architecture question first, then load-test one representative workflow with the same model and tool boundary.

The architectural difference

LangGraph is a low-level orchestration framework and runtime for long-running, stateful agents. Its central primitives are state, nodes, edges, and checkpointed execution. Its persistence layer saves state as checkpoints, which is the foundation for recovery, replay, and human-in-the-loop flows. An interrupt persists the graph state and waits for external input until the run is resumed.

Pydantic AI is a Python agent framework built around an agent loop, typed dependencies, validated outputs, tools, and composable capabilities. Its type-first approach gives a team a concise way to declare the data an agent receives and the shape it must return. It also supports tool approval, MCP, evaluations, and observability integrations.

The dividing line is no longer “LangGraph has durable execution and Pydantic AI does not.” Pydantic AI now documents durable-execution integrations with Temporal, DBOS, Prefect, and Restate, plus pydantic-graph for typed state-machine modelling. That means both routes can support a long-running production workflow. The decision is whether you want durable orchestration to be the framework's native organising model or to compose an agent framework with a durable-execution system selected for the wider application.

Compare the production choices that affect ownership

Decision	LangGraph	Pydantic AI	What to test before committing
Primary model	Stateful graphs, checkpoints, and explicit transitions	Typed agents, dependencies, tools, and validated outputs	Whether the core job is a workflow state machine or an agent interaction in an existing service
Pause and resume	Persistence and interrupts are built into the graph runtime	Durable execution is available through supported external solutions	Approval delays, process restarts, deploys, and resuming the exact reviewed work
Complex branching	Graph structure makes branches and state transitions visible	pydantic-graph offers typed state machines; ordinary Python remains useful for simpler flows	Failure, retry, escalation, rejection, and compensation paths
Interface correctness	You define schemas and validation in nodes and tools	Type hints, dependency injection, and Pydantic validation are central to the agent interface	Invalid arguments, missing data, schema changes, and output validation failures
Observability and evaluation	LangGraph can pair with LangSmith for tracing and evaluation	Pydantic AI integrates with Logfire and OpenTelemetry-compatible tooling	Trace access, sensitive-data handling, evaluation datasets, alerting, and cost attribution
Operational composition	A focused runtime for orchestration, with storage and deployment choices to make	A framework that can fit beside an application stack and chosen durable platform	Which team owns infrastructure, upgrades, incident response, and lifecycle policy

This is a capability comparison, not a benchmark. In particular, Pydantic AI's durable option brings a second system into the design. That may be an advantage if your organisation already runs Temporal or Restate. It may be needless operational surface for a team that primarily needs an agent workflow runtime with checkpoints and interrupts.

Choose LangGraph when the workflow itself is the product problem

LangGraph is the stronger default when the valuable complexity is in the lifecycle of the work. Choose it when runs must cross sessions, wait for a material approval, branch through several exception paths, or recover at known state boundaries.

Consider an account-renewal workflow. The agent gathers account signals, produces a renewal brief, sends a proposed escalation to a manager, waits for a decision, then creates approved tasks. If the manager changes the proposal two days later, the system must retain the selected records, source evidence, proposed actions, and decision. It must not re-run an external write because the process restarted.

That is naturally a state machine. LangGraph makes the state and transitions first-class. Its documentation also carries an important implementation warning: when a node restarts after an interrupt, work before the interrupt can run again. Place external effects behind idempotent operations and model compensation or verification explicitly. A checkpoint does not turn an unsafe write into a safe one.

The cost is deliberate design. Teams must define state shape, checkpoint storage, versioning, retry policy, and every edge that matters. That is useful friction when the workflow needs to be reviewed and maintained as a product capability. It is unnecessary ceremony for a short, bounded agent task.

Choose Pydantic AI when typed application integration is the primary need

Pydantic AI is the stronger default when the agent sits inside an established Python service and the most useful control surface is a typed interface. Its agent dependencies, tool inputs, and output models make the contract around a bounded unit of work easy to inspect in Python.

For example, an in-product support copilot might receive the current account ID and requesting user as typed dependencies. It can call narrowly scoped read tools, return a validated SupportProposal, and let the application decide whether to display it, persist it, or submit it to an existing approval system. The surrounding application remains responsible for session state, tenant checks, business policy, and the final write.

That shape can stay compact without hiding the important constraints. Tools still need server-side authorization. Validated output is not proof that an update is correct. A typed account_id does not establish that the user may access that account. Validate the contract at the tool boundary, then verify the final state after consequential actions.

Use Pydantic AI's durable integrations when the workflow outgrows a request-response lifecycle. Select the durable platform based on how it will persist state, retry side effects, handle code changes, expose approval events, and fit the systems your team already operates. Pydantic AI's documentation lists four officially supported durable-execution solutions; test the specific integration, not the category label.

A practical selection test

Before standardising on either framework, implement one workflow that includes a real read, a controlled write, a failure, and an approval. Use the same model, tool definitions, tenant data boundary, and acceptance criteria for both candidates where feasible.

Ask these questions:

1. Can we identify the verified final product state for this job?
2. Can a run pause and resume without selecting a different record or duplicating an external effect?
3. Are every read and write authorised by the product server, not by model instructions?
4. Can an engineer inspect why a tool was selected, which data it used, and what the tool returned?
5. Do evaluation cases cover routine work, missing data, denied permissions, tool timeouts, ambiguous requests, rejected approvals, and retries?
6. Can the team change the workflow six months from now without losing the ability to interpret active or historical runs?

The answers expose the real scaling constraint. If the hard part is durable state and transitions, begin with LangGraph. If the hard part is a typed agent boundary inside an application that already owns the lifecycle, begin with Pydantic AI. If both are true, a small proof of concept is cheaper than adopting an abstraction that does not match the work.

What not to delegate to the framework

Framework choice should come after several product decisions that both approaches require:

• Define the exact records and fields an agent may read.
• Split preparation, approval, and execution into separate actions rather than exposing an unrestricted update tool.
• Apply authorization at the API or service layer for every tool call.
• Make retries idempotent and verify the resulting product state.
• Preserve the proposal, evidence, and approver identity across a pause.
• Evaluate the workflow's actions and final state, not only the wording of its answer.

If the path is fixed and the decision rule is stable, conventional automation is often the simpler answer. If a user needs information only, retrieval may be enough. An agent is appropriate when it must interpret live product context and choose among controlled actions to complete a meaningful job.

Where Ginger Labs fits

For SaaS teams, the framework is only one layer in a larger product decision. We build embedded agents that live in a side panel, inline surface, or modal inside the customer's product. They are designed to work with the product's schemas, stages, records, and data while progressing a defined workflow in the place users already work. Our SDK includes retrieval, evaluations, self-learning loops, and observability.

We can take responsibility for the embedded-agent experience and its implementation layer. The product team still owns its API, data model, user permissions, tenant boundaries, domain rules, approval policy, and definition of a correct result. In the renewal example, the team decides which records are in scope and when a manager must approve a change; the in-product agent makes that workflow usable without asking users to learn every intermediate step.

If users should be able to describe a valuable workflow instead of learn it step by step, bring one workflow and its exception cases to a 20-minute Ginger Labs demo. We can scope an embedded agent in a sandbox of the product.

For the workflow design behind this decision, read What Matters Most When Building AI Agents for Business Workflows. For the policy that governs ambiguous requests and approvals, read When Should an Agent Ask a Clarifying Question vs Proceed Safely?.

Sources

• LangGraph overview, LangChain. Accessed August 6, 2026.
• LangGraph persistence, LangChain. Accessed August 6, 2026.
• LangGraph interrupts, LangChain. Accessed August 6, 2026.
• Pydantic AI overview, Pydantic. Accessed August 6, 2026.
• Pydantic AI durable execution, Pydantic. Accessed August 6, 2026.
• Pydantic Graph overview, Pydantic. Accessed August 6, 2026.