The Five Ways a Loop Fails to Stop

Mostafa Dhouib·September 5, 2026·7 min read

The Five Ways a Loop Fails to Stop

The short answer. A loop terminates when there is a value computed from its state that strictly decreases every pass and is bounded below. Negate each part of that sentence and you get an exhaustive list of failure modes: no measure exists, the measure is not a function of state, it does not always decrease, it decreases but measures the wrong thing, or it decreases but something resets it. Five diagnoses, five different fixes, and only one of them looks like a hang. The others look like success.

"It will not stop" is a symptom, not a diagnosis, and teams burn weeks on it because they treat the symptom as the problem. There is a better move available, and it is fifty-nine years old.

Where the list comes from

Floyd's 1967 result gives the conditions under which a loop provably terminates. You need a ranking function: a value computed from the program's state, which strictly decreases on every pass through the loop, and which is bounded below so it cannot decrease forever.

That is three conditions in one sentence, and they are conjunctive: all of them must hold. So the ways termination can fail are the ways to break them, and because the conditions are exhaustive, so is the list of failures. This is not a checklist somebody assembled from experience. It is derived, which is why nothing is missing from it.

Two of the five come from breaking one condition in two different ways, which the walkthrough makes clear.

One: there is no measure at all

Symptom. The loop's continue condition is not connected to any quantity that changes monotonically. Nothing in the design decreases.

Example. A polling loop that runs while a flag is set, where the flag is set by an external system that has stopped reporting. There is no value here that is heading anywhere.

Fix. Introduce one. This is the easy case, and the useful thing about the taxonomy is that it tells you immediately that the work is design work rather than debugging.

Two: the measure is not a function of state

Symptom. Ask twice about the same state and you can get two different answers.

Example. This is the one that catches AI systems, and it catches them by construction. The stopping decision is "does the model think it is done?" That is a sample from a distribution, not a function of state. Run the identical conversation twice and it can continue once and stop once.

Floyd's condition requires a value computed from the state. A sampled opinion is not that, and no amount of prompt engineering makes it that, because the problem is the category rather than the quality.

Fix. Compute the measure in code. The model may propose actions; it must not be the thing that decides whether the work is done.

Three: the measure decreases, but not on every pass

Symptom. Progress happens sometimes. Some paths through the loop are no-ops, and some move backwards.

Example. A repair loop that fixes a test on most passes but occasionally makes a change that breaks two others. The measure exists and is real; it just does not strictly decrease.

Fix. Either make every path decrease it, or add a secondary bound on consecutive non-decreasing passes. The second is a legitimate engineering compromise as long as you record which one you chose, because the two have different failure characteristics.

Four: the measure decreases, but measures the wrong thing

Symptom. The loop stops. Everyone is satisfied. It stopped for the wrong reason.

Example. The iteration counter. It is a genuine ranking function: it decreases every pass and bottoms out at zero, so the loop provably terminates. Floyd is satisfied. And it measures spend, not progress. Hitting zero tells you the budget ran out, which is a completely different fact from the work being finished.

This is the one your agent has, and it is the dangerous one precisely because it does not look like a failure. The loop terminated. There was no hang, no timeout, no alert. What came back was a result, and downstream nothing can tell it apart from a real one, so it gets written to a database or handed to a customer or used as the foundation for step six.

Fix. Add a measure of remaining work alongside the counter, keep the counter, and distinguish the two exits. A run that stopped because the work is done and a run that stopped because it ran out of budget must not return the same type.

Five: the measure decreases, but something resets it

Symptom. Each component provably terminates and the system does not.

Example. A planner bounded at twenty steps calls an executor bounded at ten calls; the executor reports failure and the planner replans, which resets the step count. Both proofs are valid. The composition has no ranking function at all, because each measure is restored by the other's activity.

Fix. A measure over the combined state that no participant can reset, plus one metric at task level: time since remaining work last decreased. This is the failure mode that per-component monitoring is structurally unable to see.

Using the list

The value of an exhaustive taxonomy is that it converts an open-ended investigation into five questions with yes or no answers, in order.

Is there a quantity that is supposed to be heading somewhere? No means one.

Is it computed from state, or sampled? Sampled means two.

Does it decrease on every path, or only some? Some means three.

Does it measure work remaining, or effort spent? Effort means four.

Can any other component reset it? Yes means five.

Most production AI systems answer: yes there is a quantity, it is sampled, it decreases on some paths, it measures effort, and the composition resets it. That is four of the five at once, which is why the symptom feels so intractable when you approach it as a single problem.

It is also why fixing one of them often changes nothing visible. If you replace a sampled stop condition with a computed one but the computed one is still a counter, you have fixed two and still have four. The taxonomy tells you that in advance.

FAQ

What makes a loop provably terminate? A ranking function: a value computed from the loop's state that strictly decreases on every pass and is bounded below so it cannot decrease forever. Floyd formalised this in 1967, and it is still the standard framing.

Why are there exactly five failure modes? Because the conditions for termination are conjunctive and exhaustive, so the ways to fail are the ways to break them. Two of the five come from breaking the same condition in different ways: the measure can be wrong because it tracks the wrong quantity, or because something resets it.

Which one does my AI agent have? Usually several at once. The stop condition is a sampled model opinion rather than a function of state, and the backstop is a counter measuring spend rather than progress. If the agent calls other agents, the composition failure is there too.

Why is the fourth mode the dangerous one? Because it does not look like a failure. The loop terminates cleanly, no alert fires, and it returns something the caller cannot distinguish from a completed answer. A hang is loud. A budget-exhausted run wearing a result's clothes is silent, and it propagates.

Can I fix these one at a time? Yes, but expect no visible change until the last one. Replacing a sampled stop condition with a computed counter fixes one mode and leaves you with another. The taxonomy is useful precisely because it tells you how many you have before you start.