Module 5 of 11 · Expert · 10 min read

Loop control: stopping conditions, budgets and drift

Design loops that finish: success criteria, caps, budgets, progress checks, oscillation detection and escalation.

Key takeaways

1Combine a success condition with hard caps on iterations, time and cost.
2Detect lack of progress and oscillation, not just failure.
3Fight drift by restating the original goal and keeping state outside the conversation.
4Decide in advance what happens when a loop gives up: escalate, fall back or report.

01Kinds of stopping condition

Use several together. The success condition is how you hope the loop ends; the others are how you guarantee it ends.

Success: the criteria are met (tests pass, rubric passes, validator accepts).
Iteration cap: a maximum number of rounds, always present.
Budget: maximum tokens, money or wall-clock time.
No progress: the score has not improved for N rounds.
Repetition: the same error, action or output has appeared several times.
Human checkpoint: pause for approval at set points or when confidence is low.

02A loop controller you can copy

Whether you build in code or in a visual workflow tool, the logic looks like this.

Example

state = {goal, best: None, history: [], iteration: 0} while iteration < MAX_ITERATIONS and spent < BUDGET: attempt = step(goal, best, history) score, feedback = check(attempt) if score meets threshold: return attempt # success if attempt repeats an earlier one or the same feedback appears 3 times: break # stuck if best is None or score > best.score: best = attempt # keep the best so far elif no improvement for 2 rounds: break # stalled history.append(short summary of attempt and feedback) iteration += 1 return escalate(best, history) # never fail silently

03Detecting oscillation

A common failure is the ping-pong loop: revision A fixes issue 1 and breaks issue 2, revision B fixes 2 and re-breaks 1, forever. Keep a history of attempts or their key decisions, compare new attempts with old ones, and break when you see a repeat. Including a short history in the prompt ('you already tried X and it caused Y') helps the model avoid repeating itself.

04Fighting drift

Over many iterations, the working goal can drift from the original: a 'tighten this paragraph' loop ends up rewriting the argument; an agent asked to fix a bug ends up refactoring a module. Drift happens because each step sees mostly the latest output, not the original intent.

Restate the original goal and constraints in every iteration's prompt.
Keep the spec and progress in state or a file, not only in the conversation.
Compare each attempt against the original, not just the previous attempt.
Limit scope explicitly: 'change only X'.

05Budgets in practice

Estimate the cost of one iteration (tokens times price, plus tool costs) and multiply by your cap, so you know the worst case before you start. For agents that run unattended, enforce budgets in the platform or your code, not just in the prompt; a model can't reliably keep track of its own spend.

Tip

When a loop gives up, return the best attempt so far along with what was tried. A partial result with an honest report is far more useful than a silent failure.

06When the loop gives up

Decide the fallback before you build: hand the best attempt and history to a person, switch to a stronger model, try a different strategy, or return a clear error. Log every give-up; the inputs that defeat your loop are the most valuable additions to your test set.

Finished reading?

Mark it complete to track your progress, then test yourself with the Loops, Graphs & Agents quiz.

Next: Tree of Thoughts: branching and searching →