LangGraph — Cycles, Human-in-the-Loop & Persistence

Cycles, bounded advanced

Picture the 3 a.m. pager alert that started this feature's whole existence. Someone shipped an agent that "retries until it succeeds." It hit a task it could never finish, so it tried again. And again. By morning it had made forty thousand model calls, run up a four-figure bill, and never once stopped to ask whether it was actually making progress. Nobody wrote a bug — they just wrote a loop with no way out. That failure mode is so common it has a name in every agent framework, and it is the reason this section comes before we let you build a single cycle.

So let's be honest about what a cycle really is. Everything up to L4 was a pipeline — a one-way street where work flows start-to-finish and the graph is guaranteed to end because it never revisits a node. A cycle breaks that guarantee on purpose: it is an edge that points backward, letting the agent return to an earlier node and try again. That backward arrow is exactly what turns a rigid workflow into something that can reason — re-run a tool with better arguments, re-plan after a failure, reflect and rewrite. It is the single most powerful thing LangGraph adds over a plain chain. It is also the single most dangerous.

The analogy that makes the danger obvious: a cycle is a while loop, and you already know the first rule of while loops — something inside the loop must eventually make the condition false, or it spins forever. In ordinary code your loop counter sits right in front of you. In an agent the "condition" is a fuzzy judgement made by a language model ("am I done yet?"), and models are cheerfully, confidently wrong. They will declare a broken task nearly-finished on pass one and still-nearly-finished on pass fifty. You cannot trust the agent to know when to stop, so you have to guarantee it does.

That is why LangGraph gives you two independent brakes, and "independent" is the whole point — the common beginner mistake is leaning on only one. The first brake is your own state counter: you track something like attempts in the graph's state and, in the routing function, return END the moment it crosses a cap. This is the brake you want to fire, because it is meaningful ("we tried five times, give up gracefully"). The second brake is LangGraph's built-in recursion limit, a raw step cap you pass to invoke that raises an error after N node executions no matter what your state says. This is the brake for the day your own counter has a bug — a belt-and-suspenders backstop, not your primary plan. You already made a cycle in L4 (tools → model). The power of a loop is also its danger: a confused agent can loop forever, burning tokens. LangGraph bounds cycles two ways — a global recursion limit and your own state counters.

END = "__end__"          # sentinel used by graph examples
class _app_t:
    invoke = 'demo'
    def invoke(self, *a, **k): return 'demo'
    def __getattr__(self, k): return 'demo'
app = _app_t()
class _Any:
    '''stands in for any undefined demo value; supports call/attr/index/
    iteration and basic arithmetic (as 0.7) so demo snippets run.'''
    def __call__(self, *a, **k): return _Any()
    def __getattr__(self, k): return _Any()
    def __getitem__(self, k): return _Any()
    def __iter__(self): return iter([])
    def __len__(self): return 0
    def __contains__(self, o): return True
    def __enter__(self, *a): return _Any()
    def __exit__(self, *a): return False
    def __float__(self): return 0.7
    def __int__(self): return 1
    def __lt__(self, o): return True
    def __gt__(self, o): return False
    def __le__(self, o): return True
    def __ge__(self, o): return False
    def __add__(self, o): return o
    def __radd__(self, o): return o
    def __bool__(self): return True
    def __repr__(self): return 'demo'
    def __str__(self): return 'demo'
inputs = _Any()

bounded_cycle.pydef route(state) -> str:
    if state["done"]:              return END
    if state["attempts"] >= 5:  return END   # hard stop in your own logic
    return "work"

# backstop: the framework raises if the graph runs too long
app.invoke(inputs, config={"recursion_limit": 25})

Lab L5.1 · Persistence with a checkpointer advanced

Here is a demo that quietly lies to you. You build a chat graph, tell it your name, ask "what's my name?" on the next line, and it answers correctly. It looks like the agent has memory. It doesn't — it only appeared to because both turns rode inside the same invoke call, sharing one in-flight state object. Close that call, come back tomorrow, ask again, and the agent has never heard of you. By default a graph has the memory of a goldfish: its state is born when invoke starts and dies the instant it returns.

