Loop Engineering: The Fourth Layer

Every once in a while a single sentence compresses a shift that has been building for months. On June 7, 2026, Peter Steinberger, the developer behind the OpenClaw agent framework, posted one of those sentences: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." The post tore through the industry in days. Around the same time, Boris Cherny, who leads Claude Code at Anthropic, said in a widely shared interview: "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." Two weeks later, Addy Osmani published the essay that gave the practice its lasting name and structure: loop engineering.

"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

I have been circling this idea all year without having a word for it. When I wrote about how I build software with AI, the uncomfortable observation was that I had become the bottleneck, the person sitting between the agent and the next instruction. When I wrote the 5-gate rule, the core claim was that AI output should never ship without an adversarial check that the author of the output did not control. When I wrote about delta triggers, the whole point was that a change in data, not a human at a keyboard, should be what wakes an agent up. Loop engineering is the name for the discipline that connects those three instincts into one system. So this post is my attempt to do what I try to do with every shift of this size: slow down, take it apart, and figure out what is durable underneath the virality.

First, the definition, because the term is already being stretched to cover everything. Loop engineering is the practice of designing a controlled outer system, the loop, that discovers work, prompts and orchestrates AI agents to do it, verifies the results independently, persists state between runs, and decides whether to stop, retry, or escalate to a human. The human moves out of the loop's hot path and up into its design. You stop being the person who types the next instruction. You become the person who decides what the system reads first, who checks its output, and when it is allowed to stop.

Osmani's essay put it plainly: "Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead." A loop, in this framing, is a recursive goal. The system iterates until the purpose is met or an explicit stop condition is hit. The key word in that sentence is explicit. Everything that separates loop engineering from just running an agent on repeat lives in that word.

What made June 2026 the moment, rather than some earlier month, is that the underlying pieces finally stopped being science projects. The models got reliable enough to survive iteration without wandering off. The agent harnesses grew scheduling, isolated worktrees, skills, connectors, and sub-agents as first-class primitives. And enough practitioners had independently converged on the same architecture that when Steinberger and Cherny said it out loud and Osmani wrote it down, thousands of people recognized a thing they were already half doing.

Like most ideas that look sudden, this one has a prehistory, and it is almost comically humble. In July 2025, Geoffrey Huntley published a technique he named after Ralph Wiggum, the Simpsons character whose defining trait is cheerful persistence in the face of every setback. Ralph, in its entirety, is this:

while :; do
  cat PROMPT.md | claude
done

That is it. An infinite bash loop that feeds a coding agent the same prompt file forever. Each iteration starts with fresh context, so the agent never drowns in its own history. The filesystem and git act as the only memory that survives between iterations. The prompt tells the agent to pick the most important remaining task from a plan file, do exactly one thing, verify it, commit it, and update the plan. Then the loop runs again.

It looks like a joke, and Huntley leaned into that. He also shipped with it. By his own account, Ralph generated six repositories overnight during a Y Combinator hackathon, completed a fifty thousand dollar contract for roughly 297 dollars in API costs, and over three months produced an entire programming language, compiler included. His line about the design is the one worth keeping: "the technique is deterministically bad in an undeterministic world." Ralph does not try to be clever. It tries to be stubborn, and it turns out that stubbornness plus a verifiable goal plus external memory gets you much further than anyone expected. By December 2025, Anthropic had shipped an official Ralph plugin for Claude Code. The joke had become infrastructure.

But Ralph also demonstrated the limits that loop engineering exists to fix. A bare while loop has no discovery, it does what the prompt file says or nothing. It has no independent verification, the same agent grades its own homework. It has no budget, it will happily burn tokens all night on an impossible task. And it has no escalation path, no way to say "a human needs to look at this." Ralph proved the engine worked. Loop engineering is everything you have to build around the engine before you would trust it with anything that matters.

The cleanest way I have found to place loop engineering is as the fourth layer of a stack the industry has been climbing for three years, one layer per year, each layer wrapping the one below it.

Notice the pattern in the failure modes. Each layer exists because the layer below it, done perfectly, still fails in a specific way. A perfect prompt fails without the right context. Perfect context fails without safe tools. A perfectly harnessed single run still fails across runs, because nothing above it decides what to work on next, whether the last run actually succeeded, or when to stop spending money. That cross-run gap is where loop engineering lives.

