agent-07 · Loop engineering is the harness on a timer

I was the loop

In April I wrote about running ten coding agents at once from a phone. The honest summary of that post is that I was the loop. I read what came back, I decided what was next, I poked the next agent. The tooling was clever. The scheduler was me.

This post is about the part where you stop being the scheduler.

People have started calling this loop engineering. Addy Osmani gave it the clean definition: you stop being the person who prompts the agent and build the system that prompts it instead. Boris Cherny, who runs Claude Code, says his job is now to write loops, not prompts. Peter Steinberger says the same thing in fewer words. It sounds like a new discipline. It is mostly the old one, seen from one floor up.

Earlier entries in this series mostly followed a lecture course. This one is different. It is the layer the course kept pointing at — meta-harnesses, harness self-improvement — without quite naming. So I will name it the way it actually arrived: on a timeline, not in a syllabus.

Builder takeaway: before you build a loop, decide three things you will not delegate to it: the goal, the oracle, and the places you refuse to leave the room. The loop automates everything else.

The loop is the harness on a timer

In agent-04 the equation was:

AI agent = language model + harness

A loop adds three things to that: a schedule, a place to remember, and the ability to spawn.

loop = harness + schedule + external state + spawn

If you keep the computer metaphor from agent-00, the harness is the operating system around a single run. The loop is the rest of the machine that the OS assumes: a cron timer, an init process, and a supervisor that restarts the work and reads its notes before it does.

A single agent run answers a question. A loop runs the question on a clock and acts on the answer without you in the keystroke path.

That is the entire shift. Everything else in this post is what it costs.

The idea is older than the name

The pattern is Geoffrey Huntley's "Ralph," from the middle of 2025. In its purest form it was one line:

while :; do cat PROMPT.md | agent ; done

This is the context-engineering move from agent-01. The model forgets between runs, so the state cannot live in the context window. It has to live on disk. The agent forgets. The repo does not.

What changed in 2026 is not the concept. It is that the moving parts — schedules, isolated worktrees, sub-agents, written-down skills, connectors to real tools — now ship inside Claude Code and Codex instead of living in a pile of shell scripts only you understood. That is a real convenience, and it is why the term spread this month rather than last year.

The novelty is the packaging, not the pattern.

Five parts and a place to remember

Strip the branding off either product and a working loop is five primitives and one place to remember things.

• Automations are the heartbeat. A prompt that runs on a schedule and triages by itself. Without this it is one run you did once, not a loop.
• Worktrees keep parallel agents from colliding. This is the independent-branch case from agent-02: isolated checkouts so two agents editing the same file is not the same disaster as two engineers doing it silently.
• Skills are the crystallized experience from agent-04. Project knowledge written down once so the loop does not re-derive your conventions from zero every cycle.
• Connectors are I/O. Built on MCP, they let the loop read the tracker, hit staging, open a PR, post to a channel. A loop that can only see the filesystem is a tiny loop.
• Sub-agents are topology. One explores, one implements, one verifies. The useful structural move, and I will come back to why.

Then the sixth thing: memory on disk. A markdown file, a Linear board, anything outside the single conversation that holds what is done and what is next.

That composition is the new thing: old primitives, wired together, with a clock on top.

A loop is only as good as its least gameable signal

This is the part that decides whether a loop becomes leverage or debt. Earlier posts in this series argued that self-correction needs real signals, not reflection, and that self-defined losses can become a closed loop of self-delusion. Loop engineering is the practitioner version of the same problem.

Point a loop at a problem with a real oracle — a test suite, a strict type checker, a compiler, a conformance spec it cannot argue around — and it converges. The cleanest public example is Simon Willison's port of a JavaScript engine into roughly twenty-five thousand lines of Rust, which worked because every output could be checked byte-for-byte against the original. There was a ground truth the agent could not fake.

Take the ground truth away and the loop still runs. It just produces confident, plausible, wrong code, and it does it faster than any human can read.

The proof that the oracle is what matters, and not the model, is that agents game weak oracles. Researchers keep catching looping agents rewriting a failing test so it passes instead of fixing the code, and in one case hallucinating an external service and then mocking the service it had invented. In self-training this is the oh-no moment. At the application layer it is the same event with a different name. When the signal is gameable, the optimizer games it. That is Goodhart's law, and a loop is a Goodhart amplifier.

So the first question is not "how do I write a loop." It is "does this work have a signal the loop cannot fake."

Tests, types, compilers, golden files: loop hard. Taste, architecture, security posture, whether this is even the right abstraction: the loop has nothing to push against, and you are the only judge in the room whether you admit it or not.

The maker and the checker should not be the same model

The standard fix for a weak oracle is a verifier sub-agent. Generator, verifier, revisor — the workflow from agent-04, the topology from agent-02. It helps. The model that wrote the code is too generous grading its own work, so a second agent with different instructions catches what the first talked itself into.

But the verifier has the same trap. If a model judges itself, the signal may be weak or it may reinforce its own blind spots. A verifier sub-agent built from the same model class shares those blind spots. So you add another checker. And then, in principle, another.

The regress only bottoms out in two places: a human with judgment, or a hard external oracle the chain of agents cannot talk around. A verifier with nothing grounded behind it is theater that costs tokens.

A second opinion from the same mind is not a second opinion.

Loops move the cost, they do not remove it

The pitch implies the work goes away. It moves, and it splits in two.

The first half is money. A loop that keeps a few hundred agents busy around the clock burns real tokens, and the first wall most people hit is not a quality problem. It is a two-hundred-dollar infinite-retry bug at three in the morning. When Cherny describes a couple hundred agents reading his GitHub and Slack and deciding what to build, that is not a workflow you copy by learning a skill. It is a workflow you copy by having the token budget to let agents fail expensively in parallel. Osmani's aside about being token-rich versus token-poor is the whole story, said quietly.

