LangChain vs LangGraph

LangChain vs LangGraph: which should you pick?

Choose LangChain for a configurable agent loop. Choose LangGraph directly when you need to design the surrounding process. The deciding criteria are who selects the next step, what must survive an interruption, and which operating responsibilities you want to own.

If you are starting a support assistant that looks up orders and answers questions, use LangChain's create_agent. You provide the model, tools and instructions; its agent abstraction handles the repeating model-and-tool interaction. Add middleware, code that runs around that interaction, when you need a policy or approval check.

If you already have a LangChain app, keep it until you can name a workflow requirement that is awkward to express through that abstraction. Adding conversation memory or reviewing a proposed tool call is insufficient reason on its own: current LangChain agents expose LangGraph-backed facilities for both. LangChain agent documentation.

If your application must validate a request, gather evidence, wait for an operator, perform an authorized action and reconcile the result, consider a custom LangGraph workflow. Those stages are business rules you can make explicit, while an agent handles the flexible work inside a stage.

Library terms are stated on the makers' product pages. Capability comparisons follow the runtime overview and approval middleware documentation. This is an architecture recommendation, not a speed ranking.

What LangChain and LangGraph are today

LangChain supplies the components and agent abstraction; LangGraph supplies the stateful orchestration runtime beneath it. Treating them as rival replacements creates unnecessary migration work. The current LangChain v1 release notes and LangGraph v1 release notes describe this layered design; the LangChain release history and LangGraph release history confirm the major release lines.

LangChain: the configurable agent layer

LangChain provides create_agent, a configurable agent harness. A harness is the machinery surrounding the model: instructions, callable tools and behavior controls. Its agents use LangGraph as their runtime. LangChain overview.

Its advantage is a useful starting structure. For an order-support assistant, you can expose your existing lookup function as a tool and add policy around its use. You do not have to hand-build the loop before working on the product.

Its wall is the fit of that structure. A long-running case with named business stages may become harder to understand if every transition is buried in prompts, tool conventions and middleware. That is a maintainability judgment, not a claim that LangChain agents cannot branch or retain state. The library is free; model access and whatever infrastructure you choose remain separate costs.

LangGraph: the workflow runtime you control

LangGraph provides low-level orchestration for long-running, stateful agents. A node is a unit of work; an edge determines where execution goes next; state is the information carried between those steps. You can mix ordinary application logic with model-driven decisions.

LangGraph wins when the workflow itself is part of your product. You might let a model draft a response while application code decides whether approval is required and whether the approved action has already happened.

Its wall is ownership. You must design meaningful state, transitions and failure behavior. A graph with confusing boundaries is still confusing software. LangGraph is also a free library, and you can use it without LangChain; keeping LangChain's model and tool components is often convenient.

The practical middle ground is a LangChain agent inside a larger process. Keep the useful abstraction for flexible tool work and make the surrounding business sequence explicit only where necessary.

LangChain agents vs LangGraph: the control boundary

LangChain wins convenience within the agent loop; LangGraph wins explicit control across business stages. Durability and human review are shared capabilities whose configuration still matters.

Agent loops and tool approvals: LangChain wins

An assistant that reads an order, explains its status and proposes a response fits the model-and-tool loop. Adding review before a tool sends the response still fits: HumanInTheLoopMiddleware can pause configured tool calls and accept approval, edited arguments, rejection or a direct human response for an ask-user tool. It uses LangGraph's persistence to retain the interrupted state.

Since October 14, 2026, LangChain 1.4.6 supports interrupt_mode="per_call": each gated tool call gets its own interrupt, answered by interrupt ID. Batched review remains the default. Verified against the makers' live docs and framework changelog on November 8, 2026: a tool-approval requirement still does not require a custom graph.

That gives an existing LangChain application a relatively narrow next step: configure the approval policy and a persistent checkpointer, then connect the pending decision to your application. The middleware does not build your review inbox or decide which employee is authorized to approve; those remain application responsibilities.

Explicit business stages: LangGraph wins

Choose a custom graph when the correct next step follows from the business record rather than the model's next tool suggestion. Consider a supplier-onboarding process: collect evidence, validate required fields, route an exception to an operator, then activate the supplier only after approval.

A graph can represent those transitions directly. The evidence-gathering node can still call a LangChain agent. Validation and activation can be ordinary functions with explicit outcomes. LangGraph's documented ability to combine deterministic and agentic steps is the useful distinction here.

The switching rule is concrete: move down a layer when explicit state and transitions remove recurring uncertainty about what the application is allowed to do next. A longer prompt, more tools or a slow model response does not establish that need by itself.

