The Leverage Point Moved

In mid-2026, a single idea moved through the AI-building community faster than almost anything since the launch of coding agents: stop prompting your agents, and start designing the loops that prompt them.

On June 7, 2026, Peter Steinberger — creator of the open-source agent project OpenClaw — put it in twelve words: “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.” Days earlier, Boris Cherny, who leads Claude Code at Anthropic, had said much the same thing in a widely shared talk: “I don’t prompt Claude anymore. I have loops running. They’re the ones prompting Claude and figuring out what to do. My job is to write loops.” Within a week, Addy Osmani’s essay “Loop Engineering” had become the reference text, and a wave of follow-up writing tried to pin down what a “loop” actually was.

This article treats loop engineering as the main subject and reviews three adjacent disciplines — prompt engineering, context engineering, and harness engineering — against it. That framing is deliberate: the cleanest way to understand what loop engineering is turns out to be understanding what it is not, and where its boundaries with those neighbors sit.

The one-sentence version for the busy reader: for the last few years the unit of AI engineering has been climbing a ladder — from the prompt (the words you send), to the context (everything the model sees), to the harness (the runtime wrapped around the model), and now to the loop (the system that keeps an agent working toward a goal over time, checking itself and deciding what to do next). Loop engineering is the top rung as of this writing — and, fittingly for something only weeks old at scale, it is also the least settled. Where useful, this piece flags what is genuine consensus versus what is still being argued out.

This is a synthesis of primary sources published between December 2024 and June 2026; all are linked in the References section.

Two Things People Mean by “Loop”

Most of the confusion around loop engineering comes from one word doing two jobs. Before going further, it helps to separate them.

1. The inner agent loop (a mechanism). This is the think–act–observe cycle that runs inside a single agent session. Simon Willison’s working definition is the canonical one: an LLM agent is “something that runs tools in a loop to achieve a goal,” and Solomon Hykes put the same idea more vividly — “an AI agent is an LLM wrecking its environment in a loop.” The pattern was formalized as ReAct (Reason + Act) in 2022 and is now the heartbeat of every agent runtime. Anthropic’s Claude Code documentation describes it precisely: the model receives a prompt, evaluates it, may call tools, the runtime executes those tools and feeds results back, and this repeats — one turn per round trip — until the model returns text with no tool calls, which is the signal that it is done. Barry Zhang has compressed the whole thing to two lines: while True: action = llm.run(system_prompt + env.state); env.state = tools.run(action). Everything else, as he puts it, is orchestration.

2. The outer loop (a system). This is what Osmani, Steinberger, and Cherny are mostly talking about: the system around the agent that discovers work, hands it to an agent, checks the result, records what was done, and decides what to run next — often across many sessions, on a schedule, and frequently unattended. As Osmani frames it, “a loop is a recursive goal: you define a purpose and the AI iterates until complete,” and loop engineering is “replacing yourself as the person who prompts the agent — you design the system that does it instead.”

Loop engineering as a named discipline is mostly about the outer loop, though good practice spans both. Keeping these two senses distinct resolves most of the debates later in this piece — including the question of whether loop engineering sits inside the harness or above it (it depends on which loop you mean).

The Anatomy of a Well-Engineered Loop

Across the most credible writing on the topic (Osmani, Saulius, Kilo, Flux+Form, Mindber), a consistent definition emerges:

Loop engineering is the discipline of designing, operating, and improving the feedback loops that let an AI agent pursue a goal — iterating between action and verification — until the goal is met or control is handed back to a human.

The critical move is that the agent should not answer once; it should use evidence (test results, errors, diffs, logs, reviewer notes) to improve its next step. A working loop has a specific shape:

  1. Goal + discovery. A target outcome is defined, and the system finds the work to do (e.g., open PRs, failing tests, a triage inbox).
  2. Act. The agent takes one concrete step using its tools — edits a file, runs a command, queries an API.
  3. Observe. The system captures ground truth from the environment: did the test pass, did the build break, what changed.
  4. Verify — with an independent checker. A separate context (ideally a separate model instance) grades the output against an explicit rubric. This is widely called the single most important practice: the agent that produced the work must not be the one that grades it, because models are unreliable judges of their own output.
  5. Self-correct. The agent reads the feedback and diagnoses, then adjusts. This is what distinguishes a loop from a retry — a retry repeats; a loop changes its approach based on what it learned.
  6. Persist state. Durable memory outside the context window records why prior attempts were rejected, so the agent doesn’t repeat them. This is the loop’s “spine” that survives any single conversation.
  7. Decide next / stop. The loop ends when the verifier passes — not when the agent believes it is finished — or when a hard bound trips (max iterations, timeout, or cost budget), or a human gate is reached.

