How does loop engineering relate to prompt engineering and context engineering?

It's an evolution chain: prompt engineering polishes a single instruction; context engineering manages what the model sees in one session; harness engineering builds the environment a single agent runs in (tools, sandboxes, compaction); loop engineering designs a system that prompts the agent, verifies the output, and decides what's next. Each layer builds on the one below, and the top layer optimizes away the person giving the instructions.

What's the difference between Goal and a long-running agent?

Goal is a product primitive: one persistent instruction with a verifiable stopping condition — /goal in Codex and Claude Code, Background Agents in Cursor — where the agent itself evaluates whether the work is done and picks the next step. A long-running agent is the harness-level implementation: the engineering that lets a task run across sessions for hours or days — checkpoints, recovery, out-of-session memory. One is the interface users see; the other is the implementation behind it. Both stand on the same loop skeleton.

Why is a simpler loop better?

The longer the instruction, the more room for the model to misinterpret it — and in a loop, misinterpretation compounds instead of happening once. The same misunderstanding executes on every iteration, so one night of running turns it into systematic drift. So write loops like a handover doc for a 24/7 colleague: a workflow explained in three sentences beats one explained in ten. Put the complexity into verification — tests, types, screenshots — not into the prose you hand the agent.

What does it take to build a good loop?

Three things. First, get your existing workflow straight — a loop only amplifies it. Second, understand the agent harness: context degrades, compaction silently drops information, and isolation has to be designed, so you can decide what enters the context each iteration. Third, design out-of-session memory (progress files, git history, task lists), or the loop either forgets and redoes work, or drifts further off course while feeling productive.

I Dug Into Loop Engineering: A Loop Is Your Existing Workflow Handed to an Agent — and the Simpler, the Better

TLDR: Loop engineering is this year's new discipline: instead of prompting the agent yourself, you design a system that prompts the agent, checks the output, and decides whether to continue. Huntley's Ralph loop, Anthropic's harness experiments, OpenAI's 25-hour run, and Addy Osmani's write-ups are all about this one thing. After comparing Goal and long-running agents, here's my take: a loop is, in essence, agent automation of a workflow that already exists. If your past workflow was never organized, if you don't understand the agent harness, or if you can't design memory outside the session — any one of those fails, and the loop fails. And one counterintuitive conclusion: the simpler the loop, the better — like writing a handover doc for a 24/7 colleague, where three sentences beat ten.

What is loop engineering, anyway

The terminology in this space keeps adding floors. Prompt engineering taught you to write one instruction well. Context engineering taught you to manage what the model sees in a session. Harness engineering taught you to build the environment a single agent runs in — tools, sandboxes, context compaction. This year added the top floor: loop engineering, designing a system that prompts the agent, verifies the output, and decides the next step, instead of you doing it.

One sentence: prompt engineering optimizes the instruction; loop engineering optimizes away the person giving it.

The origin is Geoffrey Huntley's "Ralph Wiggum as a software engineer" from July last year. The core code is one line (source):

while :; do cat PROMPT.md | claude-code ; done

A coding agent runs the same prompt in a bash infinite loop, each iteration with a fresh context window; tests and linters act as the referee, and it keeps going until they pass. He named it after the dumbest character in The Simpsons and joked the whole thing is "deterministically bad in an undeterministic world" — the flaws are known, and all fixable by prompting. He delivered a $50,000 contract this way, with $297 of agent spend.

This June, Addy Osmani gave it a proper name, with a refreshingly blunt definition: "Loop engineering is replacing yourself as the person who prompts the agent." (post) Boris Cherny, who leads Claude Code at Anthropic, put it harder: "I don't prompt Claude anymore... My job is to write loops." IBM put up a topic page too: building systems that "iteratively guide AI agents toward completing user-defined goals" — each cycle running Goal, Action, Observation, Adjustment.

These primitives now ship inside the products: Claude Code has /loop, /goal, cron scheduled tasks, and hooks; Codex has Automations and /goal. When a pattern goes from bash script to product feature, it's not a geek toy anymore.

What the big players are saying

