Stop prompting, start looping. Then build the loop that improves your loops

The four loop types showing up in agentic coding (turn, goal, time, and proactive), made concrete with fresh examples, plus the optimization loop that tunes the process the others run inside.

There's a shift happening in how people work with Claude Code, and it has a name: loops. The idea is almost embarrassingly simple. Instead of prompting an agent once and hoping the output is good, you give it a stop condition and let it repeat the work (gather, act, check, repeat) until that condition is met. You stop babysitting a single turn and start supervising an outcome.

Most of the writing about this is hand-wavy. So instead of another abstract explainer, here's the taxonomy made concrete, each type shown with a real task you could wire up this afternoon, plus a fifth loop that most people haven't gotten to yet.

The four loop types

A loop is an agent repeating a cycle of work until a stop condition is met. The four common types vary on two things: how the loop gets triggered (you prompt it, a clock fires it, or an event wakes it) and how it decides it's done (a pass/fail check, a target number, an open goal, or in the weakest case nothing but the trigger itself). Claude Code already ships the primitives that make these practical: the /loop skill for in-session repetition, Routines for scheduled and event-driven triggers. None of it is hypothetical.

Turn loops: verify before you answer

A turn loop adds one step to a normal prompt: check your own work before returning it. The agent gathers context, acts, then tests the output against a rule and only responds once the rule holds.

Say you have an agent writing a database migration. A plain prompt gives you SQL that looks right. A turn loop gives you SQL that has been applied to a throwaway copy of the schema, rolled back, and confirmed to leave the schema structurally identical, before the agent ever hands it to you. The stop condition is concrete: "up then down restores the same structure." One caveat worth building into the loop itself: this proves the structure round-trips, not the data. A DROP COLUMN and its matching ADD COLUMN leave an identical schema while destroying every value that column held, so genuinely destructive changes need an explicit data-preservation step (a backup column, a dual-write) before you can call them reversible.

Goal loops: work until you hit the number

Goal loops raise the bar from a pass/fail check to a target score. The agent produces something, an evaluator measures it, and if it falls short the measurement goes back in and the work is redone, repeatedly, until it clears the bar. This is Anthropic's evaluator-optimizer pattern with a hard number on the end: one process generates, a separate one grades.

Picture an agent tuning a slow SQL query. You hand it the query and one goal: get it under 200ms on the test dataset. It rewrites, runs EXPLAIN, times the result, sees 900ms, spots a sequential scan where an index should be, tries again, times 240ms, tries once more, hits 180ms, and stops. You defined the number once and walked away; the loop did the iterating. The power is that you never had to look at the intermediate attempts. Give any open-ended loop like this a ceiling too, a max iteration count or a token budget, so "keep trying" can't turn into unbounded spend.

Time loops: run it on a schedule

Time loops are triggered by the clock: every fifteen minutes, every morning at nine. Same task, run on a cadence.

For example: every morning at 8am, an agent pulls the overnight digest from your error tracker, clusters the new exceptions by root cause, and updates a triage doc with the three that spiked hardest. Nobody kicks it off; it just runs, and the doc is waiting when the team logs on. But notice what's missing: a time loop only automates the trigger. It carries no stop condition of its own, so by the definition above it's not a loop yet, just a timer wrapped around a prompt, a component you compose with a real one. That gap is the whole reason the next type exists.

Proactive loops: watch, act, don't stop until it's done

Proactive loops start from a trigger (usually an event, sometimes a schedule), run in the background without you prompting each time, and carry a goal as their stop condition. That goal is what separates them from a time loop: a time loop fires and re-runs; a proactive loop fires and won't go quiet until the goal is met.

Here's one worth stealing: watch the security-advisory feed for the packages your project depends on. When a vulnerability lands that affects a version you're on, the loop wakes up on its own, opens a branch, bumps the package, runs the full test suite, and doesn't stop until the suite is green and a pull request is drafted with the advisory linked. Two things keep this safe rather than reckless. First, the loop drafts a PR; it never merges. A human reviews and approves anything that ships, because a green suite proves the tests still pass, not that the bump is correct or benign. Second, the trigger is untrusted external text: advisories and their linked write-ups are attacker-influenceable, a live prompt-injection surface, so the agent does its work in a sandboxed, network-restricted environment. Inside those rails, you told it once what "handled" means and it works the problem until the fix is real.

