What Is Loop Engineering - and Why It Replaced Prompt Engineering in 2026

For two years, prompt engineering was the skill every developer with an AI tool was told to master. Get the phrasing right and the model would do what you needed. By early 2026, that stopped being true - not because prompting stopped mattering, but because it stopped being the bottleneck. The harder problem had shifted: what happens after the first good response? Who or what checks if the output is correct? What fires the next step? When does the whole thing stop?

Those are loop questions. And in June 2026, the field got a name for the work of answering them. Addy Osmani published an essay on agentic workflows, Peter Steinberger compressed the core idea into a sentence - "stop prompting your agents and start designing the loops that prompt them" - and the phrase stuck. Boris Cherny, who built Claude Code, said the same from the vendor side: his job had become writing the loops that drive the model, not the prompts. Loop engineering had arrived.

What a Loop Actually Is

A loop is not a while loop in the programming sense, though the analogy helps. Every agentic loop has four parts. The trigger is what starts it - a pull request opening, a cron job firing, a user submitting a task, an event from another system. The topology is the shape of the work: does the agent run linearly through steps, branch based on intermediate outputs, or spawn sub-agents in parallel? The verifier is what checks whether the goal has been reached. The stop rule is what ends the loop - success confirmed, budget cap hit, maximum retries exhausted, or a human flag raised before an irreversible action.

Agentic AI refers to systems where an AI model takes multi-step actions autonomously, using tools to interact with the world between turns. The loop is the scaffolding that controls those actions. Without one, you have a model that can reason and respond. With one, you have a system that can complete a job. The distinction is what separates a chatbot from an agent that actually ships code, files issues, or processes documents while you sleep.

The Engine Inside Every Loop

Large language models are the inference layer that every loop runs through. They generate the reasoning, the next action, the decision. But an LLM on its own has no memory of previous turns beyond its context window, no persistent state, and no way to call external tools without scaffolding around it. The loop provides all of that.

Context feeding is one of the loop's most important functions. Before each model call, the loop assembles what the model needs to see: prior outputs, tool results, relevant documents retrieved via RAG, and the current task state. A poorly designed loop feeds redundant or stale context, burning tokens on every turn and degrading output quality as the task grows. A well-designed loop feeds exactly what's needed for the current step and no more.

Tools are what give the loop reach. MCP - the Model Context Protocol - has become the standard interface for connecting agents to external systems: file systems, browsers, APIs, databases, calendars. Each tool call is a turn in the loop. The loop decides which tool to call, validates the result, and determines what to do next based on whether the call succeeded or failed.

Three Loop Topologies

Most production agentic systems use one of three shapes. Linear loops run steps in sequence: read, reason, act, check, repeat. They are the simplest to debug and the easiest to put spend caps on, but they fail at tasks that require parallel work. Branching loops route to different sub-tasks based on intermediate output - an agent that reviews a pull request might branch into a security path, a performance path, and a style path, each running independently. Multi-agent loops split work across multiple model instances running simultaneously, with a coordinating loop that assembles their outputs into a final result.

The topology choice has cost consequences. Multi-agent loops can complete in parallel what linear loops do sequentially, but they multiply inference spend. GitHub Copilot's first metered billing cycle landed developers with surprise charges they hadn't anticipated - almost entirely because agentic tasks running in the background consumed tokens without anyone watching. Loop topology is where cost control starts, not at the provider billing dashboard.

The Verifier Is the Hardest Part

Writing a trigger is easy. Writing stop rules takes thought. The verifier is what separates a loop that completes reliably from one that either loops forever or declares victory prematurely. Good verifiers are specific: did the test suite pass? Did the output match the expected schema? Did the agent produce a diff that touches only the files it was supposed to? Bad verifiers are vague: did the agent produce something that looks like what was requested?

Vague verifiers are where most agentic systems break down in production. A model asked to "write good code" will always believe it has - unless the verifier checks actual test output, linting scores, or compilation status. CodeRabbit's position in loop engineering is to be a code-aware verifier layer: automated PR review that catches issues at the verifier stage rather than at human review. The principle generalises. Any agent working on code, documents, data, or decisions needs a verifier that checks against the actual completion condition, not the agent's self-assessment.

Stop Rules and the Irreversible Action Problem

Stop rules govern two different scenarios. The first is success: the verifier confirms the goal is met and the loop exits cleanly. The second is failure modes: the loop has taken too many steps, spent too much, or is about to do something that cannot be undone. Sending an email, merging a branch, deleting a file, posting a social update - these are irreversible. A well-designed loop pauses before any of them and surfaces a human checkpoint.

This is not a limitation of agent capability but a design choice. Claude Cowork's async model - where a user starts a task at their desk, closes their laptop, and receives a notification when the agent needs a decision - is loop engineering expressed as a product. The agent runs continuously, but stop rules surface at decision points that only the user can resolve. Everything else completes without supervision.

What Loop Engineering Looks Like in Practice

A developer building a loop in 2026 is doing four things that weren't part of the job three years ago. Writing trigger logic: what event starts the agent, how is it debounced, what context gets passed in at launch? Choosing topology: should this run linearly or fan out across sub-agents, and what does parallelism cost? Designing verifiers: what are the concrete, checkable conditions that define success, and how does the loop detect partial failure? Defining stop rules: what is the maximum spend, the retry ceiling, and the list of actions that require a human before proceeding?

None of those questions appear in a prompt. They appear in the scaffolding around the model - in the orchestration layer, the tool schemas, the retry handlers, and the checkpoint logic. Supabase's $10.5 billion round was partly a bet that the infrastructure layer under agentic loops - databases, auth, real-time data - would become as critical as the models themselves. That bet is looking more accurate as loops become standard rather than experimental.

Prompt engineering is still a real skill. A well-formed task description, a useful system prompt, clear output formatting instructions - these still matter inside every loop turn. But they are the minimum. Loop engineering is what comes after: the discipline of designing systems that complete jobs, not just turns.