DEV Community: Priyansh Singhal

I Split One Agent Into Three. The Plan Never Reached the Executor.

Priyansh Singhal — Wed, 14 Oct 2026 07:05:35 +0000

A LangGraph subgraph boundary dropped the plan, and the gain came from re-reading the source, not the plan.

I gave a local 8B model a planning step before it did the real work, and modeled the handoff the way a LangGraph subgraph's own state schema actually behaves: a key the parent step produces but the child's schema never declares is simply gone on the other side. The plan never reached the next step intact: on every single task, the part that crossed that boundary was a 60-character fragment of what the planner actually wrote. I expected that to hurt. The three-step pipeline still beat the single-call baseline on accuracy, by a real margin. Those two facts together are the whole reason this is worth reading, because the second one does not mean what it looks like it means.

I wrote this with AI assistance, and I fact-checked and edited every claim myself.

Proof block. Ollama's llama3.1:8b, running locally, zero API cost, temperature 0, fixed seed. 12 synthetic incident-report extraction tasks, one deterministic run per condition (a real, stated limit, not a hidden one). Condition A: one call per task. Condition B: a plain-Python three-step pipeline, planner then executor then reviewer, that models a LangGraph subgraph's state-schema boundary rather than running an actual LangGraph graph, 36 calls total. Every claim below traces to a public, re-runnable repository: github.com/priyansh18/agent-handoff-loss-benchmark.

TL;DR

Four things came out of this run worth stating before any explanation:

The three-step pipeline scored 91.7% field accuracy against the single call's 83.3%, at 4.4x the tokens and 5.7x the wall-clock time.
On 12 out of 12 tasks, the planner's own notes (368 to 584 characters each) were truncated to 60 characters before the executor ever saw them, a real state-schema mismatch, not a prompt bug.
Three individual fields, across three different tasks, flipped from wrong to right. I logged the executor's intermediate answer separately from the reviewer's final one, specifically so I could check which step did the work instead of assuming: the executor alone, reading the full report plus whatever fragment of the hint survived, already reaches 88.9% (32/36) before the reviewer ever runs. The reviewer adds exactly one more field on top of that.
None of the three fixes trace to the planner's hint carrying something useful across the boundary. Two happened with a hint that was pure boilerplate, no task-specific content at all. The third happened with a hint that did contain a genuinely useful word, by accident of where the planner's sentence break fell, not because the pipeline was designed to protect it.

Multi-agent LangGraph handoff loss, which is the specific failure this run reproduces in miniature, is the same shape of problem Anthropic names in its own multi-agent systems engineering writeup: agents typically use about 4x more tokens than a single chat turn, and a full multi-agent system about 15x, with part of that cost going toward what the piece calls a "game of telephone" when one agent's output gets summarized and re-summarized on its way to the next one. Anthropic's own fix is to have subagents write full output to a shared store instead of passing a compressed summary through conversation. I wanted a number for the failure mode before I believed the fix, not just a paragraph agreeing with it.

The hypothesis

Stated before running anything, so the result can actually fail it: splitting a single extraction call into a planner-then-executor-then-reviewer pipeline, with the executor's state schema narrower than what the planner produces, will measurably lose information at the handoff, and that loss will show up as no better (or worse) accuracy than the single-call baseline, not as an improvement. The first half of that held. The second half was wrong, for a reason worth sitting with.

Method: the subgraph handoff

Twelve short, fictional incident reports, written as test fixtures, each describing one bug: a Redis connection pool exhausted by a feature-flag rollout, a stale model artifact overwriting a cached file, a password-reset link truncated by a URL shortener, and nine more in the same shape. Each has a ground truth of required keywords for three fields: root_cause, affected_component, fix_action. A field counts correct if the model's answer contains at least one of the required keywords for that field, a deliberately mechanical grader so the scoring is reproducible and not a matter of my own judgment call.

Condition A asks llama3.1:8b once per task for all three fields as JSON. Condition B runs three calls per task:

# The subgraph boundary, as code, not prose.
# The planner writes full notes; the executor only ever sees this:
focus_hint = plan_notes.split(".")[0][:60] if plan_notes else ""

That line is the entire experiment's load-bearing detail, and it is plain Python, not a LangGraph StateGraph call. I wrote it that way deliberately, to model something LangGraph's own subgraph docs describe without needing the framework's full runtime: a subgraph's state schema is what actually crosses the parent/child boundary, and a key the parent step produced but the child's schema never declared is simply absent on the other side. No exception, no warning. I made the schema narrow on purpose, the way a team under deadline pressure genuinely does, by wiring a field name before thinking hard about what actually needs to survive the handoff.