Durability: shared foundation, different design burden

A checkpointer saves a thread's workflow state so execution can continue later. A store holds application-defined information across threads, such as a preference used in separate conversations. They solve different persistence problems. Persistence documentation.

For either approach, choose storage that matches the failure you need to survive. InMemorySaver keeps checkpoints in the running process and loses them on restart. It can demonstrate conversation state or an interrupt; it cannot establish recovery after the worker disappears. A production database-backed saver, or the persistence managed by Agent Server, addresses that storage requirement.

Also distinguish a checkpoint from an external action receipt. Saving “ready to activate supplier” is not evidence that the supplier system accepted the activation. Keep the external identifier and outcome in an application record you can reconcile.

The makers document this restart behavior and the need for idempotent side effects, operations that can repeat without repeating their business effect. For example, use a stable operation identifier so a resumed job cannot create the same supplier twice. Interrupt and replay rules.

LangChain vs LangGraph Python: the same small task

For a simple order-status lookup, LangChain expresses the same intent with less orchestration code. The custom graph makes the model/tool route visible, which earns its place when that route needs to change.

These examples share a model, prompt, read-only tool and input. The order record is an explicitly fictional local fixture. Install langchain[anthropic] and langgraph; a live model call requires your application's ANTHROPIC_API_KEY. The example model identifier follows the makers' current LangChain overview and LangGraph quickstart. These are documentation-based examples, not a live-model benchmark.

Save this shared setup as common.py:

from langchain.chat_models import init_chat_model
from langchain.tools import tool

model = init_chat_model("claude-sonnet-4-6", temperature=0)
prompt = "Use lookup_order for order status. Do not invent a status."
request = {"messages": [{"role": "user", "content": "Status of order demo?"}]}
config = {"configurable": {"thread_id": "order-demo"}}

@tool
def lookup_order(order_id: str) -> str:
    """Read an order's status from a fictional local fixture."""
    return {"demo": "shipped"}.get(order_id, "unknown order")

LangChain: use the existing loop

Run this as a separate script alongside common.py:

from common import model, prompt, request, config, lookup_order
from langchain.agents import create_agent
from langgraph.checkpoint.memory import InMemorySaver

agent = create_agent(
    model, tools=[lookup_order], system_prompt=prompt,
    checkpointer=InMemorySaver(),
)
print(agent.invoke(request, config)["messages"][-1].content)

The graph runtime is already underneath this agent. Passing a checkpointer does not require replacing create_agent with a hand-written graph.

LangGraph: declare the same loop

Run this alternative script alongside the same common.py:

from common import model, prompt, request, config, lookup_order
from langchain.messages import SystemMessage
from langgraph.checkpoint.memory import InMemorySaver
from langgraph.graph import StateGraph, MessagesState, START
from langgraph.prebuilt import ToolNode, tools_condition

bound_model = model.bind_tools([lookup_order])

def call_model(state: MessagesState):
    reply = bound_model.invoke([SystemMessage(prompt)] + state["messages"])
    return {"messages": [reply]}

builder = StateGraph(MessagesState)
builder.add_node("model", call_model)
builder.add_node("tools", ToolNode([lookup_order]))
builder.add_edge(START, "model")
builder.add_conditional_edges("model", tools_condition)
builder.add_edge("tools", "model")
agent = builder.compile(checkpointer=InMemorySaver())
print(agent.invoke(request, config)["messages"][-1].content)

The conditional edge sends a requested tool call to tools, or ends when the model produces a final response. The tools node returns control to the model. This follows the quickstart's explicit model/tool loop, using the documented ToolNode and tools_condition helpers.

Both snippets deliberately use process-local memory and show only the successful read path. Neither is a deployment recipe, durable database setup or complete error policy. Model output is not guaranteed to be word-for-word identical merely because the configuration matches.

For this task, choose LangChain. A custom graph becomes useful when the next requirement changes the process: mandatory validation before lookup, a separate exception queue, or an approval stage that needs its own state and outcomes.

LangSmith and LangGraph deployment pricing

The library choice does not select a separate hosting tariff. The paid decision is which LangSmith services and deployment environment you need. Pricing and product documentation below were verified against the makers' live pages on November 8, 2026.

LangChain vs LangGraph vs LangSmith

LangSmith is the platform for tracing, evaluation and deployment around your application. The current hosted product is LangSmith Deployment; use that name when looking for what older material calls LangGraph Platform. A trace records an application execution and can include its model calls and other steps. It is a different object from the checkpoint used to resume the application. LangSmith pricing and definitions.