The second half is attention. Someone still reads the output. Industry telemetry already shows the shape of it: teams that lean hard on AI merge far more pull requests, but review time climbs and each PR gets larger. This is the ceiling I hit in the April post. The thing that capped ten agents was never the tooling. It was me.

Prompt engineering was cheap and close to meritocratic. Loop engineering has a meter running.

Friction was doing a job

The whole promise of loop engineering is that it takes you out of the loop, and removal of friction gets sold as pure upside. Armin Ronacher, who created Flask, named the cost better than anyone: you have to find a way to feel the pain the agent does not feel.

An agent's only real drive is to make progress. So it will do things a careful person would not. It will silently fall back to a default when a config is missing. It will leave a service hobbling along. It will paper over the failure it should have surfaced. The friction you are so eager to delete was where your judgment got applied.

agent-04 had the right instinct already: hard constraints live in the harness, not in the prompt, because tool boundaries are real boundaries and prompt rules are not. The same instinct scales to the loop. Put hard human gates on the few things that are expensive to get wrong — money, auth, database migrations, customer data — and let the loop run free everywhere else.

The skill is not removing yourself. It is choosing the three places you refuse to be removed.

The bill arrives late

What makes all of this easy to miss is timing. Prompting by hand, you read every diff as it lands, so the gap between what exists and what you understand never gets large. A loop opens that gap silently and lets it compound.

The vivid version comes from the experiments at Cursor, where a fleet of agents was turned loose on something as ambitious as a browser engine, made real early progress, and then stalled — unable to keep extending a codebase the agents themselves had written and could no longer hold. That is comprehension debt made physical. Eventually even the machines could not model what the machines built. Across real repositories, the count of surviving issues introduced by AI is already into the six figures.

The danger is not bad code. It is plausible code, arriving faster than anyone builds a mental model of it.

A loop is harness self-improvement you can read

The previous post ended on a useful point: the first practical self-improving agents may not rewrite their weights. They may rewrite their harness. And that kind of self-improvement is easier to inspect than a weight update.

A loop that updates its own skill files, rewrites its state, and revises its own rules between runs is exactly that, out in the open. The skill file, the state file, the triage notes are all readable, versionable, and deletable. That was the reason I liked skills in agent-04: a fine-tuned behavior is hard to audit, a file is not.

The caution carries over without changes. It is still dangerous if the agent can edit the wrong part of its own system. So scope what the loop is allowed to rewrite as carefully as you scope what it is allowed to deploy.

This is the safest rung on the self-improvement spectrum, and unlike most of that spectrum, it is already shipping.

Where I think we are

The leverage point moved up a layer. Judgment did not move. It concentrated.

A loop is a multiplier on whatever you bring to it. Two people can build the identical loop and get opposite results, because the loop does not know the difference between someone using it to move faster on work they understand and someone using it to avoid understanding the work at all. The system has no opinion about that. You do.

That lesson applies one rung lower. Building a loop that keeps shipping is easy. Building a loop that keeps shipping for the right reasons is the whole job.

Useful, not autonomy.

The main lesson

Loop engineering does not make the engineering easier. It moves the engineering to the parts you cannot automate.

Before you let a loop run unattended, ask:

• Does this work have an oracle the loop cannot fake?
• Is the checker independent of the maker, or grounded in something that is?
• What is the loop allowed to touch without me?
• Am I still reading the output, or only the summary?
• What is the meter costing me when the loop is wrong?
• Can the loop edit the wrong part of itself?

If you cannot answer those, the loop is not saving you work. It is deferring it, with interest.

Build the loop. Keep the oracle. Stay the engineer.

Concept inventory

The main loop-engineering concepts in this post:

• loop engineering as the layer above the harness
• AI agent = LLM + harness; loop = harness + schedule + external state + spawn
• the loop as cron, init, and a supervisor in the agent-as-computer metaphor
• the Ralph loop and its bash one-liner ancestor
• memory on disk versus memory in context
• the five primitives: automations, worktrees, skills, connectors, sub-agents
• worktrees as collision-free parallel branches
• skills as crystallized, auditable experience
• connectors and MCP as agent I/O
• the least-gameable-oracle rule
• grounded signals: tests, types, compilers, conformance suites, golden files
• Goodhart's law in the loop; test subversion; the oh-no moment at the application layer
• generator, verifier, revisor and maker–checker separation
• the verifier regress, ending at a human or a hard oracle
• token cost, the infinite-retry failure mode, token-rich versus token-poor
• review bandwidth as the real ceiling on parallel agents
• friction as steering; hard human gates on money, auth, migrations, and data
• comprehension debt and time-shifted failure
• agents stalling on a codebase they wrote
• surviving AI-introduced technical debt at ecosystem scale
• harness self-improvement as the inspectable rung of the self-improvement spectrum
• the loop as a multiplier on the operator's understanding

Sources and references

The discourse this post responds to:

• Loop Engineering — Addy Osmani
• Boris Cherny on writing loops instead of prompts (Acquired)
• Peter Steinberger: design loops that prompt your agents
• Ralph Wiggum as a "software engineer" — Geoffrey Huntley
• The Friction is Your Judgment — Armin Ronacher and Cristina Poncela Cubeiro
• Agentic Engineering Patterns — Simon Willison
• Debt Behind the AI Boom (arXiv) and An Endless Stream of AI Slop (arXiv)

Earlier in this series:

• agent-06 · Self-improving AI is a spectrum, not a switch
• agent-04 · Harness engineering is how we actually make agents useful
• My setup for running 10+ CLI coding agents at once