For a while, ‘prompt engineering’ meant one thing: wording a single instruction as well as you could, reading what came back, judging it, and writing the next one by hand. That is still the craft — but it has grown. The same skill of steering a model through what you feed it now stretches over the environment an agent runs inside, and over whole systems that run many times without you typing each step. Loop engineering is that largest scope. It is not a successor to prompt engineering; it is prompt engineering, zoomed out to the level of a self-running system.

A quick word on terms, because this page leans on the broad reading. By Prompt Engineering we mean the whole craft of getting useful behaviour out of an LLM through everything you give it — not only the wording of one instruction. Under that reading, the newer vocabulary of harness engineering and loop engineering names specialities within the field, not rivals to it — the way Software Engineering comfortably contains both frontend and backend without any of the three stopping being software engineering.

The phrase itself went from a builder-community in-joke to working vocabulary in mid-2026, largely through Addy Osmani’s essay of the same name. This page explains what loop engineering is, how the loop actually turns, the pieces you assemble to build one, and — the part most write-ups skip — where it quietly goes wrong.

What loop engineering actually is

Loop engineering is the practice of designing agentic systems that run in iterative cycles — take an action, observe the result, reason about it, validate that the goal is genuinely met, and repeat — until it is reached, with as little human prompting in between as the task safely allows.

The contrast that matters is with manual, turn-by-turn prompting — not with prompt engineering itself. In turn-by-turn prompting, your judgement runs before and after every model call: you decide what to ask, whether the answer is good enough, and what comes next. In a loop, that judgement is designed into the system. You are no longer writing each instruction by hand; you are writing the machine that writes the instructions, evaluates the output, and decides whether to go around again. As Osmani puts it, you stop doing the work turn by turn and “design the system that does it instead.”

Notice what did not change: it is still prompts driving every step. What moved is where your judgement lives — out of live typing and into designed behaviour. That shift is what separates a chat session from a loop.

Prompt engineering, at three scopes

The clearest way to place harness and loop engineering is not as rungs above prompting, but as the same craft drawn as three nested rings. At the core is the prompt itself — the context, skills and wording that steer a single model call. Wrap that in a loop and you have a cycle that checks its own work: act, observe, reason, validate, repeat. Wrap the loop in a harness and you have the tools, memory, sandbox and guardrails that let that cycle run safely, unattended. Each ring is built out of the one inside it.

So ‘moving out a ring’ is not leaving prompt engineering behind — it is doing more of it at once. A single prompt gives you a great answer. A loop gives you a cycle that keeps checking and retrying until the goal is genuinely met. A harness gives that loop somewhere safe to run — which is exactly why the outermost ring needs the most careful design.

It is tempting to flip the last two rings — to put the loop outside the harness, reasoning that the loop is the ‘bigger’ idea. It reads the wrong way round. The loop is what keeps a piece of work honest — act, observe, reason, validate, repeat — but that cycle still has to run somewhere. The harness is what gives it that somewhere: sandbox, permissions, memory, verification and logging, wrapped around every iteration the loop runs. A loop with no harness around it has nowhere safe to act; a harness with nothing looping inside it just runs once and stops. Security is not a single ring you wrap around everything; each ring guards its own scope, and the harness’s edge is where the system-wide limits live: cost and attempt limits, the validation gate, and a human on the loop. The same holds for verification and observability: the loop already checks its own result at every cycle, while the harness adds the sandboxing and logging that make each of those cycles safe to run unattended.

The loop itself: act, observe, reason, validate, repeat

Strip away the tooling and every loop comes down to the same handful of beats. The agent does something, reads what came back, works out what it means, checks that the result is genuinely correct, and only then decides whether to stop or go again. The textbook version stops at four beats and folds that check into ‘reason’ — but the hidden step is exactly where loops fail, so it is worth pulling into the open as its own beat.

Pulling validate out as its own beat is not pedantry. The most common way a loop fails is declaring victory on broken work — the model grading its own homework. Making the check a distinct step, ideally run by a separate verifier (the subagents piece below), is what stops “the model says it is done” from being mistaken for “it is done.”