The executor then extracts the three fields with that 60-character hint attached, and a reviewer sees the original report plus the executor's JSON and can correct it. Three calls, three chances to get something right, one shared report each time.

Results, before any explanation

Single call vs. three-step pipeline, same 12 tasks, same model, same machine. Image by author, generated from the run's own summary.json.

The numbers, side by side:

Field accuracy: 30/36 (83.3%) for the single call vs. 33/36 (91.7%) for the three-step pipeline.
Tasks with all 3 fields correct: 7/12 vs. 9/12.
LLM calls: 12 vs. 36.
Total tokens: 1,659 vs. 7,323.
Wall-clock time: 72.7s vs. 411.1s.

And the handoff number, which the comparison above does not show: on 12 of 12 tasks, the full planner output ran 368 to 584 characters, and the focus_hint that actually reached the executor was capped at 60. Here is what that looked like on one task, with the exact logged text, not a paraphrase:

Image by author, generated programmatically from the actual run's raw_results.jsonl.

Planner, in full, on the retry-storm task: "Here's a short investigation note: 'Review the system logs to identify the timing and duration of the downstream outage and its impact on the billing worker queue. Investigate the retry logic to determine why the system did not implement exponential backoff initially, and examine the configuration or code changes that were made to implement backoff. Additionally, assess whether the retry storm caused any data inconsistencies or other issues.'" What the executor received: "Here's a short investigation note: 'Review the system logs", 60 characters, cut before "retry storm" or "backoff" ever appear.

Failure analysis: where the gain actually came from

Three fields, across three different tasks, flipped from wrong to right between conditions. I logged the executor's intermediate answer separately from the reviewer's final one specifically so I could check which step did the work instead of assuming, and the three did not all resolve the same way.

On feature-flag-leak, the planner's hint was pure boilerplate: "Here's a short investigation note: Investigation Note", 60 characters of preamble, zero task-specific content, the cleanest version of a useless hint in the whole run. The executor's own answer, before the reviewer ever touched it, still read "feature-flag targeting rule leak due to shared cache entry reuse", correct, despite the hint carrying nothing. It got there by reading the full original report, which every step in the pipeline receives in addition to whatever the planner's hint says.

On retry-storm, the hint was semi-generic ("Review the system logs"), not pure boilerplate, but not specific either. The executor's answer stayed wrong, same gap as the single call: "downstream outage," no mention of a retry storm. The reviewer step, given the full report a second time, corrected it to "downstream outage caused a retry storm" and passed. This is the one fix in the whole run that specifically needed the reviewer, not just the executor's own read.

The third, on redis-pool, is the one honest complication: the single call missed "redis" / "connection pool," but the executor fixed it, and this time the 60-character hint actually did contain "Review the Redis connection pool confi", the planner happened to lead with exactly the right words before the cutoff landed. I can't rule out the hint helping here, and saying it was "useless" for this task specifically would be overclaiming in the opposite direction. What I can say is that two of the three fixes happened with hints that contributed nothing, and the one case where the hint might have helped was a matter of where a sentence break happened to fall, not something the pipeline's schema was designed to guarantee.

Put together: the planner step, measured honestly, earned nothing reliable this run. Its one plausible contribution depended on accidental phrasing, not the architecture. The executor's own full-report read, independent of the hint, already gets to 88.9% (32/36), measured directly from the saved intermediate answers, not inferred. The reviewer adds exactly one more field on top of that, 33/36. If I had cut the planner and reviewer entirely and sent the report straight to one executor-shaped call, I would expect something close to that 88.9% figure, not the 83.3% single-call baseline, because the executor prompt itself asks for more structured output than the bare single-call prompt does. I did not run that exact ablation, so that specific comparison stays a reasoned expectation, not a measured result; everything else in this section is measured.

