Retries and Quality Loops
Explore how to implement retry loops and quality gates in LangGraph to handle variable language model outputs. This lesson shows you how to design workflows with stateful retry counters, evaluators, and routing functions that repeatedly attempt generation until output meets quality standards or a retry limit is reached. You'll gain hands-on experience building self-correcting AI workflows with adaptive feedback for improved reliability.
Language models produce variable output. The same prompt can return a thorough, well-structured response on one call and a vague two-sentence reply on the next. For workflows where output quality matters, accepting whatever the model returns on the first attempt is a fragile strategy.
The common workaround is to make the prompt more specific: add word count requirements, structure instructions, and quality criteria directly into the prompt text. This helps, but it has limits. A prompt cannot enforce its own requirements. The model can read “write at least five sentences” and still return three.
A retry loop is a more reliable solution. Instead of hoping the prompt is strong enough, the graph evaluates each response against concrete criteria and decides whether to accept it or try again. When quality fails, the evaluator can write specific feedback into state and the next drafting attempt reads that feedback to improve. This lesson shows how to build this loop with a bounded retry counter, a quality gate node, and a loop-back edge in the graph.
The anatomy of a retry loop
Every retry loop in a LangGraph workflow has three elements. Each element has a distinct role and lives in a distinct place in the code.
The retry counter is a field in state, typically named
retry_count, that starts at zero and is incremented by the quality evaluator each time it runs. The routing function reads this value to decide whether another attempt is allowed.The quality gate is a node that reads the generated output, applies evaluation criteria, writes a boolean
quality_passedflag and any diagnostic feedback into state, and returns. It does not loop, branch, or call the model. Its only job is to measure and record.The stop condition lives in the routing function. It checks two things in order: whether quality passed, and whether the retry counter has reached the maximum. If either is true, the workflow moves forward to finalization. If neither is true, the routing function returns the name of the drafting node, creating a loop-back edge that repeats the generation and evaluation cycle.
The table below shows these three elements side by side.
Element | Lives in | Reads | Writes |
Retry counter | State schema | Routing function | Quality evaluator (increments each pass) |
Quality gate | A dedicated node |
|
|
Stop condition | Routing function |
| Nothing (returns a node name) |
Designing the stop condition
A retry loop with no upper bound is a graph that can run indefinitely. If the quality criteria are set too high, or if the model consistently produces borderline output, the loop will keep firing until something external interrupts it.
The stop condition solves this with two exit criteria: quality passes, or the retry count reaches a configured maximum. Both lead to the finalization node. The difference is that finalization knows which exit was taken, because quality_passed is in state, and it can label the output ...