LangGraph: multi-step agents that can stop and recover

A single model call is a reply. An agent is a loop that can take the next step, fail, and try a different step. LangGraph is one way to draw that loop so you can see it.

This post teaches the graph: nodes, edges, state, and what “recover from a bad answer” actually means.

Why a graph, not one prompt

One prompt can draft an email. It cannot reliably: read a brief, draft, check the brief again, and rewrite the sentence that drifted.

If you hide those steps inside one giant instruction, you cannot tell which step broke. A graph makes each step a node. You can print the state between nodes. You can rerun one node. You can stop.

If you cannot draw the steps, you do not have an agent. You have a long prompt.

The pieces

State. A small object you pass along: the user job, the last tool result, the draft, a fail count. If it is not in state, the next node will invent it.

Nodes. One job each. “Search the notes.” “Draft.” “Check the draft against the notes.” “Repair.” A node that “does the whole agent” is a one-prompt project wearing a new name.

Edges. What happens after a node. Sometimes the next node is always the same. Sometimes you branch: if the check failed and the fail count is under three, go to repair; else stop and tell the user.

A stop. Graphs that cannot stop will spend your money and still sound busy. Write the stop condition first.

The useful picture is a loop with an exit, not a straight line of hopeful steps.

A first graph you can finish

Job: answer from a notes folder, then refuse to publish a sentence the notes do not support.

Nodes:

1. Understand — turn the user question into a search query. No prose.
2. Retrieve — get two or three chunks. If none, stop: “I do not have that in the notes.”
3. Draft — write a short answer from those chunks only.
4. Check — does every sentence map to a chunk? Yes or no, plus the failing sentence.
5. Repair — rewrite only the failing sentence, or delete it.
6. Stop — return the answer and the chunk titles.

You already know RAG from the retrieve node. The graph is what you add: check, repair, stop.

Done looks like this:

If repair runs forever, your edge is wrong. Cap it. Two repairs is plenty.

Recover from a bad answer

“Memory and failure” is not a slogan. It is two fields in state.

Failure. The check node writes ok: false and the sentence that failed. Repair reads that, not the whole chat. If you only say “try again”, the model often repeats the same sentence.

Memory. State keeps the chunks and the fail count. It does not keep a novel. A transcript dump is not memory. Named fields are memory.

When the same check fails twice, stop. Show the user the last draft and the failing sentence. A person is cheaper than a third loop that you cannot explain.

Repair one sentence. Do not regenerate the whole answer and hope the bug moved.

Common mistakes

One node called agent. You cannot test it. Split it.

State that is a chat log. The next node will pick a random earlier line and treat it as fact.

No empty-retrieve stop. Then the draft node writes from general knowledge and you call it an agent.

Unlimited retries. That is a bill, not resilience.

A graph you never printed. If you cannot log node=check ok=false, you will debug by rereading the final paragraph.

Practise

1. Draw six boxes on paper. Name them. Draw the arrows, including the stop.
2. Implement retrieve and the empty stop only. Prove that case.
3. Add draft and check. Prove the thin-notes case.
4. Add repair with a cap of two.
5. Print state after every node once. Then turn the print off.

You can build this in LangGraph, or in plain functions and an if-statement. The library is optional. The graph is not.

Checklist

• You can draw your agent without opening a laptop.
• Each node has one job.
• Empty retrieve stops before draft.
• Repair has a cap.
• State is fields, not a dumped chat.
• You have a case where check fails on purpose.

The next step is a graph with an exit, not a smarter model.