There is a real theoretical reason to expect source re-reading to matter more than hand-off content here, not just my own anecdote. A April 2026 Stanford preprint, "Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets" by Dat Tran and Douwe Kiela, holds the reasoning-token budget constant across single- and multi-agent setups on three model families and finds single agents consistently match or beat multi-agent ones. Their explanation leans on the Data Processing Inequality: once one agent passes a processed version of its context to the next, information can only be lost or stay the same across that step, never gained. My focus_hint truncation is that inequality made concrete and measurable, not an edge case. My own run adds one more data point in the same direction, with the mechanism visible in the logs rather than inferred: the win was real, 91.7% beats 83.3%, but it was bought mostly by steps re-reading the original source report, not by the architecture's planning step, which is the part most multi-agent write-ups spend the most words justifying.

When a review step earns its cost, and when it doesn't

The honest reading of this run is narrower than "multi-agent wins" or "multi-agent is a trap." Both would oversell a 12-task local run. What it does support: a step that looks at the original source material again rather than trusting an earlier step's summary of it can catch real mistakes, and that happened across three fields here, at the cost of 4.4x the tokens and 5.7x the latency. A planning pass that hands off through a schema too narrow for what it produced bought nothing reliable, and would have looked close to identical in the summary table if I had cut it entirely and gone straight from report to executor to reviewer.

Before adding a planning step to any pipeline, the question worth asking is not "would more structure help," it's "what, specifically, needs to survive from this step to the next one, and does my state schema actually carry it." That is a concrete, checkable thing, not a vibe. Before adding a review step, the better question is whether the reviewer gets the original source material again or only the prior step's output, since my reviewer's advantage here came specifically from re-reading the report, not from critiquing the executor's JSON in isolation.

Reproducibility and the honest gaps

