Loop engineering

Loop engineering turns recurring work, the weekly report, the metric you watch, into a system that runs itself and sharpens with every cycle. For an analyst, that means building the system that decides what to do next. Boris Cherny put it plainly in May 2026: "I don't prompt Claude anymore. I have loops prompting Claude and figuring out what to do."

Loop Engineering with Agents infographic. On the left, the core agent loop cycles through reason, act, observe, and reason again, repeating until the goal is met or a stop is decided. On the right, loop engineering is designing that system: define the goal, set checks and guards, decide when to stop, provide tools and context, and measure and improve. Along the bottom, the old way of telling the agent what to do at each step gives way to the new way of defining the system so the loop does the telling.
The core loop on the left, the system you design around it on the right. Loop engineering is the move from micromanaging each step to shaping the loop that gets the work done. Diagram from Loop Engineering with Agents.
A note on scope. This treatment is written for business objectives and analyst use cases, so the codebase-specific parts of loop engineering are left out on purpose: git worktrees, parallel branch exploration, and pull requests or test suites as the unit of work. Those assume you are looping an agent over a repository. If that is your world, Anthropic's getting started with loops covers them well.

A cron is not automatically a loop

A schedule says when a job runs. Loop engineering determines what happens between runs. A cron can be doing it, but only when four things hold at once: it reads what the last run did, it works toward success criteria it cannot renegotiate, it has a stated limit on what it may do, and a separate checker confirms the success criteria are met. Drop any one of those and it is a scheduled job wearing a loop's name.

The working pattern has two parts: the schedule runs the check, and a goal drives the fix. A daily run looks at whether the conversion rate has left its normal band. Only when it has does a goal take over, working until the variance is explained and the summary is posted. The four kinds of loop sort this out by what starts a run and what stops it.

Define success criteria before anything else

A loop that runs until success criteria are met needs those criteria stated in terms it can evaluate. A goal with no success criteria is the most expensive failure the sources report, and most failures trace back to a fuzzy contract. Everything downstream is cheaper once that goal is sharp.

Addy Osmani reduces a goal to three parts: a command, a verifiable condition, and a bound. Deterministic success criteria work best as a count or a threshold: "every account in the region reconciles to the ledger, within 10 turns." The catch is what does the checking. In Claude Code, the goal evaluator reads the transcript and asks whether the hard rules were met. It does not judge quality, so taste stays with whoever reads the output.

The spine, and intent it can read

Persistent state is the spine: each cycle appends its outcome so the next run starts informed by what the last run found. Intent lives outside the session too, written down once and read on every run, because an agent starts each session cold and fills any gap with a confident guess. Reaching the tracker, the database, and the chat happens over MCP and ordinary APIs.

Split the maker from the checker

The run that did the work should not grade it. A separate checker with its own instructions beats an agent marking its own homework; it costs more tokens and buys the quality back. Then bound the whole thing: caps on iterations and spend, a wall-clock timeout for stalls, and an expiry so a forgotten loop stops itself. Add a stop for spinning too. When the same attempt comes back with the same result a third time, Osmani ends the run, and his goal example aborts after two turns that show no progress. And read what it ships, or comprehension debt quietly grows; what to hand a loop covers where that reading cannot be skipped.

Whether the loop survives the session that created it depends on where it runs and the agentic stack underneath. In Claude Code, /loop runs on the local machine, stops when the machine is off, and its recurring tasks expire after seven days. /schedule runs routines in the cloud for work that has to outlast the laptop.

Start with the check you already run

Osmani's first loop was a check he already did by hand every morning, his pull request backlog. The analyst equivalent is the dashboard you open before coffee. It already has a known shape, a known normal, and a known next step when something looks wrong, which is most of a goal already written down.

The bottom line

Define success criteria that a checker can test, give the loop a memory and a separate checker, bound it, and start with a check you already run by hand.

Sources: IBM, "What Is Loop Engineering?"; Addy Osmani, "Loop Engineering" and "Practical Loop Engineering" (2026); and Anthropic, "Best Practices for Claude Code" and "Getting Started with Loops." The four conditions and the maker and checker split are assembled from those; no single source publishes loop engineering as one ordered procedure.