The mental model that fixes this: think of a plain graph run like a browser tab in incognito mode. Everything works beautifully during the session, and the moment you close the tab it is all gone — no history, no cookies, nothing to come back to. A checkpointer is what takes it out of incognito. Attach one and LangGraph writes the entire graph state to durable storage after every single step, so the run leaves a trail you can return to, resume, and read.

The second half of the idea is the thread id, and it is worth slowing down on because it is where most persistence bugs live. A checkpointer does not store "the state" — it stores state per thread, where a thread id is just a label you choose (a user id, a ticket number, a session token). Picture a filing cabinet: the checkpointer is the cabinet, and each thread_id is a labelled folder inside it. Two calls with the same id read and write the same folder, so they share history; two calls with different ids never see each other. This is exactly how one deployed graph serves a thousand users without their conversations bleeding together — and it is why the classic production incident is one hard-coded thread_id merging every user into a single, horrifying shared memory. One folder per conversation, always.

Why this section comes before human-in-the-loop is not an accident. An interrupt has to pause a run and hold it — possibly for days — until a human responds. You cannot pause something that has nowhere to be stored. Persistence is the foundation the pause-and-resume gate is built on, so we lay it first. Attach a checkpointer and LangGraph saves the state after every step, keyed by a thread id. Now the same conversation can span many calls, survive a restart, and be inspected step by step.

persist.pyfrom langgraph.checkpoint.memory import MemorySaver
# production: from langgraph.checkpoint.sqlite import SqliteSaver, etc.

app = g.compile(checkpointer=MemorySaver())

cfg = {"configurable": {"thread_id": "user-1"}}   # names the conversation
app.invoke({"messages": [("user", "My name is Alice.")]}, cfg)
app.invoke({"messages": [("user", "What's my name?")]}, cfg)   # remembers — same thread

snapshot = app.get_state(cfg)          # the full state right now
print(snapshot.values["messages"])

Lab L5.2 · Human-in-the-loop with interrupts advanced

Would you give a brand-new intern the production database password on their first day and say "delete whatever looks stale"? Of course not — you'd have them draft the delete, show it to you, and run it only after you nodded. That is the entire idea of human-in-the-loop, and it is the difference between an agent you demo and an agent you actually let touch anything that matters. An LLM is a talented, tireless, slightly overconfident intern; the interrupt is the moment it turns around and asks "are you sure?" before it does something it cannot undo.

Notice why the naive alternatives fail, because you will be tempted by them. You could have the tool itself pop up an input() prompt and block — but then your whole server thread is frozen holding a half-finished run in RAM, and if the process restarts the run is gone. You could have the agent "just be careful" in its system prompt — but you are back to trusting a confidently-wrong model with an irreversible action. Neither is a real gate. A real gate has to stop the machine, put the work down somewhere safe, and walk away until a human comes back — maybe in thirty seconds, maybe on Monday.

That is precisely what an interrupt does, and this is the chapter's payoff. When a node calls interrupt(...), three things happen in order, and the order matters: the graph halts right there; its full state is checkpointed (this is why the previous lab had to come first — the pause needs somewhere to live); and control hands back to your application, along with a little package describing the pending action. The risky step has not run. Nothing has happened. Your app can now render "the agent wants to delete records-2019, approve?" in a UI, an email, a Slack message — whatever fits — and the run will sit patiently, costing nothing, until you feed a decision back in.

The mistake to inoculate against right now: "resume" does not mean "start over." When you approve, LangGraph reloads the checkpointed state and continues from the exact point it paused — the model doesn't re-reason, the earlier tool results aren't recomputed, and the human's answer flows in as the return value of that interrupt(...) call. Approve and the irreversible step finally runs; reject and it never does. You show the pending action to a human; on approval you resume and the graph continues exactly where it stopped.

hitl.pyfrom langgraph.types import interrupt, Command

