loop-stop-conditionslisted

# Loop Engineering: Stop Conditions and Guardrails **Source**: AI Builder Club, "Loop Engineering Guide (2026)" — practitioner synthesis citing a reported real-world incident (Uber capping agent tooling spend at $1,500/month after unattended loops consumed a year's budget in four months) and The Register's skeptical analysis of loop-autonomy claims. ## Closed loop vs. open loop **Closed loop**: success criteria defined before execution; every iteration checked against an explicit bar; predictable token consumption; converges toward a specified target. Use when the task has a genuinely checkable definition of "done." **Open loop**: loose conditions, wide exploration space; novel output is possible but so is slop; requires a *stronger* verifier precisely because there's more room to wander; higher token-burn risk if the verifier is weak. Use when genuine novelty is the point — but pair it with a strong verifier (see `loop-verifier-design`), never a weak one, since an open loop with a weak verifier is exactly the failure mode described below. **Decision principle from the source**: choose based on how much novelty the task needs, weighed against how much budget risk is acceptable if the verifier turns out to be weaker than assumed. ## The failure mode this prevents An unattended loop with a weak or absent stop condition doesn't fail loudly — it burns budget predictably, producing plausible-looking but unconverged output round after round. This is the same "doom loop" risk