Loop Engineering: Design the Loop That Prompts Your AI Agent

Stop feeding instructions to your agent one at a time. Build the loop that does the feeding for you. That shift in thinking has a name by now, loop engineering, and it changes what you spend your hours on when you work with AI agents.

The 2 a.m. problem

Picture a late night with a coding agent. It writes a patch. You run the tests and three fail. You paste the red output into the chat and type "fix these." The agent tries again, and you paste again. By the fifth round something dawns on you: every message you're sending is mechanical. Run the tests. Read the failure. Point at the probable cause. Try again. Stop once everything is green.

You're the most capable component in that system, and you're being used as a clipboard.

Thousands of engineers hit the same wall around mid-2026, and the idea that came out of it was blunt: quit prompting the agent and design the loop that prompts it instead.

From prompts to loops

Loop engineering is the latest step on a ladder the field has been climbing for years. Each step wraps the one below it rather than replacing it. First people tuned the words, then the data, then the environment. Now the cycle itself is up for design.

• Prompt engineering (roughly 2022 to 2024) asks which words to use. Its limit is plain: no wording can hand a model a fact it never received.
• Context engineering (2025) asks what data the model gets to see at inference time.
• Harness engineering (early 2026) asks what surrounds the model: tools, a sandbox, validators.
• Loop engineering (2026) asks which cycle should run and when it ends.

Your role moves along with it. You begin as an operator typing prompts, become a manager supervising several agents in parallel, and end up as a system designer. At that point you spell out what "good" and "done" mean, then let the machine chase those targets.

Here's a working definition. Loop engineering means deliberately designing the loop an agent runs in, including its trigger, goal, checks, memory and stopping rules, instead of hand-writing every next instruction.

Every agent already runs a loop

The twist is that no agent is without a loop. Nearly all of them have one, and few people shape it on purpose. That gap separates an agent that quietly finishes the job from one that burns through a budget overnight while sure it's making progress.

The underlying cycle is the ReAct pattern from 2022: think, act by calling a tool, observe the result, repeat until done. It's old news. What changed in 2026 is that people treat this cycle as the main thing to engineer, with the same care they'd give an API. When coding agents differ in quality, the base model is rarely the reason. The loop design usually is.

The verifier is the bottleneck

If one idea sticks, make it this one. In any loop, the verifier limits results, not the model.

A loop is simply a generator connected to a verifier. The generator, which is the model, is cheap and never gets tired, so a thousand attempts cost almost nothing. The verifier is what decides whether all that activity yields something useful or a pile of junk.

Looping pays off at all because of an asymmetry sometimes called verifier's law: for many tasks, checking an answer is much easier than producing one. That's the economics. Generate, check, regenerate, and you still come out ahead, because the check costs so little.

Verifiers come in two flavors, and picking between them is most of the craft:

• Deterministic checks run the tests, validate the schema or confirm a score. They're cheap, dependable and hard to fool, so prefer them whenever you can.
• LLM-as-judge setups have a second model grade the output against a rubric. They suit fuzzy goals, but they can be gamed, and biases around position, verbosity and self-preference are well documented.

The risk is easy to miss. A weak verifier doesn't fail loudly. It produces garbage with confidence, hundreds of times in a row. That's why writing the verifier has become the new prompt engineering.

Stack loops around loops

What turns this into a craft is nesting. Think of four concentric loops, each running on a slower clock. The inner one gets work done, and every outer ring makes the system more reliable, more autonomous and eventually able to improve itself.

1. The agent loop. The model calls tools until the task is complete.
2. The verification loop. A grader scores the output against a rubric and returns it with feedback if it falls short.
3. The event-driven loop. Webhooks, cron jobs or incoming messages start runs, so the agent works while you sleep, and a person can approve before anything ships.
4. The hill-climbing loop. A separate analysis agent reads production traces and rewrites the harness itself: prompts, tools and rubric. The system improves the system.

The usual advice is to push outward toward loops three and four, where gains compound. That's sound, with one caveat. A fourth loop wrapped around a weak verifier just automates confident garbage at scale. So stack outward for extra reach, but only once the innermost verifier is strong.

Write the contract, not the prompt

Here's what the change looks like in practice. You stop writing instructions and write a definition of "done" instead, meaning a reward function plus a stop rule, and let the loop chase it:

Goal: get the test suite passing.
Done when: all tests green - and no test was skipped or deleted to fake it.
Loop: run tests -> read failures -> fix the likely cause -> run again.
Stop when: done, or after 6 rounds (then summarize what's left).

Not one instruction went to the model, and that is loop engineering at its smallest.

Bound the loop, or it bounds your budget

A loop multiplies your effort, and that cuts both ways. Give every loop three exits: success when the verifier passes, surrender when a cap or budget runs out, and hand-off when it escalates to a human. The governing rule is that the harness, never the agent, must guarantee that the loop ends.

Each typical failure has a matching guardrail:

• Endless spinning is handled by a hard cap on iterations plus detection of runs that make no progress.
• Runaway cost is handled by budget checks before every call and cheap triage ahead of expensive work.
• A hallucinated "done" is handled by a separate, deterministic verifier. Never let an agent grade its own work.
• Reward hacking is handled by hardened criteria and a human gate on sensitive actions.

Before a loop ever runs unattended, test the verifier against cases you know are good and cases you know are bad. Confirm it rejects the bad output, and not merely that it accepts the good. A verifier nobody has tested is only an opinion.

Keep your hands on the wheel

Automation doesn't mean stepping out of the process. Put a human checkpoint where it counts: approving risky tool calls, grading high-stakes output, signing off before a change to the harness goes live. There's also a quieter cost. When a loop ships a fix, you've shipped something you may not fully understand. That gap has been called comprehension debt, and it may turn out to be the next form of technical debt.

The ethic fits in one sentence: build the loop, but build it like someone who plans to stay the engineer rather than just the person who presses go.

2 a.m., revisited

It's 2 a.m. again, and this time you're asleep. Hours earlier a webhook fired. By morning a draft pull request is waiting. The loop stopped short of merging because that's a decision it isn't permitted to make alone, and it left a clean summary of what changed and why.

You're no longer the clipboard. You're the person who designed the machinery, and every piece traces back to a decision of yours: the goal, the verifier, the limits, and the points where it has to pause and ask.

That's loop engineering. Build one, and build it so you stay the engineer.