Why LangGraph Exists

You already know how to build an agent with LangChain. You know create_agent, you understand the model-tools-loop shape underneath it, and you’ve built real, working agents with it. So let’s not open this course with a definition of LangGraph. Let’s open it the way it actually needs to be opened: by pushing what you already know until it genuinely, honestly stops being enough.

Something you already know how to build

Here’s a small, real support agent — the exact shape you built repeatedly in your LangChain course.

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

@tool
def get_order_status(order_id: str) -> str:
    """Look up the current status of an order."""
    return "Shipped"

agent = create_agent(model=init_chat_model("openai:gpt-4o-mini"), tools=[get_order_status])
result = agent.invoke({"messages": [{"role": "user", "content": "What's the status of order 1001?"}]})
print(result["messages"][-1].content)

This is genuinely fine. One model, one tool, one loop, deciding when it’s done. Nothing about this module is arguing that this was ever the wrong way to build something this simple.

Now, a genuinely harder, real requirement

Real customer support isn’t always this simple. Consider what a genuine resolution workflow actually needs to do:

Customer request
     ↓
Classify the issue
     ↓
Retrieve the customer's account
     ↓
Analyze what's actually wrong
     ↓
Choose an action (retry payment? issue refund? escalate?)
     ↓
Execute that action
     ↓
Validate the result
     ↓
Is this a high-risk action, like a large refund?
     ↓
If yes: pause for a real human to approve
     ↓
Continue only once approved

Take a moment and actually sit with this diagram, because every arrow in it is a genuine requirement, not decoration. Let’s try to build this the way you already know how — as an agent with a system prompt and a pile of tools — and watch, honestly, where that approach starts to strain.

Watching the strain happen, in real code

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

@tool
def get_customer(customer_id: str) -> str:
    """Look up a customer's account."""
    return "Priya, Pro plan, joined 2022"

@tool
def retry_payment(order_id: str) -> str:
    """Retry a failed payment for an order."""
    return "Payment retried successfully."

@tool
def issue_refund(order_id: str, amount: float) -> str:
    """Issue a refund for an order."""
    return f"Refunded ${amount}."

@tool
def escalate_to_human(reason: str) -> str:
    """Escalate this case to a human agent."""
    return f"Escalated: {reason}"

agent = create_agent(
    model=init_chat_model("openai:gpt-4o-mini"),
    tools=[get_customer, retry_payment, issue_refund, escalate_to_human],
    system_prompt=(
        "You are a customer resolution agent. Retrieve the customer's account, "
        "diagnose the issue, and take the right action. For refunds over $100, "
        "you must get human approval before executing — pause and wait."
    ),
)

Read that system prompt again, slowly. “For refunds over $100, you must get human approval before executing — pause and wait.” Now ask yourself, honestly: what does “pause and wait” actually mean here? create_agent’s loop, exactly as you learned it, runs until the model stops requesting tools. There’s no real, structural mechanism in that loop for genuinely pausing mid-execution, persisting exactly where it stopped, and resuming later — possibly minutes later, possibly the next morning, possibly after the process running this code has restarted entirely. You’re not configuring a real capability here. You’re writing a sentence and hoping the model’s own good judgment substitutes for an actual guarantee.

This is worth sitting with, because it’s not a small gap. It’s the honest, structural difference between asking a model to behave a certain way and guaranteeing, in your own code, that it will.

The real questions this gap forces you to ask

• Where does this workflow’s state — which customer, what diagnosis, what action was chosen, whether it’s been approved — actually live, in a form your own code can inspect and control?
• How do you make a loop, a review-and-revise cycle, an explicit, controlled thing, rather than an emergent behavior you’re hoping a system prompt produces?
• How do you genuinely pause execution — not simulate pausing with a clever prompt, but actually stop, save exactly where you are, and hand control to a real human?
• How do you resume, correctly, from that exact paused point, possibly much later, possibly on a different machine entirely?
• How do you persist progress so that if the process crashes at step 4 of 7, you resume at step 4, not step 1?
• How do you inspect, after the fact, exactly which path a given execution actually took, and why?

