LangGraph

LangGraph is the framework you reach for when the job stops being "one good LLM call" and becomes "a multi-step flow that has to hold state, branch, pause for a human, and survive a crash." Nodes are steps, edges are transitions, and a checkpointer persists the whole thing between every step. This page is the orient-and-decide surface — official docs at docs.langchain.com own the API contracts.

Of the LangChain family, this is the one GL is watching most closely — because unlike the toolkit, there is no clean GL equivalent for what it does. Today's orchestration is Claude Code subagents plus Neo4j as a state store: informal, session-bound, not a durable graph runtime. LangGraph is the honest answer to "what would durable actually look like." Not yet applied — this page is the map before a build that hasn't been committed to.

What it is

A Python (and JS/TS) framework for building stateful, multi-actor LLM applications as a graph. Built by LangChain Inc.; MIT licensed; pip install langgraph. Crucially, it's a standalone library — it can orchestrate any stateful Python process and does not require the LangChain prompt/chain model to be useful. Three ideas carry it:

• StateGraph — you define a state schema (a typed dict / Pydantic model), add nodes, wire edges, set an entry point, and compile() to a runnable. State flows through the graph; each node reads it and returns an update that gets merged back in.
• Nodes and edges — nodes are plain Python functions that do one discrete thing (call an LLM, run a tool, validate output) and return a state delta. Edges route: direct edges for fixed sequences, conditional edges for branching on the current state. Unlike a DAG, the graph can loop — agents revisit steps, self-correct, and iterate.
• Persistence (checkpointing) — a checkpointer snapshots state after every successful node. That single decision is what buys durable execution, human-in-the-loop pauses, time-travel, and fault tolerance for free.

The pitch: the messy parts of real agent systems — resuming after a crash, pausing for approval, keeping a coherent shared state across many actors — become graph properties instead of a pile of bespoke glue.

When to use it

Reach for it when:

• The workload is genuinely multi-step and stateful — a flow with branches, loops, retries, and a shared state that has to stay coherent across steps. This is the core case.
• You need durable, long-running execution — a run that may take minutes to hours, must survive a process restart, and resume from exactly where it stopped rather than replaying from zero.
• You need human-in-the-loop — pause mid-graph for approval or edit, persist the state, and resume on a signal. LangGraph's interrupt does this as a first-class primitive.
• You're coordinating multiple actors — several agents handing off tasks, with a supervisor or hierarchy, over a persisted shared state.
• You want the flow to be inspectable and replayable — the checkpoint history is a time-travel debugger for the run.

Skip it when:

• The work is a single LLM call or a fixed two-step pipeline — the graph runtime is overhead you'll never earn back. A function is fine.
• The "state" is a conversation buffer and nothing more — a list of messages plus a system prompt doesn't need a state machine.
• The altitude you actually need is per-step reasoning quality, not orchestration — that's DSPy territory. LangGraph moves control between steps; it doesn't make any one step smarter.
• The orchestration is short-lived and session-bound — if a crash mid-run just means "run it again," durable execution isn't paying for itself yet. (This is where GL sits today, honestly.)

At a glance

Core primitives

• StateGraph — the builder. Instantiated with a state schema; you add_node, add_edge, add_conditional_edges, set_entry_point, then compile() to a runnable graph. invoke / stream it with input state.
• Nodes — Python callables (state) -> state_update. Do the work, return a partial-state delta that gets reduced into the running state.
• Edges — direct (add_edge("a", "b")) for fixed transitions; the graph ends at END.
• Conditional edges — a router function reads state and returns the name of the next node. This is where branching, loops, and self-correction live.
• Checkpointers — persist state per thread (thread_id). InMemorySaver for dev/tests, SqliteSaver for single-server, PostgresSaver for multi-instance scale. This is the durability seam.
• Interrupts — interrupt(...) pauses the graph, persists state via the checkpointer, and waits indefinitely for a resume signal. The human-in-the-loop primitive; requires a checkpointer + a thread_id.

Distribution

• LangGraph (OSS) — MIT, pip install langgraph. Self-host with any checkpointer backend. This is what a GL build would use — free, no usage caps.
• LangGraph Platform — the paid managed tier: hosted deployment, an ops UI, task queues, standby scaling. Cloud SaaS rides on LangSmith Plus (~$39/user/mo) plus per-node-execution and standby-minute charges. There's a free Self-Hosted Lite band, but the managed value is the pitch. Skip for GL — self-host the OSS runtime.

How to integrate

Default integration order for a GL orchestration build:

1. Define the state schema. A typed dict / Pydantic model naming every field the flow carries. This is the spec — get it tight before wiring nodes.
2. Write nodes as pure-ish functions. Each node does one thing and returns a state delta. Keep the LLM-reasoning inside a node behind a DSPy Module — a DSPy module is a perfectly good node body. LangGraph owns between-step control; DSPy owns within-step reasoning.
3. Wire edges. Direct edges for the happy path; conditional edges for branch/loop/retry. Set the entry point; route terminal states to END.
4. Add a checkpointer. Start with InMemorySaver in tests, graduate to PostgresSaver against the shared Postgres instance — one DB per project, no new vendor.
5. Add interrupts where a human belongs. Any step that needs Neil's sign-off (publish a post, send a reading, execute a trade suggestion) becomes an interrupt — the graph parks and resumes on approval.
6. Persist the audit trail. Checkpoints are the run history; mirror the durable decisions into Neo4j (canonical state) so the graph and the knowledge layer agree. Neo4j answers what's true; the checkpointer answers where the run is.

The floor is low: a two-node graph with a Postgres checkpointer is a day of work and gets you durable, resumable, human-pausable flows. Promote to more actors only when a real flow demands it.

In the GL stack

Concrete places LangGraph could slot into the three active GL products. None are shipped — this is the tempted-but-not-committed list, and the "chose otherwise" here is soft: DSPy and LangGraph are complementary, not rivals.

builddaily.io

• Multi-step publish flow. Raw bujo log → DSPy draft node → self-critique node → interrupt for Neil's approval → publish node. Today this is manual choreography across subagents; as a graph it's durable and pausable, and a crash mid-flow resumes instead of restarting.
• Chat-bridge as a graph. Retrieval node → rerank node → answer node, with a conditional edge that loops back to retrieve-again when the answer node reports low confidence. The loop is the thing a plain pipeline can't express cleanly.

paiddaily.io

• Catalyst-to-brief pipeline. Ingest node → Pendle classifier node → Aerodrome risk node → brief-writer node, with a human interrupt before anything trade-adjacent ships. Long-running and multi-actor — exactly LangGraph's shape.
• Durable research runs. A "deep dive on this protocol" flow that fans out across sources over minutes, checkpointing as it goes, so a restart doesn't lose the partial work.

sagedaily.io

• Durable long-running readings. A multi-card spread that draws → computes transits → reflects per card → synthesizes is currently one big call. As a graph, each stage checkpoints; a slow or failed reading resumes instead of charging the user for a redo.
• Human-in-the-loop reading review. For premium readings, interrupt after draft so Neil (or a reviewer) can nudge voice before send — persisted, resumable, no re-generation.

The honest read: none of these require LangGraph to ship a v1. They require it to ship a v1 that's durable — and GL hasn't yet hit the wall where session-bound orchestration fails loudly enough to justify the runtime. That wall is coming; this page is the bookmark.

Gotchas

• It's orchestration, not reasoning. LangGraph will not improve the quality of any single LLM call — it moves control between calls. Put the DSPy module inside a node; don't expect the graph to make the node smarter.
• The state schema is the whole design. A sloppy state model turns into merge conflicts between node updates and reducers you didn't plan for. Design the state before the graph, like a database schema.
• Checkpointer choice is a production decision, not a detail. InMemorySaver loses everything on restart — it's for tests. Ship with PostgresSaver (or Sqlite for single-server) or you don't actually have durability.
• Interrupts need a real thread + a durable checkpointer. An interrupt with an in-memory saver evaporates on restart. The pause is only as durable as the backend behind it.
• Loops can run away. Conditional edges that route back on their own output can cycle forever. Add a step counter / recursion limit to every loop; the framework has one, use it.
• The docs and the LangChain docs are entangled. Much of the material assumes you're also using LangChain. You aren't required to — but you'll be reading around the assumption constantly.

Risks

• Vendor gravity. LangGraph is separable in principle, but the surrounding ecosystem (LangSmith, LangGraph Platform, the docs) keeps pulling toward the paid LangChain stack. The OSS runtime is genuinely free and MIT — the risk is drift into the managed tier, not a license trap. Stay self-hosted on purpose.
• Framework lock-in on the orchestration layer. A graph of nodes + a state schema + checkpointer wiring is real LangGraph-specific code. Porting a mature graph back to plain functions is a rewrite. Keep node bodies framework-agnostic (a node calls a DSPy module or a plain function) so the swappable value stays swappable.
• Solving a problem you don't have yet. The biggest honest risk for GL: adopting durable orchestration before the pain justifies it. Session-bound subagents + Neo4j work for today's load. LangGraph earns its keep the day a long-running flow crashing mid-run becomes a real cost — not before.
• Move-fast API surface. The framework has churned across its 0.x → 1.x era. Pin the version; budget a re-pin per upgrade.

Alternatives

Related

• DSPy — the per-step reasoning layer. A DSPy Module is a natural LangGraph node; LangGraph owns control between steps, DSPy owns quality within a step. Complementary, not competing.
• LangChain — LangGraph's sibling and the toolkit it grew out of. Separable — you can run LangGraph without buying into LangChain's prompt-template model.
• LangSmith — the observability + platform surface the LangChain ecosystem pulls toward. Note the gravity; stay on the free OSS runtime on purpose.