Lakshya

LLM Systems Engineering · Chapter 19 of 20

Loop engineering

A term about three months old, what it actually names, how it differs from the harness, and why its author's warnings are the most useful part.

9 min read2 diagramsAll 20 chapters

The short answer: you stop being the person who types the next instruction, and you build the thing that decides the next instruction instead.

And a date, because this one needs it more than most. The phrase was coined on 7 June 2026, when Peter Steinberger posted a single line — roughly, that you should no longer be prompting coding agents, you should be designing the loops that prompt them for you. Addy Osmani published an essay giving it an anatomy the following day, and IBM had a page on it within weeks. So it is a real term with real content, and it is about three months old. Treat anything confident about its best practices accordingly.

Where it sits

FOUR FLOORS — EACH ONE WIDENS WHAT YOU ARE DESIGNING PROMPT ENGINEERINGYou design the words in one request.You are in the loop. Every turn waits for you.you write the turnCONTEXT ENGINEERINGYou design what the model can SEE — retrieval, history, tools.Still one turn at a time, but you decide what it knows.you fill the windowHARNESS ENGINEERINGYou design the environment ONE agent runs in — loop, tools, guards, sensors.The agent runs on its own within a task. You start each task.you build the roomLOOP ENGINEERINGYou design what DECIDES THE NEXT TASK — scheduling, spawning, self-feeding.You stop typing the next instruction. Something else does.you build the thing that starts it THEY ARE NOT ALTERNATIVES AND THE LOWER FLOORS DO NOT GO AWAY. A loop still needs a harness; a harness still needs context; context still needs a prompt. You are adding a storey, not moving house.
Each floor widens what you design. The bottom line matters — this is an added storey, not a replacement.

The distinction from harness engineering is clean, and Osmani states it directly: the harness is the environment ONE agent runs in; loop engineering operates one floor above it — scheduling, spawning helpers, and systems that feed themselves work.

Two loops, and conflating them is where the confusion comes from

The inner loop is what the agent chapter builds: send, pick a tool, run it, append, repeat until the task is done. That is ordinary agent design and it has been around as long as agents have.

The outer loop is what the term actually names: what starts the agent, on what schedule, on which task, and what happens to the result — across sessions, without a human initiating each one.

If someone tells you loop engineering is just the ReAct loop, they are describing the inner one and the term is not about that. The novelty is entirely in who decides the next task.

What is actually in one

THE FIVE PARTS — AND THE SIXTH, UNDERNEATH ALL OF THEM AUTOMATIONSScheduled runs thatfind their own work.the thing thatreplaces youWORKTREESIsolated git branches soagents do not collide.parallelism withoutfile conflictsSKILLSConventions and knowledgein files it reads.so it does notrelearn each timeCONNECTORSTools and systems, usuallyover MCP (Model ContextProtocol) — so it canreach real systemsSUB-AGENTSA separate agent thatchecks the first one.verification, notmore throughput 6. EXTERNAL MEMORY — underneath all five. Files, a board, a queue. Without it every run starts from nothing, so the loop repeats work, redoes finished tasks, and never converges. This is the load-bearingone. AND THE PART THE ESSAY IS HONEST ABOUT — WHICH IS THE PART TO ACTUALLY REMEMBER: • Verification is still yours. The loop generates faster. Nothing in it reviews on your behalf. • Comprehension debt accelerates. Code ships that nobody on the team has read, at machine speed. • Cognitive surrender — named as the primary risk. Passively accepting output because checking is now the slow part. Scale the generation ten-fold and human review does not scale at all. That gap IS the discipline. Which is the same constraint the vibe-coding chapter reaches from the other direction.
Five parts, one foundation, and a red box you should read before the other six.

Two of those five are covered in depth elsewhere and are worth naming properly here. Connectors are how the agent reaches real systems, usually over MCP — the Model Context Protocol, a standard way of describing a tool to a model, covered in APIs, webhooks and MCP. Skills are the conventions and project knowledge kept in files the agent reads each session — the CLAUDE.md or AGENTS.md pattern from the prompting chapter.

The sixth is the one that decides whether any of it works. Without external memory — a file, a project board, a queue, anything that survives the session — every run begins from nothing. The loop then re-discovers the same work, redoes finished tasks, and never converges. It is the least glamorous component and it is load-bearing, which is a pattern by now.

And sub-agents earn their place here for one specific reason, which is worth separating from the general multi-agent enthusiasm the agent chapter argues against: they are used for verification — a second agent checking the first one's work — not for parallel throughput. That is one of the two genuinely defensible uses, and it is the one with a purpose beyond looking impressive on an architecture diagram.

Why the warnings are the most useful part

