Loop engineering: three speeds, one machine

Every few months, AI engineering gets a new term, and the reasonable reaction is fatigue. Loop engineering, the newest one, deserves a closer look anyway — partly because of who’s using it seriously, and partly because it names something real that serious delivery systems have been doing all along.

First, the ladder that got us here, briefly. Prompt engineering was the craft of the single instruction — everything the model knew about your task fit in what you typed. Context engineering was the craft of the workspace — systems that fill the model’s window with the right information instead of hoping you typed it. Harness engineering was the craft of the machinery — tools, state, guardrails, and the loop that turns a model into a worker. (Our Anatomy Series walks each rung in plain English.) Each new discipline contained the previous ones; none of them retired. Under every impressive agent system today there is still, at the very center, a carefully written prompt.

Loop engineering is the next rung, and its history is unusually easy to date. In June 2026, Boris Cherny — the creator of Claude Code — described his work as no longer prompting the agent but writing loops that prompt the agent: systems that read his task queues, decide what to do, and run. Peter Steinberger made the same argument in the same weeks. Addy Osmani gave the practice its name and its anatomy. And Andrew Ng formalized the model most people now use: not one loop, but three, nested by timescale. Within the month, both major AI labs had published official documentation on designing agent loops: Anthropic on goal-based, time-based, and proactive loops, and OpenAI on the Codex agent loop. Terms usually chase practice; this one caught up to it in about three weeks.

The three loops

Ng’s framing is worth restating plainly, because it’s the clearest map of AI-assisted delivery anyone has drawn.

The agentic coding loop runs in minutes. Given a spec, an agent writes code, tests its own work, and iterates until the work meets the bar — with no human in the middle. This loop closing on its own is the genuine breakthrough of the past year.

The developer feedback loop runs in hours. A human reviews what got built and steers: updates the spec, catches what only a human would catch, decides what the product should even be. Ng’s argument for why this loop stays human is the best sentence in the whole discussion: humans have a context advantage — we know things about our users, our taste, and our situation that the system doesn’t have access to.

The external feedback loop runs over days to weeks. Real users, real behavior, real signal — feeding back into the vision, which reshapes the spec, which is what the fast loop iterates against next time.

Each loop feeds the one below it. That’s the machine.

The part most discussions skip: the verifier

Here’s the uncomfortable question inside the fast loop: when the agent “tests its own work and iterates until it’s done” — done according to what?

If the answer is “according to the agent’s own judgment,” you don’t have a loop; you have a spiral. A generator that grades its own homework will happily converge on confident, wrong, and finished. The community learned this fast — the emerging consensus in loop-engineering practice is that the verifier, not the model, is the bottleneck: the model produces cheaply and endlessly, so the thing that decides whether all that motion produced value is whatever judges the work. A loop without a reliable “no” is just a very fast way to spend tokens.

Which means the real engineering in loop engineering isn’t the trigger or the retry logic. It’s the verifier: an explicit, external definition of done that the loop iterates against and cannot overrule. This should sound familiar to readers of this blog — it’s the argument we’ve been making since our first Field Paper, wearing a new name.

The map onto Cortex

Now the honest bit of positioning, and the reason this piece exists. When we designed Cortex, nobody called these things loops. We called it a delivery path. But lay Ng’s three loops over how we deliver and the machine is the same machine:

The fast loop is a Mission. Agents build and iterate inside the determinism boundary — and the verifier is the validation contract: the explicit definition of done, written before the loop starts, checked with evidence the loop can’t argue with. When a check fails, the loop repairs and re-validates. The agent never grades its own homework; that was the founding decision.

The middle loop is the two human gates. Scope & Plan is where the human writes the spec the fast loop will iterate against — nothing gets built until the plan is approved. Review & Ship is where a human examines the diff with the evidence attached and makes the call. This is Ng’s context advantage, made structural: the judgment that knows your users, your risk, and your situation sits at the gates, not inside the loop pretending to supervise every iteration.

The slow loop is Operate & Continue. Production feedback becomes the next cycle’s Missions — and because Cortex retains what it learns about your codebase and standards, each turn of the slow loop starts further ahead than the last. The loops don’t just nest; they compound.

Three loops, three speeds, one machine. The vocabulary is new. The architecture isn’t.

Who holds the wheel

The frontier of loop engineering is the ignition question: loops where the agent prompts itself — scheduled runs, queue-driven runs, systems that find their own work. That’s genuinely powerful for the right jobs, and it’s where the field is heading.

Our position is unfashionable and deliberate: in Cortex, the fast loop drives itself inside its boundary — but starting a Mission and passing the two gates stays human, by design. For serious software — the kind where a mistake is a financial event, a compliance breach, or a 3 a.m. incident — the top two loops aren’t a limitation waiting for automation to remove. They’re the product. The teams that win with loop engineering won’t be the ones that automate the most loops. They’ll be the ones that put the verifier and the wheel in exactly the right places.

Questions this paper answers

What is loop engineering? The discipline of designing the system that drives an AI agent — what triggers it, what verifies its output, when it retries, and when it stops — instead of a human prompting turn by turn. It builds on prompt, context, and harness engineering without replacing any of them.

What are the three loops in AI-assisted development? The agentic coding loop (an agent writes, tests, and iterates in minutes), the developer feedback loop (a human reviews and steers over hours), and the external feedback loop (real users provide signal over weeks). Each loop feeds the one below it.

Does loop engineering remove humans from software development? No — it relocates them. The fast loop runs itself; the loops above it stay human because humans hold context the system doesn’t: knowledge of users, taste, risk, and situation. The design question is where to place the human hand, not whether to remove it.

Why is the verifier the most important part of an agent loop? Because generation is cheap and endless — the loop’s value is decided by whatever judges the work. Without an external, explicit definition of done, a self-checking loop converges on confident, wrong, and finished. The verifier is the engineering.