TL;DR: Loop engineering has been getting a lot of attention, but it is really three names for one thing: the community calls it loop, Anthropic’s official docs call it harness. The real structure is a four-level delegation ladder, running from “you’re still watching” to “you’ve handed over even the problem statement.” It exists because of three real problems, the most critical being that models cannot reliably judge the quality of their own output. Anthropic’s own benchmark data makes the stakes concrete: a single agent produced a barely-functional prototype in 20 minutes; a full framework with generation and evaluation split ran for 6 hours and produced something genuinely usable.

“I no longer prompt Claude. I write loops that prompt Claude for me.” Boris Cherny, the author of Claude Code, said that in a Sequoia AI Ascent 2026 interview, and the clip has been shared nearly 700,000 times. But ask a follow-up question and the trouble starts. The community calls this thing a loop. Anthropic’s official docs call it a harness. Google’s Addy Osmani gave it a formal name: loop engineering. Three names, one referent, no wonder it reads like three different new technologies. This piece aligns the vocabulary first, then explains the real structure, what problem it solves, and how it connects to a system I built myself.

What is loop engineering, exactly?

Start with the terminology. Loop (the term pushed along a community line through Peter Steinberger, Addy Osmani, and swyx) and harness (Anthropic’s official term) are two names for the same thing. A harness is the apparatus that sits around the model: the prompt, the tools, the memory or handoff files, the orchestration. The model does the thinking; the harness keeps it aimed at the target.

One sentence on what it actually does: instead of directing the AI step by step yourself, you write a system that keeps directing the AI, running toward a goal until it finishes. This is a spectrum. Anthropic’s essay “Building Effective Agents” marks the two ends: workflow, where the path is hard-coded and predictable; agent, where the model decides its own path at runtime, which is more flexible but costlier, slower, and prone to compounding errors. Between them are five building blocks in ascending order: chaining, branching, parallelization, orchestrating subagents, and finally generator-evaluator. The official principle is to stay as simple as the task allows and move up only when you genuinely need to.

What a loop is: a goal enters the system, Claude works through rounds, and the output is released only when the stopping condition is satisfied

The layer that actually determines how much you have delegated is how the loop runs. Claude Code’s official documentation, “Getting started with loops,” breaks this into a delegation ladder with four levels, distinguished by what you hand over:

Turn-based: You give a prompt; the agent gathers context, takes action, verifies the result, and runs another round if it is not done yet, stopping only when it judges the task complete or the token budget runs out. You are still watching every step.

Turn-based loop: you give a prompt, Claude gathers context, acts, verifies, and responds only when it judges the task done

Goal-based (/goal): What you hand over is no longer step-by-step instructions but the stopping condition. The agent works on the task while a separate evaluation model checks the conditions you set. If it fails, the task goes back for another pass. The evaluator is a different model; the agent does not get to grade itself.

Goal-based loop: you hand over the stopping condition, a separate model acts as evaluator, and the task goes back if it fails

Scheduled and autonomous (/schedule): What you hand over is the trigger: you do not need to write a prompt each time. The system runs persistently in the cloud, watching an event source. The primary agent runs until verification passes and opens a PR; a second agent reviews and notifies you; you decide whether to merge. The most autonomous variant, nested within this tier, hands over even the problem statement. The only action you retain is the final decision.

Scheduled and autonomous loop: you hand over the trigger, the system runs in the cloud until verification passes and opens a PR, you decide whether to merge

Why this is gaining traction now: the model and the framework are co-evolving. METR’s time-horizon benchmarks show that Claude 3.7 Sonnet completed half of tasks within roughly 59 minutes; by Opus 4.5 that figure had grown to around 4 hours 49 minutes (METR’s official number, with a confidence interval of 1 hour 49 minutes to 20 hours 25 minutes, sample sizes are still limited). As the models grow stronger, the frameworks simplify: patterns that once required repeated context resets are often handled natively by newer models, and the framework’s complexity drops accordingly. This co-evolution is the backdrop for everything that follows.

What problem does it actually solve?

Three specific, concrete problems drove loop engineering into existence. In a May 2026 workshop hosted by Anthropic’s engineering team (presented by Ash Prabaker and Andrew Wilson), the failures encountered by long-running agents were sorted into three categories. First: context limits, the window is finite, the model forgets, and its state degrades. Second: weak planning, large models are not natural planners; they frequently stop halfway through and leave a half-finished result. Third, and most critical: models cannot reliably judge the quality of their own output and will declare a half-finished feature complete.

