Agentic AI
Loop engineering: why the best AI agents in 2026 are built as loops, not prompts
Prompt engineering asked “what should I say?” Loop engineering asks “what system should run so the agent finds the work, does it, verifies it, and remembers what it did — without me in the loop?” The bottleneck has moved from model capability to orchestration design.
Published . Updated . 9 min read
Key takeaways
- Loop engineering treats a task as an iterative system — trigger, goal, actions, verification, memory — instead of a single request and a single answer.
- A loop is only as good as its verification step and its termination condition: without a measurable goal and a way to check it, an agent loops forever or stops too early.
- RightOne.ai already runs the building blocks of a loop — routing, tools, sandbox execution, TODO tracking, SSE progress — so the move to explicit loop engineering is about wiring them into a controlled act/observe/decide cycle, not inventing them.
For two years the headline skill in applied AI was prompt engineering: the art of phrasing a single request so a model would answer well. In mid-2026 a different phrase took over the conversation. Engineers stopped talking about what to type and started talking about what to build around the model so it could keep working on its own.
That shift has a name: loop engineering. It is the practice of designing systems that prompt AI agents automatically, rather than a human typing each instruction. Boris Cherny, who created Claude Code at Anthropic, summarized the mindset bluntly: “I don’t prompt Claude anymore. I have loops that are running.” The term was popularized in June 2026 by Addy Osmani, synthesizing ideas from Cherny and Peter Steinberger, after agents became capable enough to run multi-step work autonomously for hours at a time.
Prompt engineering vs. loop engineering
The difference is not that prompts stopped mattering. It is where the leverage moved. A prompt is one turn of work driven by a human. A loop is an autonomous run driven by a system you designed. The core skill changes from phrasing to architecture.
| Dimension | Open-source model route | Closed-source model route |
|---|---|---|
| Unit of work | Prompt engineering: a single turn. You ask, the model answers, you read it. | Loop engineering: an autonomous run that can span many steps and a long stretch of time. |
| Who drives it | Prompt engineering: a human types every instruction. | Loop engineering: a designed system supplies the next instruction from the last result. |
| Core skill | Prompt engineering: phrasing and wording. | Loop engineering: goals, tools, verification, memory, and stop conditions. |
| Failure mode | Prompt engineering: a weak answer you can immediately reword. | Loop engineering: a loop that never terminates, drifts off goal, or burns budget unsupervised. |
The five parts of a loop
Most descriptions of loop engineering converge on the same five parts. They are a useful checklist for whether something is really a loop or just a longer prompt.
- Trigger — what starts the run. A human message, a schedule, a webhook, an event, or the completion of a previous agent.
- Goal — a verifiable end state, not a vague aspiration. “All P1 issues triaged” is a goal; “help with issues” is not.
- Actions — the tools the agent can use: file edits, shell commands, web search, code execution, API and MCP calls.
- Verification — how the loop confirms it is actually done: tests pass, a grader approves against a rubric, a check returns clean.
- Memory — what persists across steps and runs so the agent does not repeat itself: session state, notes files, a database.
Loops stack
A practical way to think about it, from LangChain’s writeup, is that loops stack. The innermost loop is the agent core: give the model context and let it call tools until it decides it is done. Wrap that in a verification loop: a grader checks the output and, if it fails, sends it back with feedback. Wrap that in an event-driven loop: a schedule, document, or webhook fires the agent without a human present. Finally a hill-climbing loop feeds production traces back into the harness so the loop itself improves over time.
Each layer adds reliability at the cost of latency and complexity, and each layer has a natural place to insert a human checkpoint. You do not have to build all four. You climb the stack only as far as the task justifies.
Loop engineering is not “let it run unsupervised”
The risky reading of loop engineering is “set an agent loose and walk away.” The disciplined reading is the opposite: because the agent acts on its own, the system around it has to be tighter. Budgets and step caps. A clear stop condition. Verification before any irreversible action. Permission gates on dangerous tools. Logs you can read after the fact. An autonomous loop without those guardrails is not productivity, it is an expensive way to make a mess quickly.
What this means for RightOne.ai
RightOne.ai already routes each turn to the model that fits the job, runs tools like web search and code execution, tracks a model-authored TODO list, and streams progress over SSE. Those are the raw materials of a loop. The move to explicit loop engineering is mostly about wiring them into a controlled act → observe → decide cycle with a measurable goal and a hard stop — and doing it without giving up the cost discipline that routing already provides.
It also fits the routing thesis directly. In a loop, not every step deserves the same model. Planning and verification may want a stronger model; the routine middle steps can run on a cheaper one. Loop engineering and effort-aware routing are the same instinct applied at two scales: spend deep work only where the step actually needs it.