Unusually for a term that spread this fast, the essay that named it leads with its risks. Three, and they compound:

  • Verification is still yours. Nothing in the loop reviews on your behalf. You have automated generation and not judgement.
  • Comprehension debt accelerates. Code ships that nobody on the team has read, at a rate a team cannot absorb — and unlike ordinary technical debt it is invisible until an incident, because the code works.
  • Cognitive surrender — named as the primary risk. Passively accepting output because checking has become the slow, tedious, unrewarded part of the job. This is a human-incentives failure, not a technical one, which is precisely why no amount of tooling addresses it.

The arithmetic that should govern any decision to adopt this.

Loop engineering multiplies generation. It does nothing whatsoever to review capacity.

The vibe-coding chapter reaches the same constraint from the other end: generation got roughly an order of magnitude faster and human review did not get faster at all. Loop engineering takes that gap and widens it deliberately.

So the honest question before building one is not ‘can we automate this’. It is: what is going to check the output, and does that thing scale with the loop or with the number of humans? If the answer is humans, you have built a queue, not a system.

Which is also why the sub-agent-as-verifier component matters more than it first looks: it is the only part of the anatomy that scales checking rather than producing.

When it is genuinely worth it

  • The work is repetitive, well-specified, and machine-checkable. Dependency upgrades, lint and type-error backlogs, test coverage on untested modules, mechanical migrations across many files, triaging inbound issues into a queue. Note what these share: a computational sensor can tell whether the result is correct without a human reading it.
  • You already have the harness. A loop over an unregulated agent just produces unreviewed work faster. If your test suite is weak, build that first — you are not ready for this floor.
  • The work is genuinely bounded. A loop with no definition of done runs until someone notices the bill.
  • And a plain reason not to: if the tasks need judgement, or the output cannot be verified without a person reading it carefully, a loop converts a solvable review problem into an unsolvable one.

How to start, if you are going to

The same shape as everything else on this floor of the site: smallest useful version, with the checking built in from the start rather than added when it hurts.

  • 1. One task type, machine-verifiable. ‘Fix type errors in this package’, not ‘improve the codebase’.
  • 2. External memory from day one — a file or a board recording what has been attempted and what happened. Without it you will not get past the second run.
  • 3. Isolation. A worktree or a branch per run, so a bad run is discarded rather than untangled.
  • 4. A hard stop. Runs per day, tokens per run, a definition of done. The agent chapter's four stop conditions apply to the outer loop too, and matter more there because nobody is watching.
  • 5. A gate that is not you reading everything. Tests must pass, the diff must be under a size, a review sub-agent must approve, irreversible actions still need a human. Decide this before the first run, because it is the component you will be tempted to skip and the one whose absence defines every failure mode above.
  • 6. Then look at what it produced, properly, for the first few weeks. Not to rubber-stamp — to find out what it does badly, so that becomes a rule in the harness. Same iterate-on-repeated-failures discipline as everything else.

The one-sentence version: loop engineering is designing what starts the agent rather than what the agent says — automations, isolation, skills, connectors and a verifying sub-agent, over an external memory that survives the session. It sits one floor above the harness and does not replace it. And its own author's warning is the thing worth carrying: it scales generation and not judgement, so build the checking before you build the loop.

Check yourself

What does loop engineering actually name?Designing the system that decides the next task and starts the agent — the outer loop across sessions — rather than typing the next instruction yourself.
Where did the term come from, and when?Peter Steinberger's post on 7 June 2026, given an anatomy by Addy Osmani's essay the following day. About three months old, so treat confident best-practice claims accordingly.
How does it differ from harness engineering?The harness is the environment one agent runs in. Loop engineering is one floor above — scheduling, spawning helpers, self-feeding work. It adds a storey rather than replacing one.
What are the two loops people conflate?The inner loop (send, pick tool, run, append, repeat) is ordinary agent design. The outer loop — what starts the agent, on what schedule, on which task — is what the term names.
What are the five components?Automations, worktrees, skills, connectors, and sub-agents — with external memory underneath all of them.
Why is external memory load-bearing?Without it every run starts from nothing, so the loop rediscovers the same work, redoes finished tasks and never converges.
What is the primary risk, per the essay that named it?Cognitive surrender — passively accepting output because checking has become the slow, unrewarded part. A human-incentives failure, which is why tooling does not fix it.
What is the arithmetic to apply before adopting it?It multiplies generation and does nothing for review capacity. Ask what checks the output, and whether that thing scales with the loop or with the number of humans.
When is it genuinely worth it?Repetitive, well-specified work a computational sensor can verify without a human reading it — dependency upgrades, type-error backlogs, mechanical migrations — and only once the harness already exists.
← Harness engineeringEnterprise agent platforms →