Why LangGraph checkpoints matter more in multi-agent than in single agent setups

Flashcard·Medium·4.0 · 0·~30s·Asked atLocus Razorpay Swiggy

Attempt it

A single-agent run is one loop. If it crashes you lose the loop and rerun from scratch; the cost is whatever the loop has spent so far, usually small.

A multi-agent run is a longer trajectory: planner, three workers in parallel, reducer, possibly a critic loop with revisions. If the critic node crashes at the end, you have already paid for the planner plus three workers plus the reducer. Without checkpoints you redo all of that. With checkpoints the runtime resumes from the last successful node and reruns only the failing one. The same property enables human in the loop: pause at a node, let a human review the state, resume. Multi-agent workflows hit pause and resume situations far more often than single-agent ones, so the checkpoint surface gets paid back faster.

Your answer

The payback on checkpointing depends on how much work you lose when a node fails. That number is small for single agent runs and large for multi agent runs. A single agent run is essentially one loop: read message, call model, call tools, repeat until done. If it crashes mid loop, you lose the loop. Total wasted work is usually a few LLM calls and a few tool invocations. Rerunning from scratch is acceptable. A multi agent run is a much longer trajectory. A typical LangGraph topology runs a planner node, three workers in parallel, a reducer that merges their outputs, and a critic node that asks for revisions if needed. By the time the critic runs, you have already spent on the planner, three worker inferences, three sets of tool calls, and the reducer. If the critic crashes here, restarting from scratch reruns all of that. With per node checkpoints, the runtime resumes from the last successful node and reruns only the critic. Checkpoints also unlock human in the loop: pause at a node, let a person review the state and edit it, resume. Multi agent workflows hit this pattern far more often than single agent loops, so the checkpoint infrastructure earns its keep faster.

LangGraph checkpoints persist the graph state after every node executes, so a crash or pause can be resumed from the last saved state instead of from scratch. The disproportionate payoff in multi agent comes from two structural facts. ### Fact 1: trajectory length governs wasted work A single agent crash loses one loop, maybe 5 to 10K tokens. A multi agent crash near the end of a long trajectory loses the planner plus N workers in parallel plus the reducer plus any prior critic revisions, easily 100 to 300K tokens. The same checkpoint feature has 20 to 50 times more value per failure. ### Fact 2: pause and resume is a multi agent native pattern Most interesting multi agent workflows want a human in the loop: pause after the planner, let a human approve the plan; pause after the workers, let a human edit one worker's output; pause before the critic decides to revise, let a human steer the criterion. Checkpoints make pause and resume cheap because the runtime can serialise the state, hand control back to the application, and resume later from the same point. ### The cost shape Checkpointing adds operational complexity (a backing store, serialisation of node state, retry semantics). On a single agent loop the complexity is often more than the saved work justifies. On a multi agent trajectory it pays back on the first long failure. The practical rule: turn on checkpoints by default for any LangGraph topology with more than three nodes, and almost always for any topology that supports interrupts.

TL;DR

A failed multi agent run wastes a long expensive trajectory while a single agent loses one loop; checkpoints resume from the last good node and unlock pause and resume.

Memory aid

Easy to grasp

Imagine baking a cake. If you mess up while still mixing the batter, you tip it out and start over; you have only lost some flour and eggs. Now imagine a five course dinner where every course depends on the one before. If you burn the dessert at the end, you do not want to restart from soup. You want a saved point at each finished course so you can pick up where things went wrong. LangGraph checkpoints are the saved points between dinner courses. A single agent is the cake. A multi agent run is the five course dinner, and the saved points pay back much faster because each course took serious time and money to make.

Key concepts

LLM frameworks Multi agent systems

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

LangGraph's checkpoint primitive is one of the framework's most important features for multi agent production deployments, and one of the easiest to under value in single agent prototypes. The disproportionate payoff comes from two structural properties of multi agent workflows: longer trajectories with higher per failure cost, and a frequent need for pause and resume that single agent loops rarely have.

