fullauto.online

← Frameworks

Framework · spec sheet

LangGraph

LangChain·orchestration
Category
Orchestration
Type
State-machine library
License
Open source (LangChain)
Languages
Python, JS
Focus
Explicit graph control flow
Best for
When the control flow is really a graph

Explicit state machines. Worth it when the control flow is genuinely a graph, not a loop.

What it is

LangGraph is an open-source library from LangChain, in Python and JavaScript, for building agents as explicit state machines. Nodes are steps — a model call, a tool run, a function — and edges decide what runs next, with a shared state object threaded through the graph and updated at each step. The note above sets the bar honestly: it is worth it when the control flow is genuinely a graph, not a loop.

That is a narrower claim than “framework for agents”. LangGraph does not care what your nodes do; it cares that the transitions between them are declared, inspectable and repeatable. If you have ever tried to express a retry-with-human-approval branch in a while loop, you already know the problem it is solving.

How it works

You define a state schema, then add nodes that read and update it. Edges can be fixed or conditional — a function inspects the state and picks the next node — which is how branching, loops and early exits get expressed without hidden control flow. Because state is a first-class value, the library can checkpoint it.

Checkpointing is the part that earns the complexity. Each step's state can be persisted, which means a run can be paused, inspected, resumed from an arbitrary point, or forked — the machinery behind human-in-the-loop patterns, where a graph stops at an interrupt, waits for a person, and continues with their answer. Streaming out of individual nodes and replaying a run from its state are the same machinery pointed at different needs: observability and recovery.

When it earns its place over a plain loop

When the flow has real structure: branches that must be audited, retries with escalation, approval gates, parallel fan-out with a join, or long runs that must survive a process restart. A plain loop handles “call tool, look at result, decide” fine. It gets ugly when the decision tree is the product — and once a person has to intervene mid-run, a persisted graph is the difference between a feature and a hack.

It does not earn its place when the flow is a loop. If your agent's control flow is “keep going until done”, a graph is ceremony: more concepts, more state plumbing, and a debug session that involves reading node names instead of a stack trace.

Limits

  • Boilerplate is the price of explicitness. State schemas, node functions and edge routing are all code you own and maintain.
  • The graph abstraction can fight you. Dynamic, improvisational flows — where the next step is invented rather than chosen — fit poorly into fixed topology.
  • Ecosystem churn. It sits in the LangChain orbit, which has changed shape repeatedly; pin versions and expect to re-read the migration notes.
  • It orchestrates; it does not evaluate. A well-structured graph around a weak model or a vague task is still weak output, now with a stack of nodes.

Alternatives on this board

  • OpenAI Agents SDK — handoffs and guardrails in a smaller API when a full state machine is too much.
  • Google ADK — sequential, parallel and loop workflow agents covering the common shapes.
  • CrewAI — when the structure is roles and hand-offs rather than graph topology.
  • Pydantic AI — when the gap is typed tools and outputs, not control flow.

Sources

Hand-maintained editorial spec, not vendor copy — the read on each tool is judgement. Last checked 16 Sep 2026 · back to frameworks.