A loop is not an automation, and it is not a retry. An automation runs a fixed script (step 1, then 2, then 3) every time. A retry repeats the same action and hopes. A loop inspects the current state, decides what to do next, checks the result, and decides whether to iterate again. As one practitioner put it, “without Reflect, you have a pipeline, not a loop.”

Goal-driven convergence. The sharpest expression of this is the /goal primitive now in both Claude Code and Codex: you give a verifiable stop condition (“all tests in test/auth pass and lint is clean”), and the loop runs itself, checks after each turn whether it is there yet, and stops when the condition holds. A companion /loop primitive re-runs on a cadence. Schedule and events drive the loop from outside; goal lets the loop drive itself to convergence.

Loop hygiene. Because a non-deterministic component sits inside the cycle, engineered loops need guardrails: bounded iterations (commonly 15–25 steps), wall-clock timeouts (~300s is a typical default), cost caps, and loop detection — fingerprinting each iteration’s (tool, result) and halting if the same fingerprint repeats. (Steve Kinney recounts a production system that returned the same answer 58 times before anyone noticed.) A common graceful-degradation pattern: if the iteration cap is hit, inject a final instruction asking the agent to synthesize whatever it has, so the user still gets something useful.

Why Loop Engineering Matters

The leverage shift: operator → architect. The reason senior engineers are excited is not that the work got easier — Cherny’s point is that it got harder and more valuable. Loop design is harder than prompt engineering, not easier; what changed is that the leverage point moved. Instead of steering an agent turn by turn, you build the system that steers it, then let it run. You design once and the system poke-prompts the agents instead of you.

Reliability, cost, and autonomy are won or lost in the loop. A strong loop turns a capable-but-unpredictable model into verified progress: long horizons collapse into a sequence of short, checkable steps, and the observation step keeps the agent grounded in reality instead of its own assumptions. A weak loop — “a retry wrapped in a cron job” — mostly produces, in Saulius’s memorable phrase, “a larger bill.”

The control-theory lineage. The structure (goal → act → observe → reflect → repeat) is a classic closed-loop controller. The twist is that the component inside the loop is a non-deterministic, generalizing model rather than a fixed transfer function. That is the whole trade: more capable and able to handle situations the designer never anticipated, but harder to predict and more expensive to run.

The three debts (the strategic fine print). Osmani and the community catalog of patterns are unusually honest about the downside, and these matter for anyone budgeting or governing this work:

  • Token/compute cost can explode with sub-agents and long-running loops.
  • Verification is still on you. Unattended loops make unattended mistakes; the human moves from doing the work to designing and auditing the checker.
  • Comprehension debt grows faster the better the loop works — if you stop reading what it ships, you lose the plot of your own system. And two people can run the same loop and get opposite results; the loop doesn’t know, but you do.

For product and strategy leaders: the durable advantage is migrating away from “who has the best model” (rapidly commoditizing) toward “who designs the best loops” — meaning verifiable stop conditions, independent verification, and durable memory. That is a systems-and-process moat, not a prompt-library moat. A recent Stanford/SambaNova line of work even treats the agent’s context as an evolving playbook the agent rewrites from its own successes and failures, improving agent benchmarks by ~10.6% with no fine-tuning at all — a signal that the optimization target of this era is the loop and its memory, not the model weights.

The Three Neighbors, Reviewed Against the Loop

Loop engineering is easiest to locate by triangulating it against the three disciplines it grew out of. Each answers a different question, at a different altitude, over a different time horizon.

Prompt engineering — the instruction layer

What it is. The craft of writing and organizing the instructions you give a model for a single interaction — a communication skill, closer to writing a sharp spec or bug report. It was the dominant lever from roughly 2022 to 2024, when most use cases were one-shot generation or classification.

Boundary with the loop. A prompt optimizes one turn; a loop optimizes the trajectory across many turns and sessions. In a well-engineered loop, the prompt doesn’t disappear — it gets demoted to a component the loop assembles and fires (often packaged as a reusable “skill” rather than typed by a human each time). Prompt engineering is the smallest unit of work; loop engineering decides which prompt fires, when, and what to do with the result. As the field puts it: prompting was the keyboard; loop design is the architecture.

Context engineering — the working-memory layer

