Claude Code has formally defined what it means by a “loop,” framing it as an agent repeatedly carrying out work until a stopping condition is hit. In its official blog, the team split that framework into four patterns: turn-based loops, goal loops, time loops, and proactive loops. The central point is simple: the hard part is not getting AI to keep running, but getting it to stop at the right moment.
The subject has become a live debate across the AI tooling community. The article points to Peter Steinberger, described as the creator of OpenClaw and now focused on next-generation personal agents at OpenAI; Boris Cherny, the creator of Claude Code; and Google engineer Addy Osmani, who named the trend “loop engineering.” All three are cited as examples of a broader move away from hand-crafting every prompt and toward building systems that feed prompts into agents in a structured way.
Cherny said he now rarely writes prompts by hand. Instead, an agent writes prompts for Claude on his behalf, and he interacts mainly with a new Claude instance that “coordinates everything.” He also said that, ten years from now, loops and related capabilities will likely rank among the work he is most proud of.
Steinberger made the point even more bluntly. Rather than writing prompts for coding agents, he said, developers should be designing loops that deliver prompts to those agents. He also demonstrated his own setup on X, showing Codex waking up every five minutes to maintain a code repository, assign tasks, and autonomously complete some of the work.
Claude Code’s latest post turns that conversation into a clearer engineering model. By its definition, a loop is an agent doing work over and over until a stop rule is triggered. The four loop types are, in effect, four different ways of deciding when enough is enough.
Four loop types, four ways to stop
The Claude Code team organizes loops around several questions: what triggers them, what stops them, what primitives they use, and what kinds of tasks they fit.
Turn-based loops
The first pattern is the turn-based loop. Here, the human stays in control throughout. One prompt starts one round of work, the output is reviewed, and the next prompt is sent only after that review. This model fits short, discrete tasks that do not belong in a larger workflow or schedule.
To cut down on repeated manual review, the article says users can write the usual acceptance checks into a SKILL.md file and let the agent verify its own work. The more measurable those checks are, the easier it becomes for the agent to decide whether it completed the task correctly.
Goal loops
The second pattern is the goal loop, invoked with /goal. In this setup, the target is fixed in advance. The article gives an example: raise a homepage Lighthouse score above 90 and stop after five attempts if it still is not there. Each time Claude thinks it is done, an evaluator model checks the output against the target. If the result falls short, the task is sent back for another round. The loop ends only when the goal is met or the maximum number of rounds has been used.
The post argues that measurable criteria such as passed tests or score thresholds work especially well because Claude does not need to guess whether the result is “good enough.” The evaluator makes that decision instead, which reduces the chance of stopping too early.
Time loops
The third pattern is the time loop, using /loop and /schedule. It is triggered by intervals, much like an alarm or a scheduled task. This is useful when the job itself stays the same while the input changes, such as summarizing Slack messages each morning or repeatedly checking whether a pull request has received review comments or whether CI has failed.
With /loop, the same prompt can be rerun on a set cadence. With /schedule, that loop can be moved to the cloud and kept alive after the local machine is shut down. The article compares the logic directly to cron jobs familiar to software engineers.
Proactive loops
The fourth pattern is the proactive loop. These are triggered by events or time and can run without supervision. Combined with auto mode and dynamic workflows, they can connect long chains of work. The example in the article is a system that scans a feedback channel every hour, picks up a bug report, triages it, fixes it, and sends a reply without pausing to ask for permission at each step.
Each individual task exits once its goal is reached, but the broader routine keeps running until the user turns it off manually. The article says this pattern fits work that keeps arriving in well-defined forms, including bug intake, issue categorization, and dependency upgrades.
Seen this way, the four loop types are really four answers to the same question: who or what decides when to stop? A person can decide. An evaluator can decide. Time can decide. An event can decide.
The Agent SDK loop is structurally simple
The official Claude Code Agent SDK documentation gives a lower-level description of the mechanism. Claude evaluates a prompt, calls tools to take action, receives the results, and evaluates again. That cycle repeats until a round arrives in which no tools are called. Only then does the system produce a final answer.
By that account, an autonomous agent is fundamentally a loop of assessment, tool use, and reassessment.
The shift is not the loop itself, but the stop rule and verification
The article is careful not to present loop design as a brand-new invention. Scheduled jobs, orchestration, and feedback loops all existed long before this discussion. What Claude has done is package these practices under a single name and arrange them into a clearer taxonomy.
What has changed, the article argues, is the emphasis on stopping conditions.
Among Claude Code’s practical tips, one item is singled out as the most valuable: verification. The recommendation is to give Claude a way to check its own output.
The article uses a straightforward analogy. If an engineer is asked to build a webpage without a browser, they cannot immediately see the result of each change. With a browser, they can inspect each version as they go and keep refining it. The power of a loop comes from that same ability to close the feedback loop on its own.
In that setup, prompts do not disappear. They are reduced to one component inside a broader loop. The real center of gravity becomes stopping-condition design, verifier design, token budget control, and multi-round execution strategy.
Without gating, loops can be costly and risky
The article also warns against a common misunderstanding: loops do not mean AI can simply be left alone to work all day without constraints. The first issue is cost. A loop with no hard ceiling can consume tokens aggressively.
It notes that, according to reports, Steinberger has described himself as “the man with infinite tokens” because free tokens are part of his OpenAI employment benefits. Most users do not have that luxury.
A second problem is less obvious. Agents can enter a dead loop that looks productive on the surface but never reaches a new successful state. They may keep changing the same files without producing an additional passing test. In some cases, they can even build a wrong solution into something that looks more complete over time.
The engineering community’s position, as summarized in the article, is direct: loops are powerful, but they are dangerous without gating conditions.
The article cites a Reddit engineering discussion that reduces those gates to three essentials:
- a done condition that a machine can actually judge, such as all tests passing or a specific item in the spec being closed;
- hard limits, including a maximum number of rounds and a maximum spend, to prevent runaway costs and infinite execution;
- lack-of-progress detection, so the system stops if it keeps touching the same files without generating any new passing tests.
Claude’s guidance also includes a broader set of cost controls:
- do not force small tasks into multi-agent setups;
- use smaller, cheaper, faster models where they are sufficient instead of defaulting to the strongest model every time;
- test on a small slice before running at scale;
- hand deterministic work to scripts, because executing scripts is often cheaper than making a model reason through every step;
- do not schedule routine tasks more often than they need to run.
That is why the article describes loops less as “letting AI run loose” and more as a discipline for keeping AI under control. At this stage, it says, loops fit structured work with clear boundaries better than open-ended tasks that depend on unconstrained creativity.
Programming focus is moving from content to behavior design
The article’s broader conclusion is that the center of programming work is shifting. The emphasis is moving away from designing the content of a single prompt and toward designing a behavior system: how work starts, how it is checked, and how it ends.
Claude Code offers a simple starting point for people who want to design loops. Look at the work you repeat every day, identify one bottleneck, and ask three questions: can the verification step be written down, is the goal clear enough, and does the work arrive on a regular rhythm? If the answer to any one of those questions is yes, the article says, that may already be the first task worth handing off to a loop.
Its final point is that AI programming used to reward prompt technique most of all. Now it increasingly rewards the ability to build a system that can verify itself and knows when to stop. Prompt writing is not disappearing overnight, but the spotlight is moving toward loop design.
The article cites Claude’s official blog post “Getting Started with Loops,” the Claude Code Agent SDK documentation, “Claude Code power user tips,” and a related Reddit engineering discussion. It was originally published by the WeChat account Xinzhiyuan and written by Yuanyu.