What is an agentic loop?

Anthropic's Claude Code team defines a loop as an agent repeating cycles of work until a stop condition is met. They categorise loops by how they are triggered, how they are stopped, which primitive they use, and which tasks suit them. There are 4 types: turn-based, triggered by a prompt and stopped when the agent judges the task done; goal-based, stopped when a stated success condition is met or a turn cap is hit; time-based, triggered on an interval; and proactive, triggered by an event or schedule with no human present in real time.

What is the difference between the 4 loop types?

What changes is which part of the work you hand off. In a turn-based loop you hand off the check, so the agent verifies its own work instead of returning it to you. In a goal-based loop you hand off the stop condition, stating what done looks like so an evaluator decides when to stop rather than the agent deciding it is good enough. In a time-based loop you hand off the trigger, so the work starts without you. In a proactive loop you hand off the prompt itself, and the routine runs on events until you switch it off. Each rung requires more specification than the last.

Why do agent loops work in engineering but stall in product work?

Because climbing past a turn-based loop requires stating what done looks like, and deterministic criteria such as a passing test count or a score threshold are what make that possible. Engineering encoded those criteria decades ago in tests, linters and builds, so a coding loop inherits them. Product work is graded by taste, strategy, or a customer outside the company, and none of those return a pass or fail. The constraint is not model capability. It is that most product teams have never written down what good looks like in a form a second person would apply identically.

You Can Only Loop What You Can Grade

What is a loop? Anthropic's Claude Code team gives the definition I find most useful: an agent repeating cycles of work until a stop condition is met. They sort loops into 4 types, and the sorting is the interesting part, because it is not a capability ladder.

It is a delegation ladder. Turn-based, you hand off the check. Goal-based, the stop condition. Time-based, the trigger. Proactive, the prompt itself. Every rung costs you a piece of judgment you now have to write down, and that is where product teams stop climbing.

There is a lot of noise right now about loop engineering, and most of it treats loops as a single thing you either do or do not do. The taxonomy is more useful than the slogan, so it is worth walking the 4 rungs and being honest about which one your team is actually on.

Rung 1: you hand off the check

Every prompt already starts a loop. The agent gathers context, acts, checks its work, repeats if needed, and hands back something it believes is done. Then you verify it manually and write the next prompt. You are the gate, and you are in the loop for every pass.

The move up is to encode your manual verification so the agent runs it itself. Anthropic's guidance is specific about what makes that work: give the agent a way to see, measure, or interact with the result, and the more quantitative the check, the easier self-verification becomes. Their frontend example says never report a UI change complete based on a successful edit, start the dev server, click the control, screenshot before and after, confirm zero new console errors, and rerun from the top if any step fails.

Read that as a product document rather than an engineering one. It is a written definition of done, precise enough that a machine applies it identically every time. Most teams have never written one.

Rung 2: you hand off the stop condition

A single turn is often not enough, and agents do better when they can iterate. The problem is that an agent left to decide whether its own work is good enough will stop early. So you state the success criteria, and an evaluator checks the condition each time the agent tries to stop, sending it back until the goal is met or a turn cap is reached.

The example is one line: get the homepage Lighthouse score to 90 or above, stop after 5 tries. Two numbers, and the loop can now run without you.

This is the rung where deterministic criteria stop being a nice-to-have. A test count or a score threshold works because it cannot be argued with. Now try writing that line for a positioning document, a pricing page, or an onboarding flow. If you cannot, you have not found a limitation of the tool. You have found that your team has been settling "is this good" by conversation, every time, without a standard.

I have argued before that the metrics worth having are the ones a team can argue about in the same room. A stop condition is that argument, settled in advance and written down.

Rung 3: you hand off the trigger

Some work is recurring, where the task stays the same and only the inputs change, or it depends on an external system you have to poll. Summarize the overnight messages. Check whether the pull request got comments or broke CI. Here you hand over when the loop runs, on an interval or a schedule.

Cheap rung, real consequence. The work now happens whether or not you thought about it that morning, which is only an improvement if rungs 1 and 2 are solid. An unattended loop with a weak check produces more of whatever it was already producing.

Rung 4: you hand off the prompt

The top rung runs on events with no human present in real time. A routine watches for new bug reports, a goal defines what triaged means, workflows orchestrate agents to fix and review, and it all proceeds without stopping to ask permission. Each task exits when its goal is met, and the routine runs until you turn it off.

Worth noticing what you have given away by this point. Not the work. The specification. Everything the routine does is downstream of definitions written earlier, and if those are vague the loop industrialises the vagueness. This is the same reason pilots stall before production: a pilot needs an agent that works once, production needs something that decides on its own whether each run was acceptable.

3 practices that carry across every rung

Fix the system, not the result. The strongest line in Anthropic's guidance is that when a result misses the standard, do not stop at fixing that instance, encode it so the next thousand iterations improve. That is the difference between using a loop and building one. A team that only fixes outputs is doing manual work with extra steps.

Review with fresh context. Use a second agent for review, because a reviewer that has not been reasoning alongside the first one is less biased by its logic. The organizational version of this is older than agents, and it is the same reason the person who wrote the spec should not be the only person who signs off on it.

Match the cost to the judgment. Route routine passes to smaller, faster models and save the capable one for the calls that need judgment. Run scripts for deterministic steps rather than re-reasoning them each time. Pilot on a slice before a large run. None of this is glamorous, and all of it is the difference between a loop that pays for itself and one that quietly does not.

Where to start

The suggested starting point is the right one, and it is a diagnostic rather than a tutorial. Look at the work you already do, pick the task where you are the bottleneck, and ask which piece you could hand off. Can you write the verification check? Is the goal clear enough to state as a condition? Does the work arrive on a schedule?

Whichever question you cannot answer is the rung you are stuck on, and it is almost never the tooling. It is a decision your team has been making by feel, at the moment when that stops being affordable.