Loop Engineering

Definition

The Claude Code team defines a loop as an agent repeating cycles of work until a stop condition is met. Loop engineering is the shift from writing better single prompts to designing the stop condition, the trigger, and the verification step around the agent.

Loops are classified by four properties: how they are triggered, how they are stopped, which harness primitive implements them, and what kind of task suits them. The guidance is explicitly not “always use a loop” — start with the simplest thing that works and reach for these selectively.

---

Core Ideas

The four loop types

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	work happens outside your project on a schedule	/loop, /schedule
Proactive	the prompt	work is recurring and well-defined	all of the above + dynamic workflows

The progression is a ladder of delegation: each rung hands the agent one more part of the loop that you were previously holding.

Turn-based (the agentic loop)

• Triggered by: a user prompt.
• Stops when: the model judges the task complete or needs more context.
• Best for: short tasks outside any regular process.
• Cost control: specific prompts, plus better verification so fewer turns are needed.

Every prompt is already a manual loop with you directing each turn — gather context, act, check, repeat, respond. The weak point is that the agent hands back something it believes works, and you do the checking. The fix is to encode your manual check steps as a SKILL.md so the agent can verify end-to-end, giving it tools that let it see, measure, or interact with the result. The more quantitative the check, the better it self-verifies.

The article’s worked example is a verify-frontend-change skill: start the dev server, open the page, click the new control and screenshot before/after, require zero new console errors, run a performance trace and audit Core Web Vitals — and “if any step fails, fix it and rerun from step 1; do not hand back partially verified work.”

Goal-based (/goal)

• Triggered by: a manual prompt, in real time.
• Stops when: the goal is achieved or a maximum turn count is reached.
• Best for: tasks with verifiable exit criteria.
• Cost control: specific completion criteria plus an explicit turn cap (“stop after 5 tries”).

The mechanism: each time the model tries to stop, an evaluator model checks your stated condition and sends it back to work. Defining “done” yourself removes the model’s judgement call about what counts as good enough — which is why deterministic criteria (tests passing, a score threshold) work so much better than qualitative ones.

/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.

Time-based (/loop, /schedule)

• Triggered by: a time interval.
• Stops when: you cancel, or the work completes (PR merges, queue empties).
• Best for: recurring work, or interfacing with an external system.
• Cost control: longer intervals, or react to events rather than to time.

Two shapes fit here: work where the task is fixed and only the inputs change (summarise Slack every morning), and work that depends on an external system you can only poll (a PR that may get reviews or fail CI).

/loop 5m check my PR, address review comments, and fix failing CI

/loop runs on your machine and dies with it; /schedule moves the same idea to the cloud as a routine.

Proactive

• Triggered by: an event or schedule, with no human present.
• Stops when: each task exits on its goal; the routine itself runs until turned off.
• Best for: recurring streams of well-defined work — bug reports, issue triage, migrations, dependency upgrades.
• Cost control: route routines to smaller/faster models, save the most capable model for judgement calls.

This is composition rather than a new primitive — /schedule for the trigger, /goal for the stop condition, skills for the verification, dynamic workflows to orchestrate agents, and auto mode so it doesn’t stall on permission prompts:

/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.

Loop output quality is a property of the system, not the prompt

• Keep the codebase clean — the agent copies whatever patterns already exist.
• Give it a way to verify its own work — encode “good” as skills.
• Make docs reachable — framework and library docs carry current best practice.
• Use a second agent to review — fresh context is less biased than the agent that wrote the code. “Loops that write code need loops that check it.”

The compounding rule: when a result misses the standard, don’t just fix that result — encode the fix so every future iteration inherits it.

Bounding token cost

• Match the primitive and model to the job; small tasks don’t need multiple agents.
• Define clear success/stop criteria so it converges sooner (but not too soon).
• Pilot before a large run — dynamic workflows can spawn hundreds of agents, so gauge cost on a slice first.
• Use scripts for deterministic work — running a script is cheaper than reasoning through the same steps every time (e.g. ship a form-filling script inside a PDF skill rather than re-deriving the code).
• Don’t run a routine more often than the thing it watches actually changes.
• Review usage: /usage breaks down spend by skill, subagent, and MCP; /goal with no arguments shows turns and tokens so far; /workflows shows per-agent usage and lets you stop one.

Model and effort level are called out as among the biggest levers on what a loop costs.

How to start

Look at work you already do, pick one 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? Does the work arrive on a schedule? Then run it, watch where it stalls or over-reaches, and iterate on the loop itself.

---

Relationships

• Context Engineering — designing what the agent sees each turn; loop engineering designs what makes it stop
• Reasoning Effort Control — the effort dial named as a primary cost lever inside a loop
• Model Context Protocol (MCP) — how a loop gets tools that let it see and measure its own result
• AI Model Routing — routing routine iterations to cheaper models and reserving the capable one for judgement
• Developer Productivity Measurement — measuring what these loops actually deliver
• Coding Agents and AI Tools — parent topic
• AI-Native SDLC — the six-stage delivery loop these primitives assemble into
• Agent Skill Evolution — an outer loop whose stop condition is a validation score, with rollback

---

References

• Loop engineering: Getting started with loops — Delba de Oliveira and Michael Segner, claude.com/blog