What Is Loop Engineering? Definition & Process

Prompt engineering treats each AI call as a one-shot: you craft the input, the model returns an output, and you decide what to do next. That model breaks the moment an agent is expected to plan across multiple steps, execute tools, and self-correct when a step goes wrong. Somewhere in mid-2026, the practitioners running production coding agents stopped describing their work as prompt tuning at all. Anthropic’s head of Claude Code, Boris Cherny, said in an interview that his job had changed: he no longer prompts Claude directly, his “job is to write loops.” Around the same time, Google Cloud AI’s Addy Osmani published an essay that named the practice and gave it an anatomy.

That shift, from wording one prompt to designing the system that keeps prompting, has become its own category of engineering practice with a name and a set of design decisions of its own. This guide covers what loop engineering is, why it matters, how a loop is put together, the layers of loops that run at different cadences, and how the practice shows up in AI systems, software development workflows, and real use cases.

What is loop engineering?

Loop engineering is the practice of designing repeatable, self-directing workflows around an AI agent so that the agent, not a human, is prompted by the system on each iteration. A loop takes a task and a check, runs the task, examines the result against the check, and continues until the check passes or a stopping condition fires. Osmani distills the definition to a phrase: “Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.”

The reason the term appeared in 2026 and not earlier is that models became capable enough to sustain useful work across many turns, but no better at deciding when they are done or when they are wrong. Prompt engineering optimized the wording of a single call. Loop engineering optimizes the entire cycle: the task specification, the tools the agent can use, the signal that tells the loop it has succeeded, and the condition that tells it to stop trying. IBM’s Think team defines it as the practice of designing agentic workflows that iteratively guide agents toward a user-defined goal with minimal human intervention. A loop, at its core, is a task plus a check.

Why loop engineering matters

Autonomy without verification amplifies mistakes. A coding agent that runs for two hours without a checker will happily generate two hours of confidently wrong code, and the reviewer inherits every one of those decisions. The economics are just as sharp: tokens spent inside an unbounded loop compound quickly, and a loop with no stopping condition can burn a day of compute on a task a human would have abandoned in ten minutes.

The value of designing the loop, rather than each prompt, is that a well-formed loop turns those risks into design choices. The check decides what counts as done. The stopping condition decides what counts as too far. The observation step decides what the agent gets to see before it acts again. Once those pieces are in place, the same agent can run unattended for far longer without producing garbage, because the loop, not the human, is what keeps it honest. This is why teams shipping production agents have shifted their focus from prompt quality to loop quality.

How loop engineering works

A loop is a small state machine with a specific rhythm. The agent receives a task and any context the loop wants it to see, decides on an action, executes that action through a tool, observes the result, and hands control back to the loop’s verifier. The verifier compares the observation against the check and returns one of three signals: continue with the current plan, revise the plan and try again, or stop because the goal is met or a limit was reached.

 Two properties separate a real loop from an open-ended agent run. The first is that the check produces a structured, machine-readable signal, not just a text response. A test suite that fails with a specific error, a type checker that returns a list of violations, or a schema validator that names the missing field can be fed back into the next iteration as concrete guidance. The second is that the loop carries state outside the model’s context window. Osmani lists this as the sixth loop component, a markdown file, a Linear board, or anything else that holds progress between runs, and it is what lets a loop resume, branch, or scale to sub-agents without losing what has already been done. Structured feedback and durable state are what turn the loop from a chain of one-shot calls into a system that accumulates progress.

Core components of loop engineering

Loop engineering has an anatomy that has settled quickly across writeups from Anthropic, Google, and independent practitioners. The pieces are not a strict layering; they are the parts a working loop needs to have in some form.

Loop inputs: task specification and action surface. The task specification describes the goal in a form the loop can hand to the agent on each iteration. Good specifications are narrow enough that the check has something concrete to test against, and open enough that the agent has room to try more than one approach. Around that specification sits the loop’s action surface, the set of operations the agent can take: reading files, running commands, calling APIs, searching a codebase, writing to a database. The action surface bounds what the loop can accomplish and, just as importantly, what it can break.

Control: verifier and stopping condition. The verifier is the check step that produces the loop’s advancement signal. Tests, type checkers, linters, schema validators, and separate reviewer sub-agents are the common forms. Osmani argues that verifiers should be separate agents from the creator, because a model asked to grade its own work is a poor judge. Alongside the verifier is the stopping condition, the rule that ends the loop, whether the check passes, an iteration budget is hit, a cost cap is reached, or a human is paged. Loops without explicit stopping conditions are how organizations discover their token bill.

