Guide 02 · 7 min
How to write a stopping condition
A stopping condition is a finish line someone else can check. This shows how to turn a vague goal into one, with the failure modes that make agents stop early or never.
A stopping condition is the sentence that tells an agent it is finished. It is the single highest-leverage thing you write, because everything else in a loop is a means of reaching it.
The rule: someone who was not involved should be able to read your stopping condition, look at the output, and say yes or no without asking you what you meant.
The two failure modes
Almost every bad stopping condition fails in one of two directions.
Too loose, and the agent stops early. “Improve the page.” The agent makes a change, decides the page is improved, and stops. It is not lying. It has no way to know what you would have accepted, so it uses the only standard available: whether its own output looks finished. That standard is always met immediately.
Too tight, and the agent never stops. “Every page ranks in the top three.” That is an outcome, not a state the agent controls. It will keep working, or it will stop and report failure on something that was never within its power. A stopping condition has to be reachable by the actions the loop is allowed to take.
The target is between: a state the loop can produce, and a person can check.
Turn a goal into a condition
Take the goal. Ask three questions in order.
1. What would have changed? Not “the page is better” but which artifact is different and how. Three sections exist that did not before.
2. How would a stranger verify it? By counting, comparing, or reading a specific thing. Count the sections. Diff against the original.
3. What must still be true? The things that must not have broken. No existing number changed. No claim without a source.
Put the three together and you have it:
Three sections exist that did not before, no existing number changed, no claim appears without a source, and the verifier printed PASS.
Four shapes that work
Most usable stopping conditions are one of these.
A count. “All 13 pages have a before and after score recorded.” You can count them. This is the most reliable shape and the one to reach for first.
A comparison. “No page has a verification date older than 21 days.” A script checks the whole set against a threshold. Good for maintenance loops that run repeatedly.
An exhaustion. “Every question in the file belongs to exactly one cluster, and every cluster names a page or a gap.” The loop finishes when the input is used up. Good when the work is bounded by a list rather than by a quality bar.
A verdict. “The verifier printed PASS.” Only as good as the verifier, so this one is never used alone. It belongs at the end of a condition that already names the state.
Four that do not
“Until it looks good.” Taste, not state. The agent’s taste is not yours and it is always satisfied.
“Until traffic increases.” Outside the loop’s control and on a timescale it does not run on. Outcomes belong in a receipt, not a stopping condition.
“Until no more improvements are possible.” Unreachable. There is always another edit, so the agent burns budget until something else stops it.
“When the task is complete.” Circular. It defines done as done.
The test
Before you run anything, write down one output that should fail your stopping condition. If you cannot describe a failing output, the condition does not discriminate and the loop will always pass.
Then write down one output that should pass. If both look the same to you, the condition is too loose.
This takes two minutes and it is the difference between a loop that works and a loop that reports success forever.
When you cannot write one
Sometimes you will try and fail. The job genuinely has no checkable finish line.
That is useful information, not a dead end. It means one of two things:
The request is still too broad. “Make our content better” splits into a dozen jobs, each of which has a finish line. Split it and write conditions for the pieces.
The job needs judgment that cannot be delegated. Deciding your positioning, choosing which market to enter, approving a claim about a customer. These are not loop-shaped and should not be forced into the format. The honest answer is that a human does this one, and the loop handles what comes after the decision.
Knowing which of those two you are facing is most of the skill.
Next
- How to write a verifier that fails, because a stopping condition ending in “the verifier passed” is only as good as the verifier.
- How to write a loop, if you landed here first.
- The definition, if you want the short version.