def risky_action(state):
    # pause and surface the proposed action to a human
    decision = interrupt({"action": "delete", "target": state["target"]})
    if decision != "approve":
        return {"result": "cancelled by human"}
    return {"result": _do_delete(state["target"])}

# --- running it ---
cfg = {"configurable": {"thread_id": "job-42"}}
app.invoke(inputs, cfg)                 # runs until the interrupt, then STOPS

state = app.get_state(cfg)              # inspect what it wants to do
print(state.next, state.values)         # show the human the pending action

# human approves → resume with their decision
app.invoke(Command(resume="approve"), cfg)

Lab L5.3 · Inspecting & editing state expert

Every debugger you have ever loved gives you one superpower: the ability to stop time and look inside. A normal agent denies you even that. When something goes wrong on pass eleven of a long, expensive run, your only tools are print statements and the willingness to run the whole thing again from scratch and pray it fails the same way. Anyone who has debugged a flaky agent knows that particular flavour of despair — the bug that costs ten dollars and four minutes to reproduce, if it reproduces at all.

The checkpointer quietly abolishes that problem, and it is the reason this lab feels like magic. Because LangGraph saved a snapshot after every step, the run is no longer a black box that either finishes or explodes — it is a flip-book you can page through frame by frame. Each checkpoint records what the state held and which node was about to run next, so you can watch exactly how the agent's beliefs evolved: where it first got the wrong idea, which tool result poisoned the plan, the precise step the reasoning bent. This is the "time travel" of the name — not a metaphor, a literal history you iterate over.

Then it goes one step further, from read to write. You can not only inspect an old checkpoint, you can edit it and resume from the corrected version. Think of a film director calling "cut," fixing one prop, and reshooting from that mark rather than the top of the scene: the agent picked the wrong record, so you patch target to the right one and let it continue — no re-running the ten good steps that came before. That is enormously cheaper than a full restart for any agent that is slow, costly, or non-deterministic.

One honest caveat, because this power invites misuse: editing live state is a debugging and correction tool, not a substitute for fixing your graph. Hand-patching state in production to paper over a bug is how you get an agent that only works when you are watching it. Use time-travel to understand the failure, then fix the node or the prompt that caused it. Because every step is checkpointed, you can walk the history, and even edit state before resuming — invaluable for debugging and for correcting an agent that went slightly wrong without restarting it.

timetravel.py# see every checkpoint (newest first)
for snap in app.get_state_history(cfg):
    print(snap.next, len(snap.values["messages"]))

# correct the state, then resume from the fixed version
app.update_state(cfg, {"target": "the-right-record"})
app.invoke(Command(resume="approve"), cfg)

Putting it together: an approval-gated agent expert

Here is the quiet truth about production agents: none of the three ideas in this chapter is impressive on its own. A loop is just a loop. A save file is just a save file. A pause is just a pause. What makes a system you would actually let touch a real incident is the way they interlock — each one covering exactly the weakness the other two leave open. Miss any single one and you get a recognisable failure: a cycle without a checkpointer forgets everything when it crashes mid-incident; a checkpointer without an interrupt happily persists the state of an agent that already did the damage; an interrupt without a cycle can gate one action but can't keep working afterward.

So watch how they compose into a single shape. The cycle is the engine — it lets the agent diagnose, act, and re-diagnose until the problem is actually resolved instead of stopping after one hopeful pass, and its two brakes keep it from running away. The checkpointer is the memory and the safety net underneath that engine — every incident becomes its own durable thread, so a restart resumes instead of restarting, and every step is on the record. The interrupt is the hand-brake wired to the dangerous levers — read-only diagnosis flows freely, but nothing irreversible (terraform apply, kubectl delete, a refund, a mass email) happens until a human signs off. Cycle to keep going, checkpointer to never lose the thread, interrupt to never cross the line without permission.

That is not a toy pattern — it is the literal skeleton of this course's capstone AI DevOps Engineer, and of most serious agents in the wild. If you internalise one thing from L5, make it this: the primitives are simple, but the discipline of combining all three is what separates a demo from a system on call. Cycles + persistence + interrupts compose into the shape of a real production agent — and of the capstone.