Both libraries are free to use. Running either in infrastructure you operate still leaves model calls, compute, storage and operations to budget. Buying LangSmith is a separate decision; its deployment documentation explicitly supports LangGraph and LangChain applications.

The pricing calculator describes the Plus trace inclusion as 10K traces total: adding seats does not imply another allowance for each seat. It displays 0.005 LSU per additional trace for its shown observability configuration. That calculator value should not be generalized to every trace-retention option.

Base traces have 14-day retention; extended traces have 180-day retention and an additional fee. Longer retention and evaluation services are separate budget choices, not free consequences of choosing a graph.

The deployment options and their walls

Cloud is the managed option, available on Plus or above. LangChain operates the infrastructure. Within Cloud, the public pricing page offers Serverless and Dedicated deployments in Small, Medium and Large sizes.

Serverless suits intermittent, background or latency-tolerant work. It scales to zero when idle, and Plus includes a small deployment. Dedicated suits customer-facing work that needs consistent availability, with always-on infrastructure, autoscaling, backups and high availability. These are the maker's own intended uses, not performance measurements from this comparison.

A practical limitation affects the migration plan: you can change a deployment's size, but you cannot change its type after creation. A move from Serverless to Dedicated therefore needs a deployment transition, not just a size adjustment. Serverless resources are also billed while provisioned, including idle time before scale-down. “Scales to zero” does not mean every non-request second is free. Cloud platform features.

Hybrid keeps the managed control plane while you run the agent infrastructure. The control plane is the service that manages deployments; the data plane runs the agents and their backing services. Self-hosted with a control plane puts both in your environment. The pricing page places hybrid and self-hosted options under Enterprise, with Custom pricing. There is no public fixed enterprise monthly amount to substitute.

Standalone Agent Server is another operational choice, with no control plane and your own backing services. Its documentation requires a LangSmith license, PostgreSQL and Redis. It is distinct from embedding the free LangGraph library in your own application. The standalone documentation also warns against deploying that server into a scale-to-zero serverless environment; the managed Cloud Serverless product is a separate configuration. Standalone Agent Server.

The same workload costs the same on either framework

The public page defines $1.00 per LSU, or LangChain Standard Unit, and lists these deployment meters:

• Runtime Compute: 0.0675 LSU / vCPU-hr.
• Runtime Memory: 0.0090 LSU / GiB-hr.
• Database Compute: 0.177 LSU / vCPU-hr.
• Database Memory: 0.025 LSU / GiB-hr.

These rates apply to billable resource consumption for additional Serverless and Dedicated deployments.

For either framework, budget for seats, billable compute and database resources, model calls, tracing and other applicable usage. Apply included allowances before counting additional resources. Do not convert requests or graph nodes into resource hours without measurements.

The current Cloud size table lists 0.8 vCPU and 2 GiB of billable runtime for Small Serverless. Small Dedicated starts with 3 vCPU and 6 GiB of runtime, plus a database with 1 vCPU and 4 GiB; autoscaling can add runtime replicas. Those are resource sizes, not guaranteed monthly bills.

The library name does not create a hosting discount. If seats, resources, model/tool usage and trace policy are held equal, the same published pricing applies. A workflow redesign can change those quantities, so compare completed jobs rather than framework labels.

Switching from LangChain to LangGraph without a rewrite

Migrate the orchestration boundary that needs control, and preserve the components that still work. The meaningful migration cost is redesigning state, behavior and recovery, not changing the import statement.

First distinguish a legacy API upgrade from a custom-graph decision. The current migration guide recommends langchain.agents.create_agent in place of the earlier langgraph.prebuilt.create_react_agent constructor. Following that migration does not mean abandoning LangGraph underneath, and an older app may benefit from current LangChain capabilities before it needs bespoke orchestration. LangChain migration guide.

Do not switch a working LangChain assistant merely because graphs look more production-oriented. If the loop, middleware and persistent storage meet the requirements, a custom graph adds design work without a demonstrated payoff.

Lock-in has layers, too. Reusable model/tool components can remain while your graph state and control flow change. Hosted infrastructure adds its own constraints: Cloud persistence is accessed through Agent Server, and the hosted database is not directly accessible. Include that access boundary in any future export or hosting move.

For model and integration choices beyond this stack, read LangChain alternatives. For a different decision, comparing graph orchestration with a team-of-specialists abstraction, read LangGraph vs CrewAI. For conversational multi-agent orchestration, see AutoGen vs LangGraph. For choices beyond this stack, use the broader AI agent frameworks comparison.

Questions from a builder making this choice

Use the AI Business Workflow Audit Checklist to define the job, its review boundary and its operating owner before changing the orchestration.