Solutions for
Please select
Try the Web App
ki-werkzeuge

LangGraph

Redaktion ·

When an agent needs more than a straight line — why this matters

Most first agent prototypes are a chain: prompt in, tool call, answer out. That works as long as the flow stays linear. But the moment the agent needs to repeat a decision, retry a failed tool, wait for human approval, or pause mid-task and resume hours later, the chain falls apart. You start holding state in global variables, hand-write while loops, and bolt on your own save-and-restore logic — until half your code is orchestration instead of actual domain work.

This is exactly the gap LangGraph fills. It is a framework for modeling LLM agents as a graph: work steps are nodes, the control flow between them is edges, and a central state carries data through the run. Unlike a linear chain, that graph is allowed to contain loops, branches, and interruptions — that is the decisive difference. With its 1.0 release (22 October 2025), LangGraph stabilized these concepts, and over the course of 2026 it has become the de-facto standard in many stacks for orchestrating production agents.

This article explains the mechanics so that by the end you can decide for yourself when LangGraph is the right tool — and when it is not.

The core mechanic: agent as a graph

The central idea is simple. Instead of writing your agent as a script that runs top to bottom, you describe it as a diagram of nodes and edges. LangGraph then executes that graph — including the jumps back, branches, and repetitions a real agent needs.

Three building blocks matter: state, nodes, edges.

State — the shared memory

The state is a shared data structure that travels through the whole graph. You declare it up front as a typed schema (in Python usually a TypedDict): every field the graph reads or writes must be listed there. A typical state holds the message history, intermediate tool results, counters, flags.

The update semantics are key: a node receives the full state as input and returns only the fields it changed. LangGraph merges that partial update back into the overall state. For fields like the message list there are reducers — for example add_messages, which appends new messages instead of overwriting the list. The history grows correctly without every node having to handle that itself.

Nodes — where the work happens

A node is a function. It takes the current state, does something — calls an LLM, runs a tool, transforms data, writes to a database — and returns the changed state fields. Nodes are the only place where real logic and side effects live. The rule of thumb: nodes do the work, edges decide what happens next.

Edges — the control flow

Edges connect nodes and determine the order. There are two kinds. A normal edge is fixed: after node A, node B always runs. A conditional edge is a function that reads the current state and decides which node runs next. This is where the run gets its intelligence: if the model requested a tool, go to the tool node; if the task is done, go to the end.

Because an edge can also point back at a node already visited, you get cycles — the actual reason LangGraph exists.

The execution model — message passing

Under the hood, LangGraph uses message passing, modeled on the Pregel approach to graph processing. When a node finishes, it sends a message along its outgoing edges to the next nodes. Those run their function, pass their messages on, and so on. The graph runs in discrete steps (“super-steps”) — nodes with no dependency on each other can run in parallel.

LangGraph vs. LangChain — not an either-or

The most common confusion: is LangGraph a competitor to LangChain? No. Both come from the same team (LangChain Inc.) and are designed as different abstraction levels of the same stack.

  • LangChain provides the building blocks: integrations to models and tools, prompt abstractions, components for quickly assembling an agent.
  • LangGraph is the orchestration runtime underneath: the StateGraph engine that adds cyclic execution, branching, persistent state, and interruptibility.

Since the 1.0 releases (October 2025), the split is clean: LangChain’s new create_agent function replaced the old AgentExecutor and calls the LangGraph engine under the hood. In other words — anyone building an agent in LangChain is already using LangGraph, knowingly or not.

The 2026 reality usually looks like this: LangChain for building quickly, LangGraph for orchestrating and scaling reliably, plus a memory layer (LangMem, Mem0) for cross-session recall.

When LangChain is enough, when LangGraph is needed

If your agent logic stays linear — prompt, a few tool calls, answer, no branching, no state across sessions — the LangChain layer gets you there faster and with less boilerplate. The moment your agent needs to branch, loop, retry, or hold state across sessions, or you need production features like persistence and human-in-the-loop, LangGraph is the right cut.

The two features that take LangGraph to production

Loops and branches are the base mechanic. What really makes LangGraph production-grade are two capabilities built on top of them.

Persistence — state survives restarts

LangGraph can save a checkpoint of the state after every node step. There are checkpointer backends — in-memory for tests, SQLite or Postgres for production. The effect: if your server crashes mid-conversation or a long-running workflow gets interrupted, the next call resumes exactly where it left off — without losing context and without you writing custom database logic.