Scaling and persistence: shared state and sub-agents. Shared state is a durable place for progress, decisions, and open questions to live between iterations, whether that is markdown files, ticket boards, worktrees, or structured logs. The constraint is that the model forgets everything between runs, so the loop has to remember for it. Sub-agents and connectors are how a larger loop decomposes into smaller ones, each with its own task, verifier, and stopping condition, and how it reaches the systems it is acting on.

The three groups sit together as one design: inputs describe what the loop is trying to do, control decides when the loop advances or stops, and persistence carries the run across iterations that the model itself cannot remember. A loop missing any of the three fails in a recognizable way: no specification produces drift, no verifier produces confident garbage, no persistence produces a loop that cannot resume.

Types of engineering loops

Not all loops run on the same clock. Andrew Ng’s three-loop framing is the cleanest way to keep them straight: an inner loop that closes in minutes, a middle loop that closes over tens of minutes to hours, and an outer loop that closes over days to weeks. A production system is almost always all three, nested.

The inner loop is the agentic coding loop. The agent writes code, runs the tests, reads the failures, revises, and iterates until the tests pass or a budget is exhausted. The human is not in this loop; the loop’s check is a machine artifact. Cadence is short and cost per iteration is low, so the loop can afford many rounds. This is where loop engineering has landed first, because the check step is a solved problem for code.

The middle loop is the developer feedback loop. A developer inspects what the inner loop produced, decides whether it heads in the right direction, and steers the agent with higher-level instructions. The check here is human judgment about product direction rather than an automated test. Cadence is on the order of a working session, and the loop’s job is to catch errors of framing that the inner loop cannot see on its own.

The outer loop is the external feedback loop. Real users touch the software, alpha testers file bugs, A/B experiments return numbers, and the accumulated signal changes what the developer asks the middle loop to work on next. Cadence is days to weeks, the check is qualitative and messy, and this loop is where the earlier loops’ assumptions get corrected against the world.

The three loops close on different clocks because they answer different questions: whether the code compiles, whether the product is worth building, and whether anyone wants it. A production system relies on all three, and each has a recognizable failure mode when it drifts. An inner loop with no tests ships broken code, a middle loop with no developer attention lets the agent chase the wrong feature, and an outer loop with no user signal builds the wrong product well.

The loop engineering process

Designing a loop is a small project in its own right, and it tends to go through the same steps regardless of the task. The Augment Code guide sketches the same sequence.

Start by defining the bounded goal. A goal that reads like “make the app better” cannot be checked; a goal that reads like “the failing integration test in orders.spec.ts passes without regressing the others” can. Pick the action surface next: which tools the agent can call, which files it can edit, which systems it can reach. A smaller action surface is easier to reason about and safer to leave unattended.

Design the check before the loop runs. This is the step most first-time loops skip, and it is why they burn tokens without progressing. The check should be deterministic where possible, and where it cannot be, it should be delegated to a separate verifier sub-agent whose only job is grading. Set explicit stopping conditions on iteration count, wall-clock time, and cost. Instrument the loop so that every iteration writes its plan, action, observation, and verdict to durable state, because the useful debug information is almost always in the transitions between rounds, not inside a single one.

Finally, run the loop against a small representative task, watch what it does, and refine. Loop engineering is iterative on the loop itself, not just on the work the loop produces.

Loop engineering in AI and agentic systems

Inside an agent harness, a loop is the concrete implementation of the reason-act-observe cycle. The agent reasons about the current state, chooses a tool call, observes the tool’s response, and reasons again. The loop’s job is to make sure that cycle terminates and that the observation-to-reasoning handoff carries a signal the model can actually use.

The failure mode that loop engineering has to design around is grounding: the model can generate a plausible next step, but it will happily take that step against an incorrect understanding of the systems it is acting on. An agent that misreads a schema, hallucinates a column that does not exist, or joins two tables on the wrong key produces output that passes shallow checks and fails deep ones. Structured feedback from the verifier, delivered in vocabulary the agent understands, is what turns those cases from silent failures into inputs for the next iteration.

Grounding the check step on an enforced ontology

The check step is where loop engineering pays for itself, and it is only as strong as the semantic model it can validate against. When an agent queries enterprise data, syntactic checks catch broken SQL but miss the more common failure: a query that runs but asks for something the schema does not actually mean. PuppyGraph sits between agents and their data as an ontology layer that defines entities, relationships, and properties over existing warehouse and lakehouse tables, and validates every graph query against that ontology before it executes. Invalid entity or relationship references are rejected with structured, LLM-readable feedback explaining the violation in the domain’s own terms, not stack traces. That feedback closes the self-correction step of the loop cleanly: the agent sees exactly which entity or edge it hallucinated, revises its plan against the real ontology, and tries again on the next iteration. Because the traversal is executed inside PuppyGraph’s own engine over the customer’s tables in a warehouse or data lake, including direct reads of open table formats like Iceberg and Delta Lake, there is no separate graph store to keep in sync with the loop’s source of truth. In an agent loop over enterprise data, that is what makes the observe step return a signal the reasoning step can actually use.