Notice something important about this list: none of these are questions about the model’s intelligence. Every one of them is a question about architecture — about the actual, real infrastructure surrounding the model, deciding what runs, when, and based on what.

This is a genuinely real gap, not a hypothetical one

It’s worth grounding this in something concrete, because this isn’t a made-up scenario built to justify a new framework. Recall Klarna’s AI Assistant from your LangChain course — 85 million active users, handling millions of real conversations. Klarna’s own, real workflow needed exactly the property this module has been circling: persistent state across conversation turns, in a genuinely multi-step resolution process that a purely linear pipeline — the shape a simple create_agent loop produces — could not reliably support. Built specifically as a graph, with that state made explicit and controllable, Klarna’s documented result was an 80 percent reduction in customer resolution time across millions of real interactions. Separately, Uber has reported saving roughly 21,000 developer hours using this same graph-based approach for its own internal agent workflows. These aren’t abstract claims about a framework’s elegance — they’re real, measured outcomes tied specifically to making workflow state and control flow explicit, rather than implicit inside a model’s own reasoning.

What LangGraph actually is, stated precisely

You’re ready for a real definition now, and it should land as the obvious answer to everything above, not as a new piece of jargon:

LangGraph is a library for building agent workflows as explicit graphs — a defined set of states, nodes, and edges — giving you direct, structural control over what runs, when, based on what data, including the ability to pause, persist, resume, and inspect execution at any point.

It’s worth being precise about the actual relationship to what you already know, since this matters and is easy to get wrong:

flowchart LR
    A["LangChain\nmodels, prompts, tools,\nretrieval, structured output"] --> C["Your Application"]
    B["LangGraph\nstate, nodes, edges, routing,\nloops, persistence, interrupts"] --> C

These aren’t competing libraries, and this course isn’t asking you to abandon anything you already learned. LangChain gives you the ingredients — a model, a tool, a retriever. LangGraph gives you explicit control over the process those ingredients get combined in. In fact, recall from your LangChain course that create_agent itself is already built directly on top of LangGraph — you’ve been using this engine the entire time, just through a simplified, high-level door. This course is about walking through that door directly, and gaining the explicit control that simplified version deliberately hides from you.

Common mistakes worth avoiding

Reaching for LangGraph on day one, for every project, regardless of actual need. Recall the simple order-status agent that opened this module — genuinely fine as create_agent. The real signal for needing a graph isn’t “this involves AI,” it’s the specific list of honest questions this module raised: does this workflow genuinely need to pause, persist, resume, or be inspected after the fact? If the honest answer is no, adding graph machinery is real, unnecessary complexity.

Trying to solve LangGraph’s problems with an increasingly elaborate system prompt instead. This is precisely the mistake this module’s refund example walked through directly — “pause and wait” is a sentence, not a mechanism. No amount of more careful prompt wording turns a request into a real, structural guarantee.

Assuming LangGraph replaces what you already learned about LangChain, rather than building on it. Recall this module’s own closing diagram — models, prompts, tools, and structured output remain exactly as useful as they were. LangGraph adds explicit control over the process those pieces run inside, not a replacement for the pieces themselves.

What you should take away from this module

• A LangChain agent’s loop runs until the model stops requesting tools — genuinely fine for simple, single-pass tasks, but with no real, structural mechanism for pausing, persisting, and resuming across real time.
• A system prompt asking a model to “pause and wait for approval” is a request, not a guarantee — the actual control has to live in your own architecture, not the model’s good behavior.
• Klarna’s real, documented 80 percent reduction in resolution time, and Uber’s real ~21,000 saved developer hours, are both tied specifically to making workflow state and control flow explicit — exactly the property a graph, and not a simple loop, provides.
• LangGraph and LangChain are complementary, not competing — you’ve already been using LangGraph underneath create_agent without realizing it.

Where this goes next

The next module builds the complete mental model this course runs on — state, nodes, edges, routing, execution — one clear layer at a time, so that every concept from here forward has an obvious place to belong.