This enables flows that go beyond a single request: multi-day approval processes, background jobs, workflows spanning multiple sessions. Each run gets a thread ID; through it you access the saved history, jump back to an earlier checkpoint, or do “time-travel” debugging.

Human-in-the-loop — pause and wait for people

LangGraph offers first-class support for deliberately interrupting execution (interrupt) so a human can review, correct, or approve. The runtime pauses, saves the state via checkpoint, and does not block a thread. When the human responds — seconds or hours later — execution resumes from the exact interruption point.

This is the clean way for anything that should not run fully autonomously: an agent that drafts an email but waits for approval before sending; a workflow that prepares a database change and has a human confirm it.

Pitfalls

  • Letting the state grow unbounded. Carrying the entire history through the state unfiltered costs you tokens — at every LLM node the context is sent again. Reducers and deliberate trimming of the message list belong in from the start (see also our lexicon article on AI pricing).
  • Infinite loops. A cycle without a clean stop condition runs until the token budget or a recursion_limit kicks in. Set the stop condition in the conditional edge deliberately.
  • Overengineering. Not every agent needs a graph. If the flow really is linear, LangGraph is extra effort with no payoff. The graph earns its keep the moment you need loops, branching, or persistence.
  • Test checkpointer in production. The in-memory checkpointer does not survive a restart. Production needs a persistent backend (Postgres) — otherwise the whole persistence idea is worthless.

Where it fits among agent frameworks

LangGraph is not the only framework for agents — but it occupies a specific niche: graph-based, stateful orchestration with a focus on control and production readiness. Other frameworks set different priorities.

| Framework | Core idea | Strength | |---|---|---| | LangGraph | Agent as a graph of nodes/edges/state | loops, persistence, human-in-the-loop, fine-grained control | | CrewAI | Role-based teams of agents | quickly standing up multi-agent crews | | AutoGen | Agents that cooperate via conversation | multi-agent dialogue, research | | DSPy | Prompts as optimizable programs | systematic prompt/pipeline optimization |

If you want explicit control over every transition and need production features, LangGraph is the obvious choice. If instead you need a team of cooperating agents fast, look at CrewAI or AutoGen. If you care about systematically optimizing the prompts themselves, DSPy is the other approach. For a broader comparison, see our overview of agent frameworks.

Typical use cases

  • Research agent with a tool loop: search, evaluate the result, search again if needed, then summarize — the classic cycle task.
  • Multi-step workflows with approval: an agent prepares an action (email, database change, ticket), interrupts, and waits for human confirmation.
  • Long-running processes: a job that runs over hours or days, persists intermediate steps, and continues after interruptions.
  • Branching decision trees: a support agent that takes different paths through different tools depending on the request.

FAQ

Is LangGraph a replacement for LangChain?
No. Both come from the same team and work together. LangChain is the component and integration layer, LangGraph the orchestration runtime underneath. Since the 1.0 releases, LangChain's create_agent calls the LangGraph engine under the hood.
Why not just write my own loop in Python?
You can — until you need persistence, human-in-the-loop, parallel execution, and resumption after crashes. LangGraph ships exactly those production-critical parts, instead of you rebuilding them per project and getting them subtly wrong.
Does every agent need LangGraph?
No. For a linear flow with no branching and no cross-session state, it is overhead. The value starts at loops, branching, persistence, or approval steps.
What is a checkpointer?
A backend that saves the state after every node step. In-memory for tests, SQLite or Postgres for production. It enables resumption after interruptions, time-travel debugging, and human-in-the-loop.
How long has LangGraph been stable?
LangGraph 1.0 was released as generally available on 22 October 2025 — according to the vendor with no breaking changes over the late pre-releases, essentially a stabilization of the existing API.

Conclusion

LangGraph answers a concrete question: how do I build an agent that does not just run straight ahead, but can loop, branch, pause, and continue after a crash? The answer is the graph of nodes, edges, and a shared state — plus two production features, persistence and human-in-the-loop, that make the difference between prototype and live operation.

The rule of thumb to take away: if your flow stays linear, use the LangChain layer and skip the graph. The moment loops, cross-session state, or human approvals come into play, LangGraph is the right tool — and since the 1.0 release stable enough to build production on.

Themenuebersicht

KI-WerkzeugeAgenten-Frameworks