Loop engineering in software development

At the team level, loop engineering describes an emerging software development lifecycle in which the units of work move from ticket to shipped code through nested agent loops rather than through hand-offs between people. The inner loops of individual coding agents connect to CI systems, code review bots, and deployment pipelines that themselves behave as loops with their own checks and stopping conditions.

Two shifts follow from this. The first is that continuous integration stops being a passive gate and becomes the primary verifier for the agentic coding loop. CI results are the check the loop reads on every iteration, so investment in test speed, flake elimination, and useful failure output has an outsized effect on how well loops run. The second is that the developer’s role moves toward loop design and inspection: choosing which tasks are loop-appropriate, writing the specifications, defining the check surfaces, and reviewing what emerged. The Augment Code team’s writeup frames the goal as always-on agentic SDLC loops that carry work from trigger to verified outcome, with humans involved where judgment matters and out of the parts where it does not.

Loop engineering use cases

Beyond code, the pattern shows up wherever a task has a mechanical check and a repeatable action surface.

Agentic coding. Claude Code, Codex, and IBM Bob run inner-loop coding agents that pick up tickets, implement changes, and iterate until tests pass. The loop is the product.

Incident response and SRE runbooks. An on-call agent reads alerts, correlates them against known signatures, executes a diagnostic tool, observes the output, and either escalates to a human or advances the runbook. The verifier is a set of health checks; the stopping condition is either resolution or paging a human.

Data quality and pipeline health. An agent examines pipeline output against expectations, isolates the offending record set, proposes a fix, and re-runs the pipeline slice. The check is a data-quality contract, and the loop only stops when the contract passes.

Autonomous evaluation and red-teaming. Evaluator loops probe a target model or system, score responses against a rubric, and iterate on the probe strategy. The check is the rubric score; the stopping condition is coverage or budget.

The pattern generalizes wherever three conditions hold together: a task decomposes into repeatable actions, an action’s result can be checked against a rule the loop can read, and the check produces a signal specific enough for the next iteration to act on. When one of the three is missing, the work reverts to a human doing the loop by hand.

Benefits of loop engineering

The practical wins come from turning three things into design surfaces rather than accidents.

Autonomy becomes bounded. A well-formed stopping condition means an agent can run unattended without turning into a runaway process. Quality goes up because the verifier catches errors the model would otherwise commit to on the next step. Human attention goes further, because engineers spend their time on the loops that matter and let the loop itself handle the iterations that a machine can grade. Loops also compose: a verified inner loop becomes a reliable primitive that a larger outer loop can call, which is what makes team-scale agentic SDLC feasible in the first place.

Challenges and limitations of loop engineering

The failure modes are as specific as the benefits. Loops without well-designed verifiers converge on outputs that pass the check while missing the intent, an effect that gets worse as models learn the shape of the checker. Runaway cost is the second common problem: without explicit iteration and budget caps, a loop can burn a large token bill on a task it will never solve.

Debugging is harder than in single-shot pipelines because the interesting behavior is usually in the transitions between iterations, and reproducing an issue requires replaying state that no longer exists unless the loop was instrumented for it. Osmani’s essay names a related human risk: smoother loops make it easier for the engineers overseeing them to disengage, so verification burden and comprehension debt shift onto the humans who eventually inherit the code. Loop engineering does not remove those responsibilities; it moves them from writing every prompt to designing and inspecting every loop.

Conclusion

Loop engineering is the design discipline that has grown up around AI agents becoming capable enough to run for hours but not reliable enough to trust unattended. The unit of work has become the loop that specifies the task, executes the action, checks the result, and decides whether to keep going. Practitioners who take the practice seriously spend most of their time on the check and the stopping condition, because those are what turn autonomy into a useful primitive rather than a risk multiplier. The loops that will matter most in the next year are the ones whose verifiers can catch semantic errors, not just syntactic ones, because that is where autonomous work meets the real complexity of enterprise data and systems.

Try the forever-free PuppyGraph Developer Edition and book a demo with the team to see how openCypher and Gremlin queries run over warehouse and lakehouse tables, with no graph-specific ETL, so the check step in an agent loop returns structured, semantic feedback instead of stack traces.