What it is. Anthropic calls context engineering “the natural progression of prompt engineering”: the set of strategies for curating and maintaining the optimal set of tokens during inference — not just the prompt, but system instructions, tool definitions, retrieved documents, history, tool outputs, and memory. The guiding principle is to find “the smallest set of high-signal tokens that maximize the likelihood of the desired outcome,” because a model has a finite attention budget. Andrej Karpathy’s analogy stuck: the LLM is a CPU and the context window is its RAM; context engineering is the OS deciding what to load. LangChain reduces the practice to four moves — write, select, compress, isolate. The term settled in mid-2025 (endorsed publicly by Tobi Lütke and Karpathy, predicted to stick by Simon Willison).

Boundary with the loop. Context engineering answers “what should the model see on this step?” Loop engineering answers “what step should happen next, who checks it, and when do we stop?” Context is the per-iteration concern; the loop is the across-iteration concern. The two are deeply coupled in one direction: an agent running in a loop is exactly what generates the ever-growing universe of information that context engineering then has to curate. In that sense, context engineering is partly in service of the loop. Their shared seam is durable memory/state — the “write context” move (saving notes outside the window) is also the loop’s spine that survives compaction and session boundaries.

Harness engineering — the runtime layer

What it is. The design of everything around the model — captured in the equation Agent = Model + Harness (Martin Fowler / Birgitta Böckeler). Osmani’s inventory of the harness: system prompts and skill files, tools and MCP servers, sandboxes, hooks/middleware, subagent orchestration, feedback loops, recovery paths, and observability. A useful sub-distinction: scaffolding is what’s assembled before the first prompt (system prompt, tool schemas, subagent registry); the harness is the runtime that dispatches tools, manages context, enforces safety, and persists state. Fowler frames its controls as guides (feedforward — steer before acting) and sensors (feedback — observe and self-correct after acting). The industry is now shipping Harness-as-a-Service: the Claude Agent SDK, Codex SDK, and OpenAI Agents SDK hand you the loop, tools, context management, hooks, and sandbox out of the box.

Boundary with the loop — the central tension. This is where the experts openly disagree, and it is worth stating both readings:

  • “The loop is inside the harness.” The harness contains the inner agent loop — the runtime’s “dumb loop” that calls the model, runs tools, and decides when to stop. On this reading (argued well by Gerald Chen), loop engineering is the single most important sub-discipline of harness engineering — specifically, how the loop itself is designed — not a separate layer.
  • “The loop is above the harness.” Osmani places loop engineering one floor above the harness: he defines the harness narrowly as the environment a single agent runs inside, so the system that runs on a timer, spawns helpers, verifies their output, and feeds itself naturally sits above any one agent’s harness.

Resolution. The disagreement is mostly definitional, and it maps exactly onto the two senses of “loop” from earlier. If “loop” means the inner agent loop, it lives inside the harness. If “loop” means the outer driving system across agents and sessions, it sits above any single harness. Both are coherent. The portable takeaway: loop engineering is the design of the control system that drives agents — whether that control lives in the harness’s stop logic or in an orchestration layer stacked on top of it.

How the Layers Fit Together

The most widely shared mental model is a set of nested layers, each taking the one below as a component:

prompt ⊂ context ⊂ harness ⊂ loop / agentic

A one-line way to hold all four in your head:

  • Prompt = what you say.
  • Context = what the model sees.
  • Harness = what runs the model.
  • Loop = what keeps it going until the goal is verifiably met.

(As noted above, not everyone agrees the loop is its own layer versus a sub-discipline of the harness. Treat the nesting as a teaching aid, not a settled taxonomy.)

Comparison at a glance

Discipline The question it answers Unit of work Time horizon What you optimize Failure it prevents Relation to the loop
Prompt engineering “How do I phrase this?” A single instruction / turn One interaction Wording, structure, examples Vague or ambiguous instructions The smallest component the loop fires
Context engineering “What should the model see now?” The context window, per step Per iteration, within a run Token selection under a finite attention budget Context rot; missing or irrelevant information Keeps each iteration sharp; curates what the loop produces
Harness engineering “What runs the model?” The runtime around the model A session / long-horizon run Tools, sandbox, hooks, recovery, observability Unsafe actions; brittle runtime; lost state Hosts the inner loop; supplies stop, tool, and safety machinery
Loop engineering “What happens next, who checks it, when do we stop?” The control system driving agents Across turns, sessions, and time — often unattended Discovery, verification, self-correction, stop conditions, memory Confident-but-wrong output; no-progress spins; expensive retries The anchor — the system that drives and verifies agents over time