Turn and time are the training wheels: turn has the thinnest real stop condition, time has none at all. Goal and proactive are where the leverage is, because both carry a real target: a proactive loop is really just a goal loop that earned the right to run unsupervised, on the work, never on the merge.

The fifth loop: one that improves your process

Here's the part most teams skip, and the one we built into our own workflow. Every loop above runs inside a development process, the ordered steps your agents follow to go from ticket to merged code. That process is itself a document. So what if you put a loop around it?

That's the optimization loop: our take on self-improving agents, in the spirit of Reflexion and self-taught optimizers, but pointed at the process rather than the model or its output. Each cycle does three things:

1. A builder delivers a real ticket by executing the current process step by step, and records telemetry on where the process was wasteful: which steps got redone, where it stalled, where checks had to run twice.
2. A scorer grades the delivered work against a fixed quality bar. This is the guardrail: it makes sure a faster process didn't quietly become a worse one.
3. An optimizer reads the telemetry and the score, finds the single highest-leverage piece of waste, and makes one bounded change to the process, then logs a falsifiable prediction about what that change will do next cycle.

The next iteration's first act is to check that prediction. If it was wrong, or if quality regressed, the change is reverted. A bad idea gets rolled back, not defended. Two things stay off-limits to the optimizer: it can't touch the quality bar it's graded against, and it can't touch review, approval, or security gates. A change that trades human sign-off for speed can sail past a quality bar that never measured for it, so those gates move only with a human's say-so. Over cycles, the process sheds waste while output quality holds.

This is a goal loop pointed one level up, at the way you build the code rather than the code itself. It pays off more slowly than the loops above, but it compounds: every improvement makes every future feature cheaper. That's the loop we think matters most, and the one that's easiest to get wrong.

What separates a loop that works from a loop that lies

Building loops taught us a few things that hold for any one you write:

• The stop condition has to be real and measurable. "Until it's good" isn't a stop condition; it's a hope. "Until the query runs under 200ms" or "until the suite is green" is one. If you can't measure the bar, you don't have a loop, you have a while-true.
• Don't let the agent grade its own homework. The strongest loops make verification independent, so the thing that judges the work is not the thing that produced it. An agent scoring its own output tends to grade itself generously, a self-preference bias we've watched play out in our own LLM-as-judge setups. Give the check its own evaluator, its own dataset, its own adversarial angle.
• Never let the loop move its own yardstick. A loop optimizing for a score will lower the score's definition if you let it. That's reward hacking, Goodhart's Law aimed at your own process. In our optimization loop the optimizer can edit the process but is hard-blocked from editing the quality bar. The constant has to stay constant, or the whole thing degenerates into cheating.
• Climb the ladder in order: stop condition first, autonomy second. Start with a turn loop, making an agent verify one thing before it answers. Graduate to a goal loop with a number you trust. Only then hand over the trigger, a schedule or an event, so the loop carries that goal into the background as a proactive loop. Do it before you have a goal, though, and all you get is a time loop firing blind. Once you've earned that trigger, scope those first unsupervised loops to reversible, low-blast-radius actions: branches and drafts, never direct pushes to main or changes to production. Skip a rung and you get a proactive loop confidently automating the wrong thing, unwatched.

Where to start

You don't need any framework to begin. Take one task you re-check by hand every time (does the migration reverse cleanly, does the query hit its budget, do the tests pass) and turn that check into a turn loop. When you trust the check, attach a number and let it become a goal loop. When you trust the number, put it on a trigger. Keep one line firm as you go: unsupervised applies to the work (branch, test, draft), not to what ships. A human still approves the merge, especially when the trigger is untrusted external input.

And once you've got a few loops running, ask the question most people don't: what loop should be watching my process? Model capability climbs no matter what you do. The compounding advantage goes to whoever also builds the loop that makes the work itself get better, cycle after cycle, without a human in the chair for every turn.