Full script, task set, raw per-task output, and the chart above, all generated directly from this run: github.com/priyansh18/agent-handoff-loss-benchmark. Everything ran locally against Ollama, zero API keys, reproducible on any machine with the same model pulled (exact numbers may still shift slightly with different hardware or Ollama versions, since wall-clock time and token counts aren't hardware-independent). One real limitation: one deterministic run per condition, not a repeated-trial distribution, so a single flipped field would move the accuracy numbers by one unit out of 36 (2.8 percentage points) either way; I'm stating the result as what happened in this run, not as a tight confidence interval. A second limitation: the keyword-based grader rewards completeness over precision, which partly explains why three other tasks stayed wrong in both conditions (detailed in the repo's failure_examples/). I think it's fair for this task shape, but it's a judgment call, named here rather than left to make the numbers look cleaner than they are.

If you've built a planner-executor-reviewer pipeline yourself: did the planning step ever get checked for what actually survives the handoff, or did it get trusted the same way I almost trusted mine?

Resources

LangGraph subgraphs and state-schema docs: docs.langchain.com/oss/python/langgraph/use-subgraphs
Anthropic, "How we built our multi-agent research system": anthropic.com/engineering/multi-agent-research-system
Tran and Kiela, "Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets," April 2026: arxiv.org/abs/2604.02460
Full reproducibility package: github.com/priyansh18/agent-handoff-loss-benchmark, tasks.py and run_bench.py produced every number above, raw_results.jsonl has the full per-task output including every truncated focus_hint and the executor's intermediate answer, and failure_examples/ walks through each flipped and still-wrong task individually.

More from me: notes.priyanshsinghal.com has the roadmap these posts draw from, and I'm on LinkedIn at linkedin.com/in/priyanshsinghal.

What Your LangGraph Logs Miss When a Node Fails

Priyansh Singhal — Wed, 07 Oct 2026 07:53:31 +0000

Two seeded failures in one small graph, and what each logging approach actually recorded.

When a LangGraph run dies, the log usually tells you the same thing twice: a node started, a node stopped, an exception was raised. It almost never tells you what the node was given. I wanted to know what a log has to contain before the failure happens, so I broke a three-node graph two different ways and checked what each run actually recorded.

I wrote this with AI assistance, and I fact-checked and edited every claim myself.

Proof

Every number in this piece comes from one run per scenario on LangGraph 1.2.12 with checkpoint 4.2.0, on Python 3.14.7. There is no LLM and no API key involved, so the API cost is zero. The three scenarios are a clean run, a transient timeout that a retry policy should absorb, and a fetch that returns an HTML error page where JSON is expected. Each run gets a fresh thread and an in-memory checkpointer. One run per scenario is enough to show the mechanism. It is not enough to estimate how often any of this happens in production.

TL;DR

The retry that succeeded left no trace in the task stream. Only a counter I put inside the node showed that fetch ran twice.
The failing task did not produce an error or finish event in the stream. The exception came out of the stream call itself.
The bad payload was visible in two places: the start event for parse, and the checkpoint saved just before the failure. My print statement threw both away.

Hypothesis

If the checkpoint store records the state each node received, a failure can be explained from the store alone, without a print statement in the node. If it does not, the node-level logs are the only evidence you have. The runs below test that for the input, and separately check whether the stream reports retries at all.

Method

The graph has three nodes. Fetch can fail transiently, parse turns the fetched string into a dict, and write produces the result. The core of it looks like this:

import json
from typing import TypedDict
from langgraph.graph import StateGraph, START, END
from langgraph.checkpoint.memory import InMemorySaver
from langgraph.types import RetryPolicy

class State(TypedDict, total=False):
    raw: str
    parsed: dict
    result: str

def fetch(state):
    return {"raw": '{"id": 7, "items": [1, 2, 3]}'}

def parse(state):
    return {"parsed": json.loads(state["raw"])}

def write(state):
    return {"result": f"wrote {len(state['parsed']['items'])} items"}

graph = StateGraph(State)
graph.add_node("fetch", fetch, retry_policy=RetryPolicy(max_attempts=3, retry_on=TimeoutError))
graph.add_node("parse", parse)
graph.add_node("write", write)
graph.add_edge(START, "fetch")
graph.add_edge("fetch", "parse")
graph.add_edge("parse", "write")
graph.add_edge("write", END)
app = graph.compile(checkpointer=InMemorySaver())

config = {"configurable": {"thread_id": "run-1"}}
for event in app.stream({}, config, stream_mode="tasks", version="v2"):
    print(event["type"], event["data"].get("name"))

The transient scenario makes fetch's first call raise a TimeoutError. The bad-input scenario keeps the same code but makes fetch return <html>error page</html>. The graph runs the same way in both. Only fetch's body changes.

The snippet compiles with an in-memory checkpointer so the saved steps can be read after the run. The task stream itself does not need one. I ran the same three-node graph with no checkpointer and it still emitted a start and a finish for every node.

What each run recorded

The clean run saved five checkpoints: the input, one after each of the three nodes, and the end. The task stream showed a start and a finish for fetch, parse and write. Nothing surprising happened, which is the point of a baseline.

The transient run called fetch twice. The task stream still showed one start and one finish for fetch, with no mention of the first attempt. The run completed with the same five checkpoints as the clean run. From the stream, the retry looks like it never happened. The only record of it was the counter I put inside the node.

The bad-input run saved three checkpoints and then raised JSONDecodeError inside parse. The most recent checkpoint is at step 1, and its next node is parse. Its state holds the raw <html>error page</html> string, which is the exact input that broke parse. On the stream, parse's start event also carried that input. Then the exception came out of the stream call. I did not get a finished event for parse, and no event carried the error.

(Checkpoint timeline diagram: see the original post for the visual.)

Failure analysis

The failure reached my code as an exception from the stream call, not as an event. A logger that only records task finishes or error events would miss it. The input was not missing from the stream, though. The start event for parse carried it, and so did the checkpoint. Both are only useful if your code keeps them, which a print statement that records just the task name does not.

The stream also does not report the retry, at least in tasks mode. A retry that succeeds is invisible to that view. LangGraph's own retry code does write a line through its logger at INFO level (langgraph.pregel._retry, "Retrying task fetch ... (attempt 1)"), so the record exists outside the stream. If you do not enable that logger, the node has to count the attempts itself.

What to log before it fails

Here is what I would log on every node, based on what the two failures showed. Each item maps to something my print-based approach threw away or could not see.

First, capture retry attempts. Either count them inside the node, or enable the retry logger at INFO so each retry is recorded with its exception. Second, record the input each node received, or at least its size and a hash. The checkpoint held the HTML here, but a checkpoint only exists if you persisted one. Third, put the thread ID and the checkpoint step on every log line, so a log entry can be joined to the saved state. Fourth, log the exception together with the payload that caused it, at the exact boundary where parsing happens.

There is a cost to the second and fourth items. Checkpoints store the full state, and logs that include raw payloads can leak whatever the payload contains. Log size and hash by default, and keep full payloads only for nodes that failed, with redaction before anything leaves the process.

When this is enough, and when it is not

The checkpoint store is enough when you have one and you can read it after the run. Without a checkpointer, the task stream still reports each node's input, but there are no saved steps to read afterwards, so the record lasts only as long as your logs. Retry attempts are the one thing neither the stream nor the checkpoint shows, so they need the node counter or the retry logger either way. If your payloads are large or sensitive, store a hash and a size, and treat the checkpoint itself as data that needs the same retention rules as your logs.

Start with the bad input, because that is what the store can explain. The retry count is the piece you have to add yourself.

Resources

LangGraph streaming docs: docs.langchain.com/oss/python/langgraph/streaming
LangGraph persistence docs: docs.langchain.com/oss/python/langgraph/persistence
I have not published a repository for this experiment yet. The graph above is the full core of it, and the two failure variants change only the body of fetch.

The question I'd like you to answer in the comments: on a parse node, would you log the raw payload, its hash, or nothing, and what would you do with that log once the run succeeded?

More from me: notes.priyanshsinghal.com has the roadmap these posts draw from, and I'm on LinkedIn at linkedin.com/in/priyanshsinghal.

Your LangGraph Node Runs Twice After interrupt(). That's by Design.

Priyansh Singhal — Wed, 30 Sep 2026 08:59:08 +0000

Checkpoints are save points at super-step boundaries. Resume, durability and subgraph state all follow from that.

Put a print on the first line of a LangGraph node, call interrupt() a few lines later, resume the graph with a human's answer, and the print fires twice. The first time you see that you assume you wired something wrong. You didn't. LangGraph does not resume a paused node from the line it stopped on. It goes back to the last saved checkpoint and runs the whole node again from the top, and this time interrupt() returns the answer instead of pausing.

Once that clicks, three things tutorials teach as separate features (human-in-the-loop, crash recovery, time travel) turn out to be one mechanism seen from three angles. A checkpoint is a save point. Everything else is what you can do with a save point. This is the explanation I wanted while working through human-in-the-loop in my own agent notes, so here it is, with the 20-line script that reproduces the double print. Every behaviour below was run on langgraph 1.2.12, not just read in the docs; the one place they disagree is called out.

I wrote this with AI assistance, and I fact-checked and edited every claim myself.

What a checkpoint actually is

LangGraph runs a graph in rounds it calls super-steps. In one super-step, every node that is scheduled runs (in parallel if there are several), their state updates are merged, and the runtime works out which nodes fire next. A plain START -> a -> b -> END graph is three super-steps: one for the input, one for a, one for b.

The docs put it in one line: LangGraph creates a checkpoint at each super-step boundary. Attach a checkpointer, run that three-node graph on a thread, and get_state_history hands back four snapshots: an empty one before the input landed, then one after each step. Each snapshot holds the full state values at that moment, the nodes due to run next, a step number, and a link to its parent snapshot. That is the entire save file.

Two details matter for everything that follows. First, checkpoints are keyed by thread_id, passed in the config on every call. A new thread starts with empty state and never sees another thread's history. Second, the docs are precise about scope: checkpointers are thread-scoped, short-term memory (conversation continuity, human-in-the-loop, time travel, fault tolerance), and a separate store handles cross-thread, long-term memory (user preferences, facts). A checkpointer remembers a thread. It does not remember a user.

Why the node runs twice

Here is the smallest reproduction. No model, no API key, just a node that asks a human before it commits.

from typing import TypedDict
from langgraph.graph import StateGraph, START, END
from langgraph.checkpoint.memory import InMemorySaver
from langgraph.types import interrupt, Command

class State(TypedDict):
    decision: str

def approve(state: State) -> State:
    print("approve node entered")          # runs before the pause
    answer = interrupt("Ship it?")         # pause here, wait for a human
    print(f"resumed with {answer!r}")
    return {"decision": answer}

graph = (
    StateGraph(State)
    .add_node("approve", approve)
    .add_edge(START, "approve")
    .add_edge("approve", END)
    .compile(checkpointer=InMemorySaver())
)

config = {"configurable": {"thread_id": "review-1"}}
graph.invoke({"decision": ""}, config)          # pauses at interrupt
graph.invoke(Command(resume="yes"), config)     # human answered

On langgraph 1.2.12 the output is three lines: approve node entered, approve node entered, resumed with 'yes'.

Walk through what happened. The first invoke enters the node, prints, reaches interrupt("Ship it?"), and stops. The runtime writes a checkpoint for the thread, and the return value of invoke carries the question under a key called __interrupt__. Nothing after the interrupt line ran, so decision in state is still the empty string you seeded.

The second invoke passes Command(resume="yes") on the same thread. This is the part the docs state plainly and most tutorials skip: the runtime restarts the entire node from the beginning. It does not resume from the exact line where interrupt was called. So the print fires again, execution reaches interrupt() again, and this time the call does not pause. The value you passed in Command(resume=...) becomes its return value. The node carries on to the second print and returns.

My read on why it works this way: the alternative is freezing a Python call stack mid-function, and nothing serializes that safely across a restart, a different worker, or a deploy. Saving state at a boundary and replaying is what lets a pause be resumed by something other than the exact process that paused. The docs describe the model in one sentence: execution returns to a checkpoint boundary, and the workflow replays forward until it reaches the pause again.

Three consequences follow, and each one is easy to trip over.

Anything before interrupt() must be safe to run twice. The docs say side effects called before interrupt must be idempotent, and their own example is the database row: inserting one before the pause inserts it again on resume. Put the write after the interrupt, or make it an upsert, or use an idempotency key. Do not put the email send on line one and the approval on line three.

No checkpointer, no resume. Run the snippet above without checkpointer=InMemorySaver() and the first call still returns __interrupt__, which is misleading, because there is nowhere to resume from. The second call raises RuntimeError: Cannot use Command(resume=...) without checkpointer. The docs list a checkpointer as requirement number one for interrupt, and the error message is the runtime agreeing.

Order matters if a node interrupts more than once. Resume values are matched to interrupt calls strictly by index, in the order the calls happen during the replay. A node with two interrupts takes two resumes, and the first resume value lands in the first call. Add a conditional interrupt before an existing one and the wrong answer lands in the wrong call. Keep interrupts in a node few and their order fixed.

Durability: what survives a crash

If checkpoints are save points, the next question is how often the game saves. LangGraph exposes that as a durability argument on invoke and stream, with three modes. Leave it unset and 1.2.12 uses "async"; the default is in langgraph/pregel/main.py, the docs page names none.

"exit" persists only when the run exits, whether by finishing, erroring, or hitting an interrupt. Fastest, and intermediate state is not saved, so a process crash mid-run loses everything since the start. "async" writes each checkpoint while the next step is already executing, which the docs describe as good performance and durability with a small risk of a missed checkpoint if the process dies at the wrong moment. "sync" writes every checkpoint before the next step starts, highest durability, some overhead.

You can see the difference without a crash. The three-node graph from earlier leaves four snapshots in history under "async" or "sync", and exactly one under "exit". That one is the finished state. Time travel to the point before b is impossible on that thread, because the save point was never written.

My view: "exit" is right for a cheap graph where a retry from scratch costs nothing, and wrong the moment a node does anything you would not want repeated. And no mode helps if the checkpointer itself is InMemorySaver. It keeps checkpoints in RAM, and the docs say it plainly: when the process restarts, all checkpoints are lost. Most examples, the docs' own included, use it because it needs no setup. Production needs PostgresSaver or at least SqliteSaver, or your carefully durable checkpoints evaporate on the next deploy.

Subgraphs and time travel are the same save point

The two features that look most separate are the ones that fall out of the model most directly.

Subgraphs. Compile a subgraph without a checkpointer and add it as a node in a parent that has one, and the subgraph inherits the parent's checkpointer. An interrupt() inside the subgraph surfaces at the parent's invoke exactly like a top-level one, and Command(resume=...) on the parent resumes it. Its checkpoints live in the same store under a namespace of the form child_node_name:uuid, nested subgraphs joined with |. You can read them with get_state(config, subgraphs=True).

Where the save points sit decides what replays. From the parent's history the whole subgraph is one step: START -> child -> END leaves three snapshots however many nodes the child has. The child's own save points live under its namespace, so when a two-node subgraph pauses in its second node, resume re-runs only that node; the first one's result was already saved. checkpointer=True drops the uuid from the namespace and, per the docs, makes the subgraph per-thread: its state carries across calls on the same thread. checkpointer=False saves nothing inside. The docs say no interrupts or durable execution. On 1.2.12 it was one step short of that, and it is the place the docs and the run disagree: the interrupt still surfaced, the resume still completed, but both nodes ran again, the first one included, because there was no save point inside to replay from. Same rule, one level up: everything in a stateless subgraph before the pause must be safe to run twice.

Time travel. This is loading an older save. Pull the history, pick the snapshot whose next is the node you want to re-run, call update_state on that snapshot's config with new values, then invoke(None, fork_config). On the three-node graph, forking the snapshot before b with n=100 returns n=1000, because b multiplies by ten and never knew the original run existed. The fork is a new branch on the same thread; the original checkpoints stay in history, which is what makes this safe for debugging a bad agent turn.

Seen this way, human-in-the-loop, fault tolerance, subgraph state and time travel are one feature with four names. The runtime writes a snapshot at every boundary, and resuming from any snapshot replays forward.

How to actually use this

A short checklist, in the order the mistakes usually happen:

Decide what a thread_id means in your app before writing a node. One per conversation is the usual answer. One per user is a store's job, not a checkpointer's.
In any node that calls interrupt(), move side effects below it or make them idempotent. Read the node top to bottom and ask what happens if this runs twice.
Pick durability on purpose per graph instead of taking the "async" default. Long, expensive, or side-effecting runs want "sync"; cheap replayable ones can take "exit".
Swap InMemorySaver for a persistent saver before the first deploy, not after the first lost approval.
For each subgraph, choose: inherit (default), carry state across calls on the thread (checkpointer=True), or stateless (checkpointer=False). Stateless means the whole subgraph replays on resume, so rule 2 applies to every node in it.

If you are working through this stage yourself and want to talk through any of it live, I keep a slot open on Topmate.

More from me: the notes this came out of are at notes.priyanshsinghal.com, part of the full roadmap at notes.priyanshsinghal.com, and I post shorter breakdowns of what I'm learning on LinkedIn.

The LangChain You Learned in 2024 Doesn't Exist Anymore

Priyansh Singhal — Wed, 23 Sep 2026 09:23:46 +0000

LLMChain and its siblings moved to a legacy package. The new core is one function, create_agent, plus middleware.

Open a LangChain tutorial from 2024, follow it against a fresh install, and the imports fail before you write any logic. LLMChain is not in the main package anymore. Neither is initialize_agent, nor most of the chain zoo that tutorials spent two years teaching. That is not deprecation drift. It was a deliberate rebuild: in October 2025 LangChain shipped 1.0 and cut the framework down to what its team calls essential abstractions, moving everything else into a separate legacy package.

I hit this wall while working through the agentic AI stage of my own learning roadmap, with a browser full of tutorials describing a library that no longer matches what pip installs. This article is the map I wanted that week: what actually changed, what the new core looks like, and how to read older material without getting burned.

What 1.0 actually changed

LangChain 1.0 went generally available on October 22, 2025, alongside LangGraph 1.0. Two changes matter more than the version number.

First, the scope cut. The main langchain package no longer tries to be a warehouse of every chain pattern from the last three years. It focuses on agents, models, messages, and tools. Everything legacy, including LLMChain and the old pre-built chains, moved to a package literally named langchain-classic (@langchain/classic in JavaScript). Old code did not stop existing, it changed address. In current code the old import reads from langchain_classic.chains import LLMChain, and that rename is doing honest work: the framework is telling you this is the museum wing.

Second, a stability promise. 1.0 commits to no breaking changes until 2.0. That sounds boring, but for a library famous for breaking tutorials every few months it is arguably the biggest feature in the release. What you learn on the 1.x core should keep compiling for a while.

The reason for the cut is visible in what survived. Chains were LangChain's answer to a 2023 question: how do I glue prompts together? The 2026 question is different, how do I run a model in a loop with tools, safely. Agents won, and the package now says so.

The new core is one function

Here is a complete working agent on the current API, straight from the quickstart shape in the docs. One prerequisite the snippet itself won't remind you of: export the API key for whichever provider you're calling first (ANTHROPIC_API_KEY, OPENAI_API_KEY, and so on), or the agent has nothing to authenticate with.

from langchain.agents import create_agent

def get_weather(city: str) -> str:
    """Get weather for a given city."""
    return f"It's always sunny in {city}!"

agent = create_agent(
    model="anthropic:claude-sonnet-4-6",
    tools=[get_weather],
    system_prompt="You are a helpful assistant",
)

result = agent.invoke(
    {"messages": [{"role": "user", "content": "What's the weather in San Francisco?"}]}
)
print(result["messages"][-1].content_blocks)

create_agent is the whole story. You hand it a model, a list of plain Python functions as tools, and a system prompt. The model argument is a provider-prefixed string ("anthropic:claude-sonnet-4-6", "openai:gpt-5.5", or any "ollama:" model tag), which makes trying your agent against a local model a one-line experiment. At runtime it loops: the model reads the messages and either emits tool calls or a final answer. Tool calls get executed, their results are appended to the message list as tool messages, and the model runs again. A response with no tool calls ends the loop.

Two details worth knowing before you build anything real. This function replaces create_react_agent from LangGraph, which is now deprecated, so treat any tutorial teaching that name as pre-1.0. And it runs on the LangGraph runtime underneath, which matters later. Note also content_blocks on the final message: 1.0's standardized way to read reasoning traces, citations, and tool calls in one consistent shape across providers.

Middleware is the actual headline

create_agent got the announcement-post attention. The part I think matters more day to day is middleware, which the docs describe as hooks that let you customize behavior at every step of the agent loop.

Before 1.0, controlling the middle of an agent's execution meant callback handlers, subclassing, or forking a prebuilt graph. Most tutorials just skipped the problem. Now there are three obvious seams, named for exactly where they cut in:

@before_model runs before each model call. This is where you trim context or enforce a call budget. The docs' own example counts model calls in state and jumps to the end past a limit, which is a real runaway-agent guard in about ten lines.
@after_model runs after each model response, before anything acts on it. Output validation and redaction live here.
@wrap_tool_call wraps each tool execution like an HTTP middleware wraps a request. You get the request, you own calling the handler, you can log, retry, or replace the result.

There are also built-ins for the three things everyone eventually hand-rolls: human-in-the-loop approval for dangerous tools, PII redaction, and conversation summarization. The human-in-the-loop one is configured per tool, so HumanInTheLoopMiddleware(interrupt_on={"send_email": True}) pauses the loop for approval before that one tool fires while every read-only tool runs untouched. One catch before you demo it: the pause is a LangGraph interrupt underneath, so the middleware line alone does not give you a working approval flow. You also need a checkpointer attached to the agent (InMemorySaver for local work, something persistent in production) and a thread ID passed with every invoke, and resuming means calling the agent again with a Command carrying the decision. Three extra lines, but the docs only make this clear once you are deep in the human-in-the-loop page, and every demo that skips them dies at the first pause. The summarization one is configured with a token threshold and a keep-last-N-messages count, and it quietly solves the failure mode where a long-running agent drowns in its own history. That used to be a weekend of custom code. My honest read: if you evaluate LangChain 1.0 by create_agent alone it looks like a nicer constructor, and the middleware system is the actual argument for using the framework instead of writing the loop yourself.

How to read old tutorials without getting burned

A practical triage, since most LangChain material online is still pre-1.0:

Date the code, not the post. Anything showing LLMChain, initialize_agent, or create_react_agent predates October 2025 in spirit, whatever its publish date says. The concepts often still transfer. The imports will not.

Treat langchain-classic as an escape hatch, not a destination. It exists so working systems keep running, and if you maintain one, updating an import path beats a rewrite. I would not point new code at it. You would be learning the museum wing while the actual exhibit is one function with clean seams.

Expect some patterns to have moved into the loop. Structured output is the clearest example: it now happens inside the main agent loop rather than as a separate follow-up LLM call, which is one less round trip and one less place to disagree with your own schema. If a tutorial bolts an output parser onto the end of a chain, that is the old world showing.

Where LangChain ends and LangGraph begins

The framework's own framing is that you start with LangChain's high-level API and drop down to LangGraph when you need more control. In practice the boundary is shape: one model looping over tools is create_agent territory, even with heavy middleware. The moment you need multiple agents, branching workflows, or explicit state machines, you are describing a graph, and pretending otherwise just means building a graph badly out of middleware.

The two worlds compose rather than compete. An agent built with create_agent can be added as a single node inside a LangGraph StateGraph, middleware and all, so graduating to a graph does not mean rewriting the agent you already have. You wire it in next to your routing and classification nodes and it keeps behaving exactly as it did standalone.

Which suggests a learning order I wish more roadmaps made explicit. Learn the loop first, then middleware, and only then LangGraph. Every graph node you will ever write is easier to reason about once you can explain what one agent loop does, because underneath, that is what is running.

If you are working through this stage yourself and want to talk through any of it live, I keep a slot open on Topmate.

More from me: the full roadmap this article is part of is at notes.priyanshsinghal.com, and I post shorter breakdowns of what I'm learning on LinkedIn.