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 LangChain product page and LangGraph product page. Capability comparisons follow the makers' 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.

LangChain: the configurable agent layer

LangChain describes create_agent as a “minimal, highly configurable harness.” A harness is the machinery surrounding the model: instructions, callable tools and behavior controls. The same overview explicitly says, “LangChain’s agents are built on top of LangGraph.” 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 calls itself a “low-level orchestration framework and runtime” 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 overview.

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 or rejection. It uses LangGraph's persistence to retain the interrupted state. Human-in-the-loop documentation.

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. LangGraph overview.

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. Both snippets were checked locally with a scripted model to verify tool execution and saved state. This checks the wiring, not live model behavior or performance.

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. Agent configuration.

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 is the explicit loop pattern in the LangGraph quickstart, using the supplied tool-node 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 13 October 2026.

LangChain vs LangGraph vs LangSmith

LangSmith is the platform for tracing, evaluation and deployment around your application. 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.

These are the plan terms on langchain.com/pricing. The page's 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. Pricing FAQ.

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. Deployment environments.

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. Deployment pricing FAQ.

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. Pricing and deployment environments.

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. Published deployment rates.

For either a LangChain agent or custom LangGraph app, the normalized monthly Plus calculation is $39 × seats, plus each billable resource-hour quantity multiplied by its rate above, plus model, tracing and other applicable usage. Apply the included deployment allowance before counting billable resources. Do not convert requests or graph nodes into resource hours without measurements.

Here is arithmetic using the maker's published sizes, explicitly calculated rather than quoted plan prices. An additional Small Serverless deployment has 1 vCPU and 2 GiB of runtime resources, giving 1 × 0.0675 + 2 × 0.0090 = $0.0855 per provisioned hour. A Small Dedicated deployment lists 3 vCPU and 6 GiB for runtime, plus 1 vCPU and 4 GiB for its database, giving 3 × 0.0675 + 6 × 0.0090 + 1 × 0.177 + 4 × 0.025 = $0.5335 per provisioned hour. These are size-based resource estimates before additional scaling or other services, using the size table and published rates.

For a single Plus seat with that Dedicated resource profile held constant, the monthly subtotal is $39 + $0.5335 × provisioned hours, before the other charges just listed. The formula is identical for both frameworks. A guaranteed monthly bill needs your deployment's actual resource time and scaling.

There is no framework-price crossover at an equal workload. The calculated difference is $0 when seats, billable resources, model/tool usage and trace policy are held equal. A workflow redesign can change those quantities, but neither library name supplies a discount or establishes a lower token bill.

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. Cloud persistence details.

For a different decision, comparing graph orchestration with a team-of-specialists abstraction, read LangGraph vs CrewAI. 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.