Your Agent Loop Should Know When to Stop Before It Starts

In June 2026, Peter Steinberger — creator of OpenClaw, now at OpenAI — posted a reminder that spread through engineering circles: "Here's your monthly reminder that you shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." Boris Cherny, head of Claude Code at Anthropic, made the same point independently: he no longer prompts Claude directly — he writes the loops that do the prompting for him. The internet ran with it. The explainers followed — most of them converging on the same five-stage framework: Discover, Plan, Execute, Verify, Iterate. What those explainers rarely treat as upfront design decisions: the stop condition, the memory schema, and the verification boundary. All three appear somewhere in the framework — Verify is step four, memory gets a paragraph, maker-checker gets a principle. What mostly doesn't appear is the argument that these three are decisions you make before the loop runs once, not stages inside it. Treat them as checklist items and the loop runs fine in a demo. It just won't stop correctly in production. It drifts, compounds costs, and fails quietly while every infrastructure metric stays green. Reliable Agent Loops Begin With These Three Design Decisions 1. What "Done" Actually Means In my experience, most teams write the loop first and the stop condition second. By the time they get to it, "done" means "the agent said it's done" — which is not a stop condition. It's a trust exercise. A real stop condition is external to the agent. It verifies the goal independently, without asking the agent. For a coding loop: the tests pass, the linter is clean, and the diff is under a size threshold you set before the loop ran. For a content loop: the output clears a rubric the agent did not write. The condition exists before the loop starts, and the loop exits when the condition is met — not when the agent declares confidence. In my experience, the most common failure here is the fuzzy goal. "Improve the data pipeline" is a prompt. "All three integration tests green, no external API calls during a dry run, and the generated schema backwards-compatible with the previous version" is a stop condition. The difference matters because a loop without a precise exit criterion stops when it runs out of retries, when the context window fills, or when someone notices the token bill and kills it manually. None of those are the outcome you designed for. Write the exit condition first. Then write the loop. 2. What the Loop Remembers A single loop run is a conversation. What the loop knows on run 47 depends entirely on what you decided to store outside that conversation. The memory file — a markdown document, a structured log, anything that lives outside the agent's context window — is the most underspecified component in most loop explainers. It gets described as the spine of the loop and summarized as a file the agent reads at the start of each run. That's the right idea. What nobody follows with: what goes in it, how it gets updated, and what happens when it accumulates stale information. In my experience, loops that run for more than a week develop memory drift. The file records what was tried and what failed. But it doesn't record why something was marked as failed — which means a later run will re-examine closed paths because the recorded failure no longer looks like a failure in the current context. The loop retraces work. Costs compound. The loop looks busy. Memory design is not a markdown question. It's a schema question. What gets recorded, what gets pruned, and what gets treated as authoritative — those decisions determine whether your loop compounds across runs or circles through the same ground repeatedly. 3. What the Verifier Knows Going In The popular frameworks are right that the maker and checker should be separate agents. That separation is necessary. It is not sufficient. A checker that has seen the implementation's reasoning is not independent. It has already been primed toward the decision the implementer reached. It finds the work harder to reject because it understands the choices that led there. The bias is structural — the same reason you don't ask a developer to review their own pull request. The priming happens before the review starts. In practice, this means the verification agent gets the exit condition, the output, and the original goal. It does not get the implementation's reasoning trace, its tool call history, or its scratch-pad notes. If the loop's memory file includes the implementer's working notes, the verifier should run against a version that strips them. The verifier's only job is to check whether the output meets the condition you defined before the loop ran. Give it anything more and you are asking it to grade homework it helped write. Designing all three of these before the loop runs takes longer than just running the loop. The fuzzy goal, the unstructured memory file, and the non-independent verifier all look fine in a demo — the loop completes, the output looks reasonable, and the cost is manageable because it only ran once. The shortcuts show their cost on run five, run twelve, or the first time the loop runs unattended overnight. By then the exit condition is negotiable, the memory file has drifted from reality, and the verifier has been approving its own judgment for days without anyone noticing. The upfront design cost is roughly an hour. The cost of skipping it is a postmortem. Steinberger was right. Stop prompting. Start designing loops. Building the loop is the easy part of that shift. What sits in step four of the popular framework — Verify — is not a stage you run at the end. It is a decision you make at the beginning: what counts as done, what the loop is allowed to remember, and what the checker is allowed to know. Stop condition first. Memory schema second. Independent verification third. Then write the loop.