Skip to main content
HomeAboutSolutionsIndustriesContact

Loop Engineering: Design the Loop, Not Every Prompt

A single prompt cannot fix a bug it has never seen run. Loop engineering is the practice of building the harness that lets an agent act, observe, reason and retry until a testable condition is met.

Verdeshell Team · 6 min read · Last reviewed

Stop prompting agents. Design the loops that prompt them — hand the agent a goal with a testable stop condition, then let it act, observe, reason and retry on its own.

The agent loop: act, observe, reason, retryAn agent acts on its environment, observes the real result, reasons about the gap, and retries. The cycle repeats until a testable stop condition is met, at which point the work is done.Actrun code, edit, testObserveread what happenedReasonwhy did it fail?Retryadjust, go againStop conditionall tests passNo human in the cycle — the loop ends when the condition is testable, not when it looks done.
One agent, one cycle. The loop only ends when the stop condition is actually testable.

What it is

Loop engineering describes a single agent repeating its own work toward a goal. The unit is not a prompt but a cycle: the agent acts, observes what actually happened, reasons about the gap between that and the goal, and tries again.

The cycle keeps running until a stop condition is met — and the important word is testable. "Until the code is good" is not a stop condition. "Until the test suite passes" is. That distinction is most of the engineering.

You will also hear the loop called the harness: the scaffolding built around a model rather than inside it. The model is the engine; the loop is the vehicle. Changing engines is easy and changing vehicles is not, which is why the loop is where the durable engineering value sits.

The loop in motion

Act — the agent runs code, edits files, executes the tests. Not describes them; runs them. An agent that can only produce text about what it would do has no loop, because there is nothing to observe.

Observe — it reads what actually happened at runtime. A stack trace, a failing assertion, a linter complaint. This is the step that makes the loop worth building: real feedback from a real environment.

Reason — it works out what went wrong and why, which is different from noticing that something went wrong.

Retry — it adjusts and goes again, with no human in between. If a person has to re-prompt at each turn, what you have is a conversation, not a loop.

Why coding pushed this pattern first

Software is the domain where the feedback is cheap, immediate and unambiguous. Tests pass or they do not. That makes it the natural first home for autonomous loops, and it explains why coding agents matured ahead of agents in fuzzier domains.

It also explains why single-shot generation disappoints on real codebases. Most bugs only surface once the code runs, in an environment the model never saw. One generation cannot close that gap, however good the prompt is — the information simply is not available at generation time.

The loop closes it by moving the interesting work after execution rather than before it.

The ReAct lineage

The pattern descends from ReAct — reason plus act — where a model alternates between thinking about a problem and taking an action in an environment, using the result of each action to inform the next thought.

What changed since is scale and autonomy. Early ReAct implementations alternated for a handful of steps under close supervision. Current coding agents run the same alternation for hundreds of steps against a real repository, which is what makes context management and stop conditions load-bearing rather than incidental.

What this means when you are buying or building

Ask what the stop condition is. If a vendor cannot state the testable state their agent works toward, the product is a conversation with extra steps.

Ask what the agent can actually touch. An agent without real tool access cannot observe, and without observation there is no loop.

Ask what happens on failure. Blind retry is not error handling — see the companion piece on what a well-built loop needs.

One request through an agent loopA goal enters the loop. The agent acts on the environment, observes the real result, reasons about the failure, and retries with an adjusted approach. The cycle repeats until the stop condition — a passing test suite — is met, at which point the loop exits as done.Goalfix the failing testActedit + runObserveread the outputReasonwhy did it fail?Retryadjust approachTests pass?the stop conditionDoneloop exits

1. Goal in — The agent is handed a goal with a testable stop condition — not a prompt describing what to type.

Step 1 of 7
Read this walkthrough as text
  1. 1.Goal in — The agent is handed a goal with a testable stop condition — not a prompt describing what to type.
  2. 2.Act — It edits the file and actually runs the test suite. Describing the change would give it nothing to observe.
  3. 3.Observe — It reads what really happened at runtime — the failing assertion, not its own prediction of one.
  4. 4.Check — Tests still failing, so the stop condition is not met. This check is the thing driving the loop.
  5. 5.Reason — It works out why it failed — which is different from noticing that it failed.
  6. 6.Retry — It adjusts the approach and goes round again. Repeating the same edit would be blind retry, not recovery.
  7. 7.Done — On a later pass the tests go green, the stop condition is met, and the loop exits on its own.
Step through one request. The loop only exits when the stop condition is actually met.

More in Building with GenAI

Anatomy of a Good Agent Loop7 min readGraph Engineering: Coordinating Specialized Agents6 min readLoops vs Graphs: How the Two Patterns Nest5 min read

Want this built properly?

We design and run these systems for clients. Tell us the problem and we will tell you whether an agent is the right shape for it.