Loop Engineering

Loop engineering is designing the loops around an AI agent rather than tuning a single prompt. Three loops sit around the agent's own cycle of acting and observing. Checks verify its output and send it back when it fails, triggers start a run when something happens, and feedback from traces across many runs improves the harness.

A prompt shapes one answer. The loops decide what happens after each answer: accept it, retry it, hand it to a person or stop. They also decide what the next run learns.

We read loop engineering as the part of harness engineering that deals with repetition. The harness holds the context, tools, state and permissions for one run, and the loops decide how runs follow each other. They fail in ways a single run never shows. An agent keeps going after it should stop, a trigger starts the same run twice, or a harness change fixes the traces it was tuned on and breaks the rest.

What is loop engineering, and where did the term come from?#

DeepLearning.AI released a free short course, Loop Engineering with LangChain Deep Agents, on 28 October 2026. Its announcement gives the idea in one line: add loops that check output, trigger runs on events, and improve the harness from traces across runs. Sydney Runkle, who maintains Deep Agents at LangChain, teaches it with Esmaeil Gargari of DeepLearning.AI. The course names four loops: the agent loop, a verification loop, an event-driven loop and a hill-climbing loop that learns from many runs.

The phrase was already circulating among builders the week before. AndreaPN listed it with prompt, context, harness, graph and cache engineering. Pavan Belagatti set it against graph engineering, with loops for open-ended work and graphs for steps known in advance. Geoffrey Huntley, whose July 2025 write-up ran a coding agent in a bare Bash loop, tied good loop engineering to rapid security incident response. He made the case ahead of a talk at ContainerDays Singapore on 27 October 2026.

We treat those names as a map of where a fix goes, not as separate disciplines. Prompt and context engineering change what the model reads on one turn, harness engineering changes the runtime around one run, and loop engineering changes what happens between turns and across runs. Find the layer a failure lives in before writing the fix, since a prompt edit cannot stop a loop that has no exit, and a new loop cannot repair a tool that returns malformed output.

Belagatti's split matches how we choose between a workflow and an agent. If a person can write the steps down, we write them down, and a loop runs only where the next step depends on what the last one found. Our page on the AI software factory takes the same sequence one step further, to a harness and its loops shared by a whole team.

What is an agentic loop, and what sits around it?#

The agentic loop is the agent's own cycle. The model picks an action, a tool runs it and the result comes back, and then the model picks again until the goal is met or a limit stops it. Loop engineering starts there and adds three more loops, each with its own way to end.

The verification loop checks each result against something the model cannot argue with, and sends a failure back with the error attached. On Skionis, the DevOps agent we shipped on a live AWS account, a validation loop runs structural and semantic checks against the account before anything is applied. Template errors before deploy fell from around 10% to 4% once that loop sat in front of the engineer's approval.

On Solarpunk, a critic we built decides after every step whether to continue, retry or escalate. The run then compares what the agent claims it finished with the real state of the application. Our page on Reflexion and self-correction covers how to write that retry.

The event-driven loop starts runs without a person. The course wires its agent to a Slack message or a Jira ticket, so nobody is watching when the run begins and the harness has to assume that.

Give a triggered run the same permission scope and approval points as a run a person started. Enforce them in the tool rather than asking for them in the prompt, as our guide to human in the loop AI agents sets out. Make every action safe to repeat, because a source that delivers the same message twice will start the same run twice.

The hill-climbing loop reads traces from many runs, finds the failures that repeat, and changes the harness so the next run avoids them. We give it its own section below, because it changes the system the other loops run inside.

How many rounds should an AI agent loop run?#

Every loop needs a cap, and the cap belongs in the harness. AI Native Dev posted an account from Simon Maple of Tessl about a pull request whose agent ran 66 review rounds, kept going after a person said stop, and cost roughly $800. Their lesson is that loop engineering starts with a limit, and that every agent loop needs a run cap tuned to its environment.

Set the cap from the round counts good runs need in testing, not from a guess. A verification loop still failing by then usually has a cause another round will not fix: a wrong plan, a missing permission or a vendor that is down.

On Skionis, we send a template that will not come clean after bounded revision to a person, as a request the agent cannot safely fulfil. We bound Solarpunk's retries for the same reason, because an agent that retries indefinitely against a broken vendor burns cost and time while looking busy.

A person's stop has to end the run. Maple's pull request kept running after someone asked it to halt. A stop sent as a message competes with everything else in the agent's context, while a stop the harness checks before each round does not depend on the model at all.

Put a token or dollar budget beside the round cap and check both before every round. Hand the run to a person with its trace attached, so whoever picks it up can see whether the plan or the environment failed.

How should traces improve the harness?#

The hill-climbing loop changes the system, so it needs the most care. Its input is the trace of every run: what entered the context, which tools ran, what came back, and each check and retry. Our harness work starts the same way, with a real run traced end to end before anything changes. Most harness decisions come out of that trace rather than out of opinion. Our page on LLM observability sets out what goes in one.

On Skionis, every validation failure and its revision sit in one record with the request and the result. Those failures are the system's own log of what the model gets wrong, and we use them to improve the loop rather than the prompt.

On Solarpunk, each trace tells a planning defect apart from an outage, an expired session or stale state. Feed only the planning defects back into the harness, because a loop that learns from outages changes the agent to work around failures that were never the agent's.

On the trademark drafting platform, we treat attorney corrections as the signal automated scoring cannot see. A person's edits belong in the traces this loop reads.

Let a person merge what the loop proposes. A harness change found by reading traces fixes the runs it was found in. Only an eval suite built from the rest of your traffic shows whether it broke anything else. We put that suite in CI, built from cases pulled from real traffic, with a gate that fails a build which regresses, and a harness change clears it like any other change.

Keep the gate, the permission scope and the trace outside what any loop can edit. A loop told to raise a pass rate can raise it by weakening the check. In OpenAI's misalignment report, updated 20 October 2026, a coding agent removed a monitoring integration and then denied removing it. In our harness work the permission scope is enforced in code the agent cannot edit. Give the loop that tunes the agent the same treatment.

Which loop to add first#

Add the loops in the order they protect you. Cap the agent loop and trace it before anything else, since an uncapped loop fails expensively and a run without a trace cannot be debugged.

Add verification next, against a check the agent cannot edit. On Skionis most errors die in that loop before AWS is asked to start anything. Add triggers once a run can finish safely with nobody watching, and the hill-climbing loop last, because it needs many traces and an eval gate before it is safe to run.

Skip a loop the work does not need. If a person can write the steps down, build a fixed workflow with a check at each step. Our guide on agentic workflows and AI agents sets out that choice.

An agent that runs a few times a month will not produce enough traces for a hill-climbing loop to learn from. A task a person already reviews line by line gains little from one either. Spend that effort on the verification loop instead.