Anthropic: if the agent can't go the distance, fix the harness. In late November last year they published "Effective harnesses for long-running agents", defining the harness as the scaffolding wrapped around the model: tools, prompts, context management. They compared a long task's sessions to "a project staffed by engineers working in shifts" — "each new session begins with no memory of what came before," and nobody hands anything over. Two recurring failures: overreach, where the agent tries to one-shot the whole app, exhausts context, and leaves undocumented half-work; and premature completion, where a later session sees existing progress and declares the job done. The fixes are all plain engineering: an initializer agent generates a feature list of 200+ items, each with "passes": false, flipped to true only after end-to-end verification; progress goes into claude-progress.txt; every session ends with a git commit as a checkpoint. And one iron rule: "It is unacceptable to remove or edit tests." The line that stuck with me most: "Inspiration for these practices came from knowing what effective software engineers do every day." Everything in the loop is an old engineer's daily habit — nothing in it is a new invention.

Worth remembering: back in December 2024, Anthropic's own "Building Effective Agents" advised everyone to "start with the simplest solution possible" — use workflows, not agents, unless you must. Less than two years later, their product lead says he doesn't prompt anymore. The wind turned fast.

OpenAI: run it for 25 hours straight. They ran long tasks with GPT-5.3-Codex-Maximized — one run went about 25 hours uninterrupted, roughly 13 million tokens, about 30,000 lines of code (retrospective). Their conclusion is a little counterintuitive: what determined success wasn't the model's one-shot intelligence but the loop itself — and "the most important technique" in the whole system is durable project memory: prompt.md for the objective, plan.md for milestones, implement.md as the runbook, documentation.md as the status log, updated every iteration, carrying the task across sessions. Their framing: agentic coding is increasingly a competition over time horizon, not one-shot intelligence — and METR measures the length of tasks agents handle reliably as doubling roughly every seven months.

IBM: the textbook definition. A four-stage cycle, plus two caveats: goals need "clear and verifiable stopping criteria" (or the token bill burns through), and humans stay in the loop for "quality, security and business outcomes." Corporate-flavored caution, but correct: the loop can be automated; the responsibility can't be outsourced.

The skeptic, Ronacher: proceed carefully. Armin Ronacher (of Flask) wrote "The Coming Loop" this June. He draws a fine distinction: the agent loop inside a session (call a tool, read the result, call another) has existed for a while — the new thing is the harness-level loop: "The task stays alive beyond the point where the model by itself would normally have said: 'I am done.'" His discomfort is specific: today's models write code that is "too defensive, too complex, too local in its reasoning" — terrified of exceptions (he cites Karpathy's phrasing), stacking fallbacks, avoiding strong invariants — and looping amplifies exactly this tendency: "If each iteration adds another small defense, the system slowly becomes less understandable while appearing more robust." He lists where loops genuinely work: porting, performance exploration, security scanning, research — all cases of transforming existing code or producing short-lived artifacts. His conclusion isn't refusal — "the question is not whether we will loop" — the question is how to keep human judgment inside the loop.

Goal vs long-running agents: an interface and its implementation

Any loop discussion this year runs into two terms, often used interchangeably. Pulled apart:

Goal is a product primitive. Codex and Claude Code both have /goal; Cursor's counterpart is Background Agents. It boils down to one thing: a persistent instruction with a stopping condition, where the agent itself evaluates "am I done?" and picks the next step, and you stop re-stating the context every turn.
Long-running agent is the other layer: the harness engineering that lets a task run across sessions and sandboxes for hours to days — checkpoints, failure recovery, out-of-session memory, isolated worktrees.

	Goal (/goal)	Long-running agent
What it is	One persistent instruction	An execution system across sessions
Where the loop lives	Product-built primitive, hosted by the product	Harness layer: sandboxes, worktrees, checkpoints
Where state lives	The product tracks goal state	The filesystem: progress files, plans, git
Stopping	Verifiable completion criteria	Verification: tests, E2E, screenshots
Human's role	Occasionally check status, pause/resume	Review diffs, manage memory, prevent drift
Typical failure	Declaring done too early	Overreach, accumulating defensive code
Examples	Codex /goal, Claude Code /goal, Cursor Background Agents	Anthropic's harness experiments, homegrown loops

After all the comparing, my conclusion: these two aren't competitors. Goal is the interface the user sees; long-running is the implementation behind it — both stand on the same loop skeleton. What actually separates good from bad isn't which term you pick, but the quality of the skeleton itself — which is the next section.