The table makes the through-line visible: as you move down the rows, the time horizon lengthens, the unit of work grows (from a string, to a window, to a runtime, to a self-driving system), and the failure mode being defended against shifts — from “the model misunderstood” to “the system did the wrong thing, confidently, while no one was watching.” Loop engineering is where that last, most expensive class of failure is addressed.

Practical Implications

For builders

  • Make the stop condition verifiable. End on the verifier’s verdict, not the agent’s belief that it’s done. “All tests green and lint clean” beats “looks good to me.”
  • Separate the maker from the checker. Run verification in an independent context, ideally a different model, against an explicit rubric. Self-critique doesn’t count.
  • Persist state outside the window. Record why attempts failed so the agent doesn’t repeat them; this memory is what makes iteration cumulative rather than amnesiac.
  • Bound everything and watch for spins. Iteration caps, timeouts, cost budgets, and loop-detection fingerprints are not optional for unattended runs.
  • Engineer for safety before autonomy. Simon Willison’s guidance on running agents in “YOLO mode” (auto-approve) is blunt: the three risks are destructive commands, data exfiltration, and your machine being used to attack others. Mitigate with a sandbox, tightly scoped credentials, or simply “use someone else’s computer” (a disposable cloud container). Don’t grant broad autonomy to a loop you can’t contain.
  • Pick the right problems. Willison’s heuristic: loops shine on problems with clear success criteria that involve tedious trial-and-error — debugging, performance tuning, dependency upgrades, shrinking container images. A solid, cleanly passing test suite massively amplifies the value, because it gives the loop a fast, trustworthy feedback signal.
  • Start narrow. The honest current state is that loops are already in production for narrow, well-checked tasks; ambition should scale with the quality of your verification.

For product and strategy teams

  • Build-vs-buy is shifting to “buy the harness, build the loop.” With Harness-as-a-Service maturing, the differentiated effort is no longer wiring up tool-calling and conversation state — it’s the domain-specific loop, verification, and memory on top.
  • Invest in verification and durable context as the moat. The defensible asset is the checker and the institutional memory the loop accumulates, not the prompt text.
  • Budget realistically. Plan for token/compute cost, and for the human cost of auditing what loops ship. Measure loops by verified outcomes, not by how many times they ran.
  • Govern unattended writes. Loops that act without a human present need explicit approval gates for sensitive or irreversible actions. Autonomy and guardrails are designed together, not bolted on after.

Where the Idea Is Still Forming

Loop engineering deserves a clear-eyed caveat, because it is genuinely new and the discourse is moving week to week.

  • The term is contested. Some treat it as a real paradigm shift (Saulius: “a genuine shift in how we work with coding agents, not merely a rebranding of automation”). Others argue the inner-loop version is best understood as a sub-discipline of harness engineering that simply got its own name (Gerald Chen). Skeptics worry it risks rebranding ordinary “automation.” All three positions are defensible right now.

  • The failure mode is doing it badly. The community is unanimous on one point: a loop is not “run the agent again on a schedule.” Without independent verification, genuine self-correction, and durable state, you don’t have a loop — you have a more expensive retry. The named failure modes are stuck/no-progress spins, runaway cost, comprehension debt, and divergent results across runs.

  • What’s likely next. The open problems practitioners are most excited about: orchestrating many agents in parallel on a shared codebase; agents that read their own traces to find and fix loop- and harness-level failures; and loops that assemble the right tools and context just-in-time for each task instead of being pre-configured. The trajectory of the whole field has been the unit of engineering climbing the stack — prompt, then context, then harness, then loop — and there’s no obvious reason to expect that climb to stop here.

Bottom line. Loop engineering names the practice of designing the control system that drives an AI agent: it discovers work, acts, checks itself with an independent verifier, remembers why past attempts failed, and stops only when a goal is verifiably met. Prompt, context, and harness engineering are the layers it stands on — the words, the working memory, and the runtime, respectively. The leverage point of building with AI has moved up to the loop. Whether you file it as its own layer or as the most important corner of the harness, the skill it points at is the same, and it is where reliability, cost, and autonomy are now decided.

Checklist

A desk reference for shipping AI agents that work unattended, distilled to the decisions that determine whether a loop earns its name.

Loop Engineering — Builder’s Checklist

References

Grouped by discipline. All sources published December 2024 – June 2026.

Loop engineering (core)

The agent loop (mechanics and lineage)

Context engineering

Harness engineering

Prompt engineering & “what comes next”

AG
AgentCoding
A technical journal on AI security and engineering practice