This answer walks through both properties, explains how checkpointing turns LangGraph into a durable execution engine, and ends with the operational trap of turning checkpoints on for every workflow regardless of shape.

What checkpointing actually does in LangGraph

A LangGraph checkpointer is a pluggable storage layer that persists the graph state after every node executes. The state is the typed dictionary that flows through the graph; the checkpoint captures its full value plus metadata (which node just ran, what edges remain, the thread id that identifies this particular run).

The runtime contract

When a node returns, the runtime writes a checkpoint to the configured store. If the next node crashes (or the process crashes, or the user pauses), the next time you invoke the graph with the same thread id, the runtime loads the most recent checkpoint and resumes from there. The nodes already executed are not rerun.

Backing store choices

Three first class options:

MemorySaver: in process dictionary. Fastest, but loses everything on process exit. Right for tests.
SqliteSaver: local SQLite file. Durable across restarts; fine for single node deployments. Sufficient for many production cases.
PostgresSaver: real database, with concurrent reads and writes and proper transactions. The default for production multi tenant deployments where many tasks can be paused simultaneously.

Custom backends are easy to add. Some teams ship Redis backed checkpointers for low latency pause and resume on short trajectories.

Why trajectory length governs the value of checkpoints

Pause and resume is the bigger production win

The operational trap and when to turn checkpoints off

Situations where this technique stops working.

2–4 min · Everything important, quickly.

python

from langgraph.graph import StateGraph
from langgraph.checkpoint.postgres import PostgresSaver
from typing import TypedDict

class AgentState(TypedDict):
    plan: str
    worker_outputs: list[str]
    critique: str

def planner(state: AgentState) -> AgentState:
    state["plan"] = "Step 1, Step 2, Step 3"
    return state

def worker(state: AgentState) -> AgentState:
    state["worker_outputs"].append("work done")
    return state

def critic(state: AgentState) -> AgentState:
    state["critique"] = "looks fine"
    return state

graph = StateGraph(AgentState)
graph.add_node("planner", planner)
graph.add_node("worker", worker)
graph.add_node("critic", critic)
graph.add_edge("planner", "worker")
graph.add_edge("worker", "critic")
graph.set_entry_point("planner")

checkpointer = PostgresSaver.from_conn_string("postgresql://...")
app = graph.compile(checkpointer=checkpointer)

config = {"configurable": {"thread_id": "task-42"}}
# Run; if critic crashes, rerun the same call and resume from after worker
app.invoke({"plan": "", "worker_outputs": [], "critique": ""}, config=config)

Property	Single agent loop	Multi agent trajectory
Work lost on a mid run crash	One loop, around 5 to 10K tokens	Whole trajectory so far, often 100K plus tokens
Need for pause and resume	Rare	Common (approvals, human review, escalations)
Checkpoint payback per failure	Small relative to operational cost	Large; pays back on the first failure
Recommended default	Off unless explicit need	On for any topology with three plus nodes

Real products, models, and research that use this idea.

LangGraph documentation in 2025 and 2026 ships checkpointers for memory, SQLite, and Postgres as first class primitives, with explicit guidance on which to use per deployment shape.
Production teams running LangGraph multi agent systems in 2026 commonly back checkpoints with Postgres for the human in the loop approval pattern, where thousands of tasks can be paused awaiting human action.

What an interviewer would ask next. Try answering before peeking at the approach.

QHow would you implement an approval gate using LangGraph checkpoints?

Add a node that calls interrupt() before the destructive action; the runtime serialises state and returns control to the application. The application persists the thread id, presents the state to a human, and on approval calls app.invoke() with the same thread id and a resume command, which picks up at the interrupted node.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Treating checkpoints as a nice to have for any workflow, and missing that the payback is governed by trajectory length and per node cost; a single agent loop rarely earns the operational complexity.

60 second bullets to scan on the way to the call.

What a LangGraph checkpoint captures and when it is written
Why the cost of a failure scales with trajectory length in multi agent designs

Primary sources. Browse if you want the original framing.