Loop Engineering: When 'Stop Prompting Your Agent' Became the Consensus

Peter Steinberger compressed the whole idea into one sentence: "stop prompting your agents and start designing the loops that prompt them." Addy Osmani gave it a name in a June 2026 essay. Boris Cherny, who runs Claude Code at Anthropic, added the exclamation mark: "I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops." Within four weeks the term "loop engineering" went from coined phrase to de-facto discipline across the applied-agent industry.

If you missed the shift, here's what happened and why it matters for anyone building on an agent framework.

What loop engineering actually is

Loop engineering is the discipline of designing the control system that prompts, verifies, and stops an AI agent — instead of hand-writing individual prompts and hoping the model figures the rest out.

The unit of work is no longer "prompt." The unit of work is a loop, with four parts, per the Claude Agent SDK's canonical definition: gather context, take action, verify work, repeat. Or, per the emerging longer taxonomy: trigger, topology, verifier, stop rules.

The best short summary comes from O'Reilly Radar, which framed it as the natural next step after prompt engineering: once the model is good enough that a single-turn prompt is no longer the ceiling, the interesting engineering work moves to what happens between the model calls.

The shift isn't new theoretically — ReAct, chain-of-thought, and agent frameworks have been about loops since 2023. What's new is that as of mid-2026 the biggest practitioners say out loud they no longer treat prompt writing as their primary craft. The loops are.

What the loop actually does

Read Addy Osmani's essay and the concrete anatomy shows up. A well-designed loop has six components, not one:

1. Automations — the entry point. A cron trigger, a webhook, a git push, a Slack message. The loop starts because something in the outside world happened.
2. Worktrees — an isolated execution environment. A branch, a container, a scratch directory. The loop's actions can be undone without destroying the surrounding state.
3. Skills — reusable playbooks the agent can invoke. Not the raw model. Not raw prompts. Named, versioned procedures the loop composes.
4. Connectors — the outside world the agent can read from and write to. MCP servers, APIs, databases. The loop's ability to be useful is bounded by the connector set.
5. Sub-agents — delegated specialists for isolated parts of the task. The loop hands off, tracks, and merges.
6. External state — memory, ticket status, PR status, whatever survives the loop dying and restarting.

Zoom in on the verify step and it's the most under-invested part of the whole discipline. The Claude Agent SDK team argues, in Anthropic's "Building Effective Agents" writeup, that the verifier is the actual bottleneck of the modern agent stack — not the model. A model that produces good work 90% of the time and a verifier that catches the 10% failures beats a model that produces good work 95% of the time and ships every result unchecked.

Why it beats prompt engineering

The old workflow: the human writes the prompt, iterates on wording, ships when the outputs look good on a handful of examples. This worked when the agent did one thing per prompt. It stops working when the agent does 40 things per invocation, some of which touch production systems, and the "prompt" is just the entry ticket to a 20-minute autonomous run.

Two things compound to make loops beat prompts:

• Compounding reliability. A single-turn prompt at 90% success is fine. A 20-step task at 90% per-step success is 12% success end-to-end. The way you get from 12% to 90% is not a better prompt; it's a verify step after every action that can bounce the loop back one turn instead of one task.
• State that survives failure. Prompts don't have memory of the last five failed attempts. Loops do. When a loop pushes a bad commit and CI fails, a well-designed loop reads the CI log, revises, and retries — inside the same task, without waking the human. That's not a prompt property. It's a topology property.

The secondary effect nobody talks about: loop engineering is auditable in a way prompt engineering isn't. When something goes wrong, the loop's execution trace shows which skill fired, which connector was called, what the verifier said, and where the stop rule kicked in. Prompts are a black box; loops are a program.

Where this is being built

The whole industry converged on this in about a quarter:

• Anthropic's Claude Agent SDK is the reference implementation for the "gather → act → verify" loop shape, and their engineering essays (Building Effective Agents, Effective Context Engineering, Effective Harnesses for Long-Running Agents) are the underlying playbook.
• OpenAI's Agents SDK ships a very similar shape, with slightly different verbs — its "handoff" primitive is the same idea as Anthropic's sub-agent delegation.
• LangGraph was arguably the earliest to name the graph-of-nodes idea, and it's the framework people reach for when the loop needs to be an explicit DAG rather than a controller function.
• Cline, Aider, and Continue are the loop implementations most developers touch daily — coding harnesses that gather repo context, take action via edits, verify via tests, and repeat.
• Trigger.dev, Inngest, and Temporal are increasingly showing up as the automation-layer substrate underneath these loops, especially for the long-running or scheduled variants.

The AI Builder Club's Anthropic-playbook writeup is a good synthesis of how Anthropic's four foundational essays cover the loop-engineering discipline even though the company has never used the term itself.

The interesting divergence is between two schools: the controller school (write a Python function that orchestrates model calls in an explicit loop — Osmani's default) and the framework school (declare the graph and let a library run it — LangGraph). Both work. The controller school is winning on visibility right now because it maps 1:1 to how Claude Code and the Anthropic SDK are structured.

How to evaluate a loop

If someone hands you a loop design and asks whether it will hold up in production, ask these:

• Where's the verifier? If every action ships to production without an intermediate check, this isn't loop engineering, it's prompt engineering wearing a loop costume. What specifically verifies each action, and how expensive is that verifier compared to the action?
• What's the stop rule? How does the loop know it's done? An explicit acceptance criterion? A budget cap? A max-turn cap? Loops without stop rules run until they crash or bankrupt the credit card.
• What survives a restart? If the process dies at step 14 of 20, does the loop resume at 14 or restart at 1? What state is in memory vs. on disk vs. in an external system?
• Are sub-agents isolated? Can a misbehaving child leak state into a sibling? Can the parent cancel a runaway child? What happens to partial child work when the parent aborts?
• What's the audit trail? For every action the loop takes, is there a machine-readable record of which skill fired, which connector was called, what the verifier said? If not, incident post-mortems will be miserable.
• Where does the human get involved? Every loop needs a human-in-the-loop escape hatch for the actions that shouldn't be autonomous. Where's yours, and how expensive is the interruption?

Prompt engineering is not dead. It's what happens inside each step of a loop. But it's no longer the interesting engineering surface. The interesting surface — the one that determines whether the agent ships useful work or just interesting demos — is the loop around it.

Boris Cherny was being blunt but literal: his job is to write loops.