Loop Engineering: Know When to Check, Correct and Stop
An agent loop needs more than repetition. I explain how checks, bounded corrections and clear stopping conditions turn repeated attempts into useful work.
TL;DR
Loop engineering connects work to a check that is allowed to fail. A useful loop can make targeted corrections and recognise when it is finished or stuck. Success conditions, a budget and a recorded stopping reason belong in the design just as much as the next model call.
One more attempt is not a plan
“Keep going until everything works” sounds like a useful instruction for a coding agent. It postpones the important question: how will the agent know that it works?
Without an answer, the agent may repeat the same test, choose a different test or keep changing the result until it looks plausible. That creates activity. Whether the actual problem is getting smaller remains unclear.
I start at the other end. What must demonstrably be true when the work ends? Not “improve the landing page”, but perhaps: the agreed content exists in both languages, links lead to the intended destinations and the page remains usable on a small screen. Those checks require different evidence. None replaces the others.
Loop engineering needs feedback
In Getting started with loops, Anthropic distinguishes goal-based, time-based and proactive loops, among others. That classification helps choose an approach. For a particular workflow, I also need to know which observation will change the next action.
Task → Work → Verification
↑ |
| specific finding
| |
+-- correction allowed?
|
no → stop with reason
Verification passed → record result → finish
Useful feedback is not a general “try harder”. It identifies the checked revision, the problem and the expected behaviour. If a heading is clipped on mobile, that finding returns to the presentation task. It does not require another research round or an entirely new article.
I distinguish two return paths. The result may be wrong, in which case it needs correction. Or the assumption behind the task may be wrong, in which case the plan needs to change. If the required API does not offer a capability, a fourth implementation attempt will not help.
Retries, repairs and schedules are different things
A retry repeats a call after a temporary failure. A repair loop changes an artifact based on a finding. A scheduled run checks later whether the world has changed. These cases should not all trigger the same blind repetition.
Trying again later can make sense when an API is temporarily overloaded. Missing permission requires a different action. If the operation already happened and only the response was lost, repeating it might cause a second external effect. The Amazon Builders’ Library on idempotent APIs addresses precisely this boundary: repeated calls should not produce unintended duplicate outcomes.
For an agent, the practical consequence is to identify the failure category and observed state first. Then decide whether to wait, repair, read back or stop.
A concrete verification contract
For a bounded local correction run, I would write down the following contract. The numbers are an example budget, not a measured optimum:
Goal: The agreed presentation passes the specified checks.
Scope: Only the affected component and its language strings.
Checks: Function, DE/EN parity and defined browser viewports.
Limit: At most two correction rounds and 15 minutes.
Stop: Same failure without a new diagnosis, or broader scope required.
Result: Verified artifact, or an open finding with the latest evidence.
Why two rounds? Not because two is a special number. I want to set a finite boundary for this small experiment before it starts. A large migration would need a different budget. The important part is that the budget does not silently expand after the first failure.
A model must not lower its own standard either. If a test fails because a requirement is violated, the loop cannot simply remove the requirement. Changing the check needs a separate justification: was the test wrong, or is the product still wrong?
How I recognise a stuck loop
I compare findings, not just exit codes. If the same failure survives a correction unchanged, I need a new diagnosis. If two versions keep replacing each other, a shared contract may be missing. If access or a decision is unavailable, “blocked” is an honest state.
A useful loop recognises not only success, but when another iteration will not solve the problem.
Stopping must leave a usable result: which artifact was last checked, what remains open and what specific action would help. I can then take over or resume later without reading the entire conversation again.
Scheduled does not mean continuously operated
Claude Code documents /loop as a way to run recurring tasks within a session, with a limited lifetime. That is a different operating model from a durable service. The documentation was checked on October 4, 2026; version-specific behaviour can change.
A fixed, mechanical check does not automatically need a language model on every tick. An ordinary scheduler can measure a state and pass only a relevant change on for interpretation. That reduces overhead and makes the distinction between “nothing changed” and “the check did not run” visible.
From one loop to a system
The graph engineering article addresses dependencies between tasks. A loop answers how an individual result improves within that workflow. Harness design supplies the context and tools.
In the material on my learning platform Agentic Builders, separate write scopes and mechanical checks support one another. I would never infer from a green check alone that an entire system is safe. A check supports only the claim it was designed to test.
In session-orchestrator, this idea sits at the boundary between work and verification. The method is useful without a plugin too: a clear task, a meaningful check and a finite correction path.
If you want to assess an existing agent loop, start at its end. What counts as evidence? What happens when progress stops? Does an interrupted run leave enough behind to continue usefully? You can contact me with a concrete case.
Common questions
What is loop engineering?
I use the term for designing a work-and-verification cycle with a clear goal, feedback and stopping conditions. Repetition alone does not make an agent reliable.
How is a retry different from a correction loop?
A retry repeats a call after a temporary failure. A correction loop changes an artifact in response to a substantive finding. Both need limits, but they address different problems.
Does a passing test mean the work is complete?
Only when the test actually covers the agreed completion condition. A passing build does not prove that publication succeeded or that a payment flow works.