There is a design principle hiding in the layer boundary that I think is the most important sentence in this entire topic: the outer loop is deliberately more deterministic than the inner work. The agent inside the loop is probabilistic, creative, and fallible. The loop around it is boring on purpose. Fixed validation commands. Hard iteration limits. Budget caps. Named exit paths. Approval gates in front of anything irreversible, a merge, a deploy, a delete, an email that leaves the building. You want the intelligence inside and the control outside. Invert that, put an LLM in charge of deciding when the LLM has done a good job with no hard checks anywhere, and you have built a machine for generating confident failure.

Strip any production loop down and you find the same five-step control sequence, in the same order.

goal
  -> attempt
  -> evidence
  -> decision
  -> stop | retry
     | escalate

A goal that is clear and verifiable. An attempt by the agent. Evidence gathered independently of the agent, tests, lint, builds, logs, a checker's output, never the agent's own claim that it is done. A decision made against that evidence. And one of exactly three outcomes: stop because the goal is met, retry because the budget allows another attempt, or escalate because something exceeded the loop's authority. The step people skip is evidence. An agent reporting "all tests pass" is an assertion. A CI runner exiting zero is evidence. Loops that conflate the two are the ones that ship confident garbage, which is the same reason my 5-gate rule insists the reviewing model must not be the authoring model.

When I evaluate any loop design now, mine or anyone else's, I ask five questions in order:

• Discovery: what does the loop read first? A queue of CI failures, an issue tracker, an alert stream, a plan file. If the answer is "whatever the prompt says," you have Ralph, not a loop.
• Handoff: who or what receives the work? One agent, a fleet in isolated worktrees, a specific sub-agent per task type.
• Verification: who checks the result? If the answer contains the phrase "the agent confirms," start over.
• Persistence: what gets saved for next time? Models forget everything. The loop must not. State lives in files, tickets, and commits, outside any single context window.
• Scheduling: when does it run again, and when does it stop? A loop without an explicit stop condition is not automation, it is a liability with a cron entry.

Osmani's essay identified five building blocks, plus a sixth that everyone who runs loops learns the hard way. What is striking is how quickly all six became native features of the major agent tools rather than things you assemble yourself.

One. Automations and scheduling. The heartbeat. Something has to discover and triage work on a cadence, failed CI runs, open issues, alerts, backlog items, without a human kicking it off. This is the piece that actually removes you from the hot path. My delta trigger post was really about this block before I had the vocabulary: the insight that a change in the world, not a human's attention, should be the event that starts work.

Two. Worktrees. Isolated filesystem branches so parallel agents cannot collide. Unglamorous, essential. The moment you run two agents against one checkout you understand why.

Three. Skills. Codified project knowledge, conventions, build steps, past decisions, usually markdown files the agent loads on demand, so each fresh-context iteration does not re-derive intent from scratch. Skills are how a loop's tenth run benefits from what its first run learned.

Four. Plugins and connectors. Reach into the real world via MCP or equivalent: the issue tracker, Slack, the staging environment, the APIs. A loop that cannot touch the systems where work actually lives can only ever be a demo.

Five. Sub-agents, especially the maker and checker split. One agent produces. A separate agent, often prompted to be openly skeptical, or a hard-coded gate that is not a model at all, verifies. Models are demonstrably poor at grading their own work, and the failure is not random, it is biased toward approval. Separating authorship from judgment is the single highest-leverage structural decision in the whole architecture.

Six. Durable external memory. Plan files, progress notes, tickets, boards. Ralph's deepest insight, dressed up: the filesystem remembers so the model does not have to. Every serious loop treats the model as stateless compute and keeps all state where the next iteration, or a human at 2am, can read it.

The patterns showing up repeatedly in real deployments are not exotic. They are the boring, high-frequency work every team carries:

• CI and flaky-test repair. Detect the failure, reproduce it in an isolated worktree, have an agent propose a scoped fix, require an independent checker plus the full test suite to pass, stop or escalate after a bounded number of retries. This is the canonical loop because the rejection signal is nearly perfect.
• The daily triage sweeper. A scheduled run that reads overnight issues, CI noise, and stale PRs, prioritizes them, handles the mechanical ones, and leaves a human-readable summary of the rest. It replaces the first ninety minutes of reactive work with a briefing.
• Ticket-to-PR. A well-specified ticket triggers investigation, a draft implementation, tests, and a PR. The human reviews for intent and design, not line by line. The quality of the loop is capped by the quality of the ticket, which has the healthy side effect of forcing better tickets.
• Vulnerability and incident response. An alert triggers investigation and a draft remediation, and then the loop stops, deliberately, at a human judgment gate. Nobody sane lets the loop merge a security fix unattended.
• Overnight feature work. Multi-hour runs against a clear, machine-checkable specification. This is Ralph's direct descendant, now with budgets, checkers, and exits.