Earlier solutions fell short. A single model, a single session, running a build-check-fix loop and compressing its own history to patch itself: this approach’s fatal flaw is precisely the third category. It grades its own work, stamps it approved, and ends up patching an unreliable foundation indefinitely. The Anthropic principle that gets quoted often is aimed at exactly this: fail predictably rather than succeed unpredictably.

How the new approach addresses each failure: the context problem is solved with structured file handoffs rather than model memory; the planning problem is solved by having a planner agent decompose a vague requirement into a spec and multiple sprints before any code is written; the third and most critical problem is solved by splitting generation and evaluation into two agents with independent contexts and independent system prompts, borrowing the adversarial structure of a GAN. Ash said it plainly in that workshop: critiquing a painting is far easier than painting one, so rather than asking the generator to self-critique, train a strict independent reviewer.

What makes this practical is a step that happens before any work begins. The two agents, generator and evaluator, negotiate the completion criteria upfront. In Anthropic’s documented case study, a single sprint (the level-editor sprint) produced 27 measurable criteria, each with a clear threshold. If any one failed, that phase was incomplete; the generator received specific feedback and went back to work.

📊 Primary benchmark data

  • Single agent on the same problem (building a retro game-making toolkit): 20 minutes, $9, a barely-functional prototype
  • Full framework with planning, generation, and evaluation separated: 6 hours, $200, RetroForge, a genuinely usable, playable application
  • Nearly all of the additional time went into negotiating what “done” meant and strictly verifying whether it was reached: that is exactly what determined whether the output was usable

Anthropic added a clarification worth keeping: the co-evolution of stronger models and simpler frameworks does not mean the framework layer disappears. Their phrasing is that interesting harness combinations will not diminish as models improve; they will just shift. Old patterns get absorbed by the model; new capabilities open new combinations. How to apply this depends on where your task sits: wherever the model still cannot carry the weight, the framework still has to.

How does this connect to my own translation system?

In “Building Effective Agents,” when Anthropic illustrates the generator-evaluator building block, the example they use is literary translation: translation involves many fine details the first pass may miss, but an independent evaluation model can provide useful critique and iterate through revisions. That happens to be exactly what I started building a few months ago: a meeting translation quality engineering system I call TQEF. Multiple speech recognition streams feeding different engines, into a translation model, through post-processing, out as segmented translations: the generation side. A scorer applying a five-dimension rubric to each segment (terminology, fluency, context, formatting, fatal errors), rejecting anything that does not pass: the evaluation side. Five sources merging, scheduled processes accumulating a corpus: the infrastructure holding the whole thing up.

I did not read this official framework before building it. I arrived at the same structure by running into the same walls, round by round. I thought one step further than the official illustration: not just tuning the scorer’s prompt, but adding a phase (I call it Stage B) to verify whether the scorer itself is accurate: cross-checking its judgments against a separate set of metrics, calibrating it against expert human scores, checking whether it produces stable results when run on the same batch twice. I have not actually finished that phase. It sits behind other priorities, an honestly-left-open gap. This responds directly to the principle stated earlier. A loop can help you separate generation from evaluation, but what “a good translation” means is something you have to define yourself first, and even whether your own ruler is accurate is something only you can verify.

Having walked that path once, I settled on a few working principles. Every handcrafted component gets one sentence explaining why it exists: that sentence forces you to decide whether to keep it when the model improves. When a model upgrade arrives, subtract before you add. Put your energy into the evaluator and the criteria; those survive model changes. Do not put it into stacking more loops; those get absorbed. When one result fails, do not just fix that result: encode the failure into the system so every future round benefits. Control token costs at the right layer: the goal-based evaluator works fine with a cheaper model if the stopping condition is written clearly; deterministic steps belong in scripts, not in prompts.

Loop engineering lets you hand over the how: how to gather context, how to take action, how to verify. What it can never hand over is who defines what “ran correctly” means. That standard has to come from a person first.

This piece covers the framework itself. How I independently arrived at the same structure inside the translation system over the past few months, and where I ran into trouble, is a story for the next post.

References

Anthropic / Claude Code, official primary sources

Other primary sources

  • Boris Cherny (head of Claude Code), Sequoia AI Ascent 2026 interview: the original source of the opening quote. This line was later clipped and recirculated widely; this piece cites the interview itself rather than the secondhand versions
  • Addy Osmani, Loop Engineering: the original essay that formally named the concept