Getting started with loops

What a loop is, and the one line that matters

The team's definition is plain: a loop is an agent repeating cycles of work until a stop condition is met. That part is not the useful part — it has been written a hundred times.

The useful part is the sorting principle. They split loops by which piece of your judgment you hand off. Read that way, 'should I automate this?' becomes a sharper question: which single piece of my thinking can I safely give away here?

The post also opens with a caution most vendor content skips: not everything needs a loop. Start with the simplest thing that works and reach for these patterns selectively.

Turn-based — you hand off the check

The first type is the one most people use daily without naming it: the turn-based loop, or agentic loop. You send a prompt, the agent gathers context, makes the change, checks its own work, and hands it back; then you check it and write the next prompt. The judgment you keep here is the check.

The article's one real move is showing you how to hand even that off: write your manual review steps into a skill file so the agent runs them itself. Their worked example is a verify-frontend-change skill that starts the dev server, clicks the new button, screenshots before and after, confirms zero new console errors, runs a performance trace, and if any step fails, fixes it and reruns from step one rather than handing back half-checked work.

That is a real bar. Most people's idea of "the agent verified it" is much weaker than restarting the whole check from the top.

Goal-based — you hand off the stop condition

The goal-based loop is where you stop deciding when the work is 'good enough' and let a target decide instead. You give it a condition and a turn cap: get the homepage Lighthouse score to 90 or above, stop after 5 tries. Each time the agent tries to stop, a separate evaluator model checks the condition and sends it back to work until either the goal is met or the cap is hit.

The reason this works is also the reason it fails. The condition has to be deterministic (a test that passes, a score above a number), because 'looks done' is exactly what the main agent will claim so it can stop early.

The short version: a loop can only automate what you can measure. Vibes can't loop, specs can.

Time-based and proactive — the trigger, then the whole prompt

The last two types move the human further out. A time-based loop hands off the trigger: the same prompt re-runs on a schedule while only the inputs change (check my PR, address review comments, fix failing CI). Run locally, closing the laptop stops it; moved to the cloud, it keeps running without you.

A proactive loop hands off the whole prompt. An event or a schedule fires it, no human is watching, and it composes everything above: a schedule to watch for work, a goal to define done, skills to verify, and a permission mode that lets it act without stopping to ask.

That is the real ladder in the piece: check, then stop-condition, then trigger, then prompt. Each rung is one more piece of your judgment leaving the room.

Where it's thin — a vendor writing down its own product

Two honest caveats, because this is first-party content defining the primitives it sells. First, it is optimistic about how easy handing off is. It spends its length on the four types and one paragraph on token control, while the harder failure modes get no airtime: a stop condition the agent learns to fake (reward-hacking), context that rots as the window fills, and writes that aren't safe to retry.

Second, the gate for whether to build a loop at all is missing. A workable version of that test: build one only if the task repeats at least weekly, verification is automated, your budget can absorb wasted runs, and the agent has real tools to work with. The post's single 'use selectively' line only gestures at it.

The strongest case against reading vendor material like this is obvious: it is built to make more looping feel natural, and more looping sells more tokens. The defence is that the taxonomy is useful even if you build nothing new from it. It's a vocabulary, not a mandate.

The keeper — encode the fix, then label your loops

Under 'maintaining quality,' the post lands one line worth more than the taxonomy: when a result misses the bar, don't just fix that instance, encode the fix so the system improves on every future run. That is the whole difference between a loop that repeats its mistakes and one that gets better.

Put it together and the keeper is small and durable. Name which piece of judgment each of your loops hands off, and you can see at a glance which ones are missing a real check or a real stop condition.

That's a cheaper diagnostic than reading the code, and it still works on jobs you built months ago and haven't looked at since.

Vocabulary

• turn-based loop — you prompt, the agent works and checks itself, you review, repeat
• goal-based loop — runs until a success condition is met or a turn cap is hit
• evaluator model — a separate model that grades whether the goal is met before stopping
• proactive loop — an event- or time-triggered loop that runs with nobody watching
• reward-hacking — the agent games the stop condition instead of doing the work

If you're building — what to watch for

• Label every automated job you run with the single piece of judgment it hands off: check, stop-condition, trigger, or whole prompt. Anything you can't label is the first thing to look at.
• A loop can only automate what you can measure. If the stop condition isn't deterministic, the agent will declare victory early — that isn't a bug in the model, it's the incentive you gave it.
• Write your manual review steps down as a skill the agent runs itself, and make a failed step restart the check from the top rather than hand back half-verified work.
• When a run misses the bar, encode the fix rather than patching that one instance — otherwise the loop repeats the same mistake at scale.
• Before building a loop, apply the gate: does the task repeat at least weekly, can verification be automated, can the budget absorb wasted runs, does the agent have real tools? If not, do the simplest thing instead.

Reading it critically

• Vendor content: it defines the primitives it sells and is optimistic about them by design. Some of the surfaces it describes are research-preview, so they can change under you.
• It soft-pedals the hard parts — a stop condition the agent can't fake, context rot, idempotent writes, reward-hacking. It names token guardrails but not these failure modes.
• The 'start with the simplest solution' caution is one line against a whole post that pushes toward more loops. The real go/no-go test isn't in it.
• The four types overlap: proactive is just time-based plus goal-based plus skills, composed. Treat it as a teaching frame for which judgment you delegate, not four separate mechanisms.