Read that list again and notice what is common: every item repeats often, every item has an objective rejection signal, and every item has a bounded blast radius. That is not an accident, and it previews the critique section below. Leading teams are now wiring these individual loops into larger chains, the standing "agentic SDLC" workflows some people call software factories, where the middle of the work flows through loops and humans hold the two ends, deciding what is worth building and judging whether what was built is right. When I wrote about rebuilding a team one agent at a time, this is the operating model I was groping toward.

Here is the Stratechery-shaped question: when a capability gets cheap, where does the value go? Ben Thompson's conservation of attractive profits says that when one layer of a stack commoditizes, value migrates to an adjacent layer that is still scarce. Code generation is commoditizing at a rate that still surprises me month over month. What is not commoditizing is knowing whether the generated thing is correct, safe, and worth shipping. Verification is the new scarce layer, and loop engineering is, at bottom, the discipline of industrializing verification. The generation step is almost incidental.

The historical rhyme I keep coming back to is not the assembly line, it is Toyota. The lesson of the Toyota Production System was never "automate everything." It was jidoka, automation with a human touch: machines run autonomously and are designed to stop the moment something abnormal happens, pulling a human in. The andon cord is an escalation gate. The loop that stops and asks is not a weaker loop, it is the entire point. Sixty years of manufacturing history says the teams that win are not the ones with the most automation, they are the ones whose automation knows when to stop.

The economics also explain the shift in what the human is paid for. Hand-cranking prompts is piecework. Designing a loop is capital formation: you build an asset that produces without your attention, and traces from every run become raw material for improving the loop itself. The leverage compounds. But so does the cost of a bad design, which is why the honest accounting has to include the failure modes.

The practitioners worth listening to are blunt that loops only pay under narrow conditions, and all four must hold at once:

• The task repeats often enough to amortize the loop's construction cost.
• There is a reliable, machine-checkable rejection signal: tests, builds, linters, type checks.
• The budget can absorb failed iterations, because there will be failed iterations.
• The agent has the tools and environment to actually investigate, logs, reproduction, access.

Remove any one and the loop produces expensive noise. And the documented failure modes are not hypothetical. Token blowouts, because loop usage is wildly variable and can dwarf interactive use, a lesson anyone who has felt token anxiety already knows in their body. Metric gaming, the agent that deletes a failing test to make CI green, which is not malice, it is a system optimizing the signal you gave it instead of the outcome you meant. Stale memory that quietly poisons every subsequent run. Comprehension debt, shipping code the team no longer fully understands, accruing interest invisibly until the first serious incident presents the bill. And the one I find most corrosive because it is the least visible: cognitive surrender, the slow slide from supervising outputs to accepting them. I wrote about the ceiling this puts on a one-person operation in the limits of the personal engineering org, and loops raise that ceiling without removing it.

Osmani's closing warning is the right one and deserves quoting exactly: "Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go." A loop amplifies the judgment of its designer. It does not replace it. Amplified good judgment is leverage. Amplified absent judgment is just noise at scale, delivered faster and with an invoice.

The role shift is the real story, and it is bigger than tooling. Two years ago the scarce skill was writing a good prompt. A year ago it was assembling good context. Now it is designing a control system: choosing what the loop reads, who checks its work, what survives between runs, and where the hard stops live. That is not a prompt writer's job description. It is a systems engineer's, and honestly, it is closer to what managing well has always looked like. Clear goals, independent verification, bounded autonomy, escalation paths. The people already discussing the next abstraction, graphs of interdependent loops, fleets that design loops, are extrapolating a real trajectory, but the fundamentals will not change when the topology does.

My own summary after a month of sitting with this: loop engineering is the disciplined engineering of the outer control cycle around capable but fallible agents. When the goal is clear, the verification is objective, the budget is enforced, and a human owns the design and every irreversible decision, it is the most leverage per hour of engineering effort I have seen in my career. When those conditions are missing, it is an expensive while loop wearing a discipline's name.

The while loop was never the hard part. Huntley proved a single line of bash could carry an astonishing load. The hard part is everything the bash does not say: what is worth doing, what counts as done, and who answers when the machine is not sure. Those were always the engineer's questions. The loop just makes it obvious that they were the job all along.