My take: a loop is agent automation of an existing workflow

A loop doesn't invent a new process out of thin air. It takes a workflow that already exists and hands it to an agent to run 24/7. Look at everyone's practice: Ralph is spec-first — write the spec, then start the loop. Anthropic runs an initializer agent first to generate the feature list. OpenAI's loop revolves around prompt.md and plan.md. It's all the same move: externalize the workflow from your head into files first, then let the loop consume it.

Aerial view of a conveyor line: a loop automates the pipeline that was already there, not the inspiration

Hence three ways to fail:

If the existing workflow was never organized, the loop will be bad. If you can't articulate how this work gets done day to day and what the judgment calls are, you can't write it as a loop an agent can execute. A loop is an amplifier: a clear process gets 10x speed; a messy process gets its mess amplified 10x, and it never clocks out. A loop without a process is a hallucination with a cron job attached.
If you don't understand the agent harness, the loop will be bad. The loop runs on top of a harness. If you don't know that context degrades, that compaction silently drops information, that worktrees and subagents are how you isolate work — you can't answer the hardest question in loop design: each iteration, what enters the context and what doesn't. One Osmani line I keep coming back to: "every component in a harness encodes an assumption about what the model can't do on its own." If you can't read that layer of assumptions, your loop is superstition; when it works, it's luck.
If you can't design memory outside the session, the loop will be bad. Sessions are amnesiac; the loop's continuity lives entirely outside the conversation: progress files, git history, task lists, status logs. OpenAI calls durable project memory the single most important technique in the system; Anthropic uses claude-progress.txt plus git commits as the shift handover. Design memory badly and the loop has two endings: it forgets, and does the same work over and over; or it drifts, running further off course while feeling productive. "The agent forgets, the repo doesn't."

The most overlooked of the three is the first. People assume loops are a technology problem. They're a process problem first: however clearly you can write down the workflow is however well the loop will run.

The counterintuitive part: the simpler the loop, the better

Intuition says the heavier the task, the more detailed the loop's instructions should be. Practice says the opposite.

Two reasons. First, the longer the instruction, the more room for misinterpretation. Ten sentences give the model ten places to understand something differently; three sentences leave little room. Second, and more brutal: in a loop, misinterpretation doesn't happen once — it compounds. In a single chat session, a slight misunderstanding resets when you start over. In a loop, every iteration departs from the same document, so one misunderstanding executes hundreds of times; one overnight run turns it into systematic drift. Osmani calls the goal losing fidelity through repeated summarization "alignment drift" — same physics.

So the mental model for writing a loop should be a handover doc for a colleague who's online 24/7: a workflow explained in three sentences is easier to execute well than one explained in ten. Fewer words, fewer ways to be misunderstood; a blunter goal, fewer loopholes to worm into. This isn't my invention — the practitioners converged on it independently:

Huntley repeats it in the original post: "One item per loop. I need to repeat myself here—one item per loop."
OpenAI's 25-hour loop, expanded, is seven steps: Plan → Edit → Run → Observe → Repair → Update → Repeat.
Huntley also argues against turning loops into multi-agent orchestration — "a red hot mess" — one process, one repo, one document is the best shape.

Complexity doesn't disappear; it belongs in verification — tests, types, linters, screenshots, the hard constraints — not in the prose you hand the agent. Hard constraints pull the run back when it drifts. Long instructions compound the drift.

A single track running into the fog: a simple instruction has one direction and one way to run

When not to put work in a loop

Four cases to hold off:

The output is core code that has to last a decade. Ronacher's warning: loops are good at porting, scanning, exploring — transforming existing code or producing short-lived artifacts. Code humans will read for ten years, written unattended by a loop, risks one more quiet layer of defense every iteration.
You have no way to verify. "Done is a claim, not a proof." Without tests, types, E2E, or screenshots, the loop will diligently spin in place, reporting progress every cycle.
A legacy codebase in bad shape. Huntley himself says he wouldn't run Ralph on someone else's existing code.
The process itself isn't sorted out yet. Back to point one: write the workflow down clearly before you automate it.

I'll close by quoting Osmani verbatim: "Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go." A loop doesn't replace engineering judgment. It amplifies whatever judgment you already have — including the absence of it.