Retries and Quality Loops

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.

A 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_passed flag 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.

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 accordingly.

Storing max_retries as a field in state rather than as a hardcoded constant makes the retry policy ...