Anyone building with large language models today eventually runs into the same two names: LangChain and LangGraph. They come from the same company, they're designed to work together, and they're frequently — and incorrectly — treated as competitors. This article explains what each one actually does, how they fit together, and when to reach for one, the other, or both.

The Problem They're Solving

A raw call to an LLM API is just a function: text in, text out. Real applications need more than that. They need to call external tools, retrieve documents, remember prior turns, follow multi-step plans, pause for human approval, retry when something fails, and recover their state after a crash. Stitching all of that together by hand, for every project, is tedious and error-prone. LangChain and LangGraph exist to remove that repetition.

LangChain: The Application Layer

LangChain is the higher-level framework. It gives developers standardized building blocks for LLM applications: model wrappers that work across providers, prompt templates, retrieval components for RAG (retrieval-augmented generation), memory abstractions, and a large catalog of integrations — several hundred connectors to vector stores, APIs, and data sources. Its value is in speed: it gets a team from an empty repo to a working prototype in hours rather than days, especially for common patterns like chatbots, document Q&A, and simple tool-using assistants.

A key piece of LangChain is its create_agent interface, which lets developers stand up a tool-using agent with a few lines of code, complete with support for durable execution, streaming, and human-in-the-loop review.

LangGraph: The Orchestration Runtime

LangGraph sits a level lower. Where LangChain gives you components, LangGraph gives you a runtime for controlling how those components execute over time. It models an application as a graph: nodes are units of work (an LLM call, a tool call, a piece of logic), edges define how control moves between them, and a shared, typed state object is threaded through the whole graph.

That graph structure matters because real agent behavior is rarely a straight line. An agent might need to loop back and retry a step, branch down different paths depending on a decision, pause mid-task and wait for a human to approve or edit something, or resume later exactly where it left off — even after a server restart. LangGraph handles this through a few core primitives:

1. Nodes and edges — the units of work and the control flow between them, including conditional branches and cycles (something a simple linear pipeline can't express).

2. Checkpointers — persistence that snapshots the graph's state, enabling durable execution and recovery from failure.

3. Interrupts — explicit pause points for human-in-the-loop review before the agent continues.

LangGraph is intentionally lower-level than LangChain's high-level agent API. That's the trade-off: more control and reliability, at the cost of writing more explicit code.

How They Fit Together

Since LangChain 1.0 (released in late 2025), this isn't really an either/or choice anymore. LangChain's create_agent function runs on LangGraph's execution engine under the hood, which is how it gets durable execution and persistence without the developer having to build a graph by hand. In practice:

1. Use LangChain's high-level agent API when you want a standard agent pattern working quickly, without needing to think about the underlying execution graph.

2. Drop down to LangGraph directly when you need custom control flow — branching logic, loops, multiple cooperating agents, fine-grained state management, or careful control over latency and retries — that the high-level API doesn't expose.

Most production systems in 2026 end up using both: LangChain for the integrations, prompt handling, and quick scaffolding; LangGraph for the parts of the application where control and durability really matter. Companies including Klarna, Replit, Elastic, Uber, and JPMorgan are cited as running agents built this way.

A Simple Way to Think About It

If LangChain is the toolkit — models, prompts, integrations, and a convenient way to assemble them — LangGraph is the engine room that keeps the resulting application running correctly in production: surviving failures, respecting human checkpoints, and behaving predictably across long-running, multi-step tasks. You don't have to choose a side. You choose how much of the engine room you need to see.

Getting Started

For a first project, the practical path is:

1. Start with LangChain's create_agent and its standard components (models, tools, memory) to get something working.

2. Reach for LangGraph once you hit a wall the simple agent API can't express — a workflow with real branching, a need for human approval steps, or state that must survive a restart.

3. Use LangGraph's checkpointing early if reliability matters from day one; retrofitting persistence onto an already-built agent is more work than designing for it up front.

Both libraries are open source (MIT-licensed) and actively developed by LangChain Inc., with official documentation at docs.langchain.com covering current APIs, integrations, and migration notes as the frameworks evolve.