The loop, officially defined
"Design loops instead of prompting" is everywhere, but pin anyone down and you'll get a different answer. The Claude Code team's blog collapses the word into one definition, agents repeating cycles of work until a stop condition is met, then splits it into four types, from light to heavy. Each rung up hands the loop a little more control.
First, collapse the word into one sentence
There's a lot of talk right now about "designing loops" instead of prompting your coding agent, and if you try to pin down what a loop actually is, you'll come across multiple different answers. What this blog does is plain: it collapses the overloaded word into a definition you can act on, then splits it into a few types.
The team's definition is one line: agents repeating cycles of work until a stop condition is met. Around it, they categorize loops along four dimensions.
triggered
stopped
is used
best fits
Sorted by those four axes, you get four loop types, from light to heavy: Turn-based, Goal-based, Time-based, Proactive. The blog sets the tone up front: not all tasks require complex loops; start with the simplest solution and use these patterns selectively. Each rung up hands the loop a little more control: from handing off "the check," to "the stop condition," "the trigger," and finally "the prompt." Here's each in turn.
Every prompt you send already starts a loop
Everyone runs this layer daily. Every prompt you send starts a manual loop with you directing each turn: Claude gathers context, takes action, checks its work, repeats if needed, and responds. The team calls this most basic cycle the agentic loop.
Ask Claude to create a like button: it reads your code, makes the edit, runs the tests, and hands back something it believes works. You then manually check the work, and write the next prompt.
The payoff at this layer is handing the "you check it" step to Claude itself. Not by writing longer prompts, but by encoding your manual steps as a SKILL.md so Claude can check more of its own work, end-to-end. The skill should include tools or connectors that let Claude see, measure or interact with the result, and the more quantitative the checks are, the easier it is for Claude to self-verify. The blog's full example is a skill named verify-frontend-change: never report a UI change as complete based on a successful edit alone, verify it the way a human reviewer would.
---
name: verify-frontend-change
description: Verify any UI change end-to-end before declaring it done.
---
# Verifying frontend changes
Never report a UI change as complete based on a successful edit
alone. Verify it the way a human reviewer would:
1. Start the dev server and open the edited page in the browser.
2. Interact with the change directly. For a new control (button,
input, toggle): click it, confirm the expected state change,
and screenshot before/after.
3. Check the browser console: zero new errors or warnings.
4. Use the Chrome Devtools MCP, run a performance trace and audit
Core Web Vitals.
If any step fails, fix the issue and rerun from step 1 —
do not hand back partially verified work.
The four steps: start the dev server and open the page; interact directly, clicking a new control and screenshotting before/after; check the console for zero new errors; run a performance trace and audit Core Web Vitals with the Chrome Devtools MCP. If any step fails, fix it and rerun from step 1 — never hand back partially verified work.
Use /goal to define what "done" looks like
Sometimes a single turn is not enough, especially for more complex tasks; agents do better when they can iterate. You extend how long Claude keeps iterating by defining what done looks like with /goal.
When you define the success criteria, Claude doesn't have to decide what's "good enough" and end the loop early. Each time Claude tries to stop, an evaluator model checks your condition and sends it back to work until the goal is met or a number of turns you define is reached. That's why deterministic criteria, like number of tests passed or clearing a score threshold, are so effective.
/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.
A quantifiable completion bar (90 or above) and a hard turn cap (5 tries) in one line.
Re-run on an interval, or watch an external system
Some agentic work is recurring: the task stays the same and only the inputs change, like summarizing Slack messages every morning. Other work depends on external systems, and a simple way to interface with one is to check it on an interval and react to what changed, like a PR that may receive code reviews or fail CI.
The primitive here is /loop, which re-runs a prompt on an interval.
/loop 5m check my PR, address review comments, and fix failing CI
/loop runs on your computer, so if you turn it off, it stops. You can move the loop to the cloud by creating a routine with /schedule (marked research preview). The former is a temporary loop on your machine; the latter is a scheduled task that lives in the cloud and doesn't depend on your machine being on.
No human present, the first three composed into a long run
The heaviest layer is the loop that runs with no human in real time. The primitives above, along with other Claude Code features like auto mode and dynamic workflows (research preview), can be composed into a loop for long-running work.
The blog's example handles incoming feedback by composing four things:
/schedule to run on a schedule (research preview)
Run a routine that checks for new reports.
/goal to define what done looks like
And skills to document how to verify it.
Dynamic workflows to orchestrate
Agents that triage each report, fix it, and review the fix.
Auto mode, so it never stops to ask
The routine runs without stopping for permission.
Put together, a prompt could look like this:
/schedule every hour: check #project-feedback for bug
reports. /goal: don't stop until every report found
this run is triaged, actioned, and responded to. When
fixing a bug, use a workflow to explore three solutions
in parallel worktrees and have a judge adversarially
review them.
You can see the four layers stacking here: /schedule supplies the event-or-schedule trigger, /goal supplies the hard completion bar, and the "three solutions in parallel + a judge adversarially reviewing them" is exactly the orchestration dynamic workflows does.
Which shapes that "workflow" slot can take internally (fan-out, tournament, adversarial verification, six patterns in all) is the subject of a separate piece. In other words, dynamic workflows is a component of the Proactive loop, not the loop itself; this piece is the shell wrapped around it. For how one turn inside the loop splits work across agents, read "How to use Dynamic Workflows: six patterns and three failure modes."
Whatever the layer, quality and cost share one discipline
The quality of a loop's output depends on the system around it; to keep token usage in check, loops need clear boundaries. Both cut across all four layers, and the blog gives a checklist for each.
Maintaining code quality
| Do this | Why |
|---|---|
| Keep the codebase itself clean | Claude follows the patterns and conventions already in your codebase |
| Give Claude a way to verify its own work | Encode what good looks like, for you and your team, with skills |
| Make docs easy to reach | Framework and library docs hold the up-to-date best practices |
| Use a second agent for code reviews | A reviewer with fresh context is less biased, not swayed by the main agent's reasoning; use the built-in /code-review or Code Review for GitHub |
One principle runs through it: when a single result falls short, don't stop at fixing that one issue, try to encode it to improve the system for all future iterations. Same idea as encoding verification into a skill at layer one, a single problem should settle into a system improvement.
Managing token usage
| Do this | The point |
|---|---|
| Choose the right primitive and model | Smaller tasks don't need multiple agents or loops; some can use cheaper, faster models |
| Define clear success and stop criteria | Be specific about done so Claude arrives sooner, but not too soon |
| Pilot before a large run | Dynamic workflows can spawn hundreds of agents; gauge usage on a smaller slice first |
| Use scripts for deterministic work | Running a script beats reasoning through the steps; e.g. a PDF skill ships a form-filling script Claude runs each time |
| Don't run routines more often than needed | Match the interval to how often the thing you're watching changes |
| Review usage | /usage breaks down by skill / subagent / MCP; /goal with no args shows turns and tokens; /workflows shows each agent's usage and lets you stop it |
One table: what you hand off
The blog closes with one table, organized around what you hand off. It's the same column as the ladder in the hero: from handing off the check, to the stop condition, the trigger, and finally the whole prompt.
| Loop | You hand off | Use it when | Reach for |
|---|---|---|---|
| Turn-based | The check | You're exploring or deciding | Custom verification skills |
| Goal-based | The stop condition | You know what done looks like | /goal |
| Time-based | The trigger | The work happens outside your project on a schedule | /loop, /schedule |
| Proactive | The prompt | The work is recurring and well-defined | All of the above, and dynamic workflows |
The blog's starting method is concrete too: look at the work you already do, pick one task where you're the bottleneck, and work out which piece you could hand off, whether you can write the verification check, whether the goal is clear enough, whether the work arrives on a schedule. Once you have an idea, run the loop, observe where it stalls or over-reaches, and iterate on it.