Common pitfalls expert

Exercises expert

def work(state):
    state["progress"] += 40
    state["attempts"] += 1
    return state

def run(max_attempts=5):
    state = {"progress": 0, "attempts": 0}
    while state["progress"] < 100 and state["attempts"] < max_attempts:
        state = work(state)
    reason = "done" if state["progress"] >= 100 else "hit attempt cap"
    return state, reason

print(run())   # ({'progress': 120, 'attempts': 3}, 'done')

class RecursionLimit(Exception):
    pass

def run_graph(step_fn, state, recursion_limit=25):
    steps = 0
    while not state.get("done"):
        steps += 1
        if steps > recursion_limit:
            raise RecursionLimit(f"exceeded {recursion_limit} steps")
        state = step_fn(state)
    return state, steps

# a buggy node that never sets done -> the backstop fires
buggy = lambda s: {**s, "n": s.get("n", 0) + 1}
try:
    run_graph(buggy, {}, recursion_limit=10)
except RecursionLimit as e:
    print("backstop:", e)

class MemorySaver:
    def __init__(self):
        self.store = {}
    def get(self, thread_id):
        return self.store.get(thread_id, {"messages": [], "step": 0})
    def put(self, thread_id, state):
        self.store[thread_id] = state

saver = MemorySaver()
def step(thread_id, user_msg):
    state = saver.get(thread_id)                 # resume where we left off
    state["messages"].append(user_msg)
    state["step"] += 1
    saver.put(thread_id, state)                  # persist
    return state

step("chat-1", "hello")
s = step("chat-1", "again")
print(s["step"], "steps on thread chat-1")       # 2 -- state survived
print(saver.get("chat-2")["step"])                # 0 -- separate thread

def run_until_interrupt(state):
    # progresses until it wants to run a dangerous action
    state["plan"] = "delete_records"
    state["status"] = "interrupted"          # pause here for approval
    return state

def resume(state, approved):
    if state["status"] != "interrupted":
        return state
    if approved:
        state["result"] = f"executed {state['plan']}"
    else:
        state["result"] = f"skipped {state['plan']} (denied)"
    state["status"] = "done"
    return state

s = run_until_interrupt({})
print("paused with pending:", s["plan"])
print(resume(dict(s), approved=False)["result"])   # skipped ...
print(resume(dict(s), approved=True)["result"])     # executed ...

class Graph:
    def __init__(self):
        self.history = []
    def step(self, state):
        state = {**state, "n": state.get("n", 0) + 1}
        self.history.append(dict(state))     # snapshot each step
        return state
    def rewind_to(self, i):
        return dict(self.history[i])         # restore an earlier checkpoint

g = Graph()
s = {}
for _ in range(3):
    s = g.step(s)
print("now:", s)                             # {'n': 3}
patched = g.rewind_to(0)                      # go back to after step 1
patched["n"] = 99                             # edit state
s = g.step(patched)                           # resume from the edit
print("after time-travel:", s)               # {'n': 100}

from typing import Annotated, TypedDict
from langgraph.graph import StateGraph, START, END
from langgraph.graph.message import add_messages
from langgraph.checkpoint.memory import MemorySaver

class State(TypedDict):
    messages: Annotated[list, add_messages]

def model(state): return {"messages": []}     # calls Claude + tools in reality
def tools(state): return {"messages": []}

builder = StateGraph(State)
builder.add_node("model", model)
builder.add_node("tools", tools)
builder.add_edge(START, "model")
builder.add_edge("model", "tools")
builder.add_edge("tools", END)

# checkpointer + interrupt = pause before running tools for human approval
graph = builder.compile(checkpointer=MemorySaver(), interrupt_before=["tools"])

cfg = {"configurable": {"thread_id": "run-1"}}
graph.invoke({"messages": [{"role": "user", "content": "delete old records"}]}, cfg)
# ...inspect graph.get_state(cfg), get human approval, then:
graph.invoke(None, cfg)   # resume from the interrupt on the same thread

Knowledge check check yourself