The part teams skip most often, though, is the band underneath: observability. It is easy to celebrate a loop that lands a green checkmark and never ask how it got there, how many tokens and dollars it burned, or which step made the call that mattered. A loop you cannot trace is one you cannot debug, cost or trust — and unattended systems are exactly where a quiet, expensive mistake gets to repeat all night. A well-engineered loop records every beat, and always keeps a hard stop for “enough” when validation refuses to pass.

The pieces you assemble

A loop is not one thing you switch on; it is a handful of parts wired together. Osmani’s essay names six, and they map cleanly onto the vocabulary above. Think of the first five as the machinery and the sixth — memory — as the thing that makes the other five stick from one run to the next. Expand each to see what it does and why it earns its place.

A loop, start to finish

Here is how the six pieces click together in one realistic cycle — the kind of overnight maintenance loop teams were building through 2026.

1. The heartbeat fires. A morning automation wakes up and reads yesterday’s failing tests and newly opened issues.
2. Work gets triaged. It calls a triage skill that knows the project’s conventions and sorts findings into “an agent can attempt this” versus “a human should look.”
3. Agents go to work in isolation. For each actionable item it spins up a worktree with a pair of subagents: one drafts a fix, a separate one reviews it.
4. The loop acts in the real world. Connectors open a pull request and update the ticket — not a suggestion in a chat window, an actual change in your systems.
5. Anything uncertain is handed back. Items the verifier is not confident about land in a triage inbox for a person, rather than being shipped on a guess.
6. Progress is written down. A state file — the external memory — records what was done, so tomorrow’s run continues seamlessly instead of re-discovering the same work.

Notice that a person is still very much in this picture — reviewing pull requests, clearing the triage inbox, deciding what “done” means. The loop did not remove the engineer. It removed the typing between steps — and, built well, it left a trace of every one of them, so you can see exactly what it did and what it cost.

It's prompting all the way down

If harness engineering is prompt engineering at the widest scope, with loop engineering as the validating cycle running inside it, this is where you can see the prompts underneath it all. Every act beat of the loop is a model call, and that call is only as good as the instruction behind it. Vague prompts inside a loop do not fail politely once — they fail on a schedule, unattended, and the verifier has to catch every one.

So the clear, well-structured prompting this site teaches is not left behind; it gets distributed through the machinery. A skill file is a prompt you wrote once so you never have to write it again. A verifier subagent is a prompt whose whole job is to be a strict critic. A goal condition is a prompt precise enough that a machine can tell whether it has been met. Frameworks like CRAFTING AI earn their keep here: the more reliably you can specify context, role, action and format, the more of the loop you can trust to run without you.

Which is exactly why this page belongs on a prompt-engineering site. Building a loop does not graduate you out of prompting — it asks you to prompt well in more places at once.

When a loop is worth building

Loops are not free. They cost design effort up front and vigilance forever after, so they earn their place on some tasks and actively get in the way on others.

A loop fits when…

• the work is repetitive and recurring — the same shape of task, over and over;
• “done” can be checked mechanically — tests pass, a schema validates, a metric moves — so a verifier has something real to grade against;
• a mistake is recoverable — caught by review or easily rolled back, not shipped irreversibly to customers or funds;
• the volume genuinely exceeds what a person can prompt by hand.

Reach for a plain prompt instead when...

• the task is one-off — building the loop costs more than doing the work;
• success is a matter of taste or judgement a verifier cannot score;
• an error is expensive or irreversible, and a human must hold each decision;
• you do not yet understand the task well enough to say when it is finished — if you cannot define “done,” the loop cannot either.

Sources and further reading

This page is our own synthesis of an idea that took shape publicly through 2026 — including the argument that loop and harness engineering sit within prompt engineering rather than above it. The anatomy of the loop and its six components leans most directly on Addy Osmani’s essay.

• Addy Osmani, Loop Engineering — addyosmani.com/blog/loop-engineering
• IBM Think, What Is Loop Engineering? — ibm.com/think/topics/loop-engineering
• MindStudio, Loop Engineering vs Prompt Engineering — mindstudio.ai/blog
• Firecrawl, Should You Stop Prompting Agents and Start Designing Loops — firecrawl.dev/blog/loop-engineering