Loop Engineering: The Work Moves From Prompting to Control

Picture this. At 3am, a coding agent opens its fourth pull request against the same bug. The tests are green. The diff is clean. The permission check it removed was never covered by the test suite.

The impressive part is that the agent kept working after everyone went home. The problem is that nobody can tell whether four attempts created progress or simply made the mistake look more finished.

That tension sits underneath the sudden interest in loop engineering: designing systems that keep AI agents working toward a goal without a person writing every prompt.

On June 7, Addy Osmani named and codified the term with a clean definition: replace yourself as the person prompting the agent and design the system that prompts it instead. Boris Cherny, head of Claude Code, had described his job as writing loops a few days earlier. Peter Steinberger then gave the idea its compact slogan: design loops that prompt agents. Geoffrey Huntley’s 2025 Ralph Wiggum technique was an important working antecedent.

Loop engineering gives a new name to a familiar pattern. The human moves from directing each turn to deciding how work is found, assigned, checked, remembered, and stopped.

It sounds like the next rung after prompt engineering, context engineering, and harness engineering. That framing is convenient and slightly misleading. Loops still depend on all three. They add an outer control layer around them.

If the prompt is vague, the context stale, the tools over-permissioned, or the tests shallow, repetition magnifies the defect. A loop can remove the human from each turn. It cannot remove the need for human judgment from the system.

This week in AI News

Three launches and incidents moved agent strategy closer to production operations.

• OpenAI’s Hugging Face Incident Turns Agent Evals Into Production Risk — PMs need containment and recovery metrics beside task scores.
• Gemini 3.6 Flash Makes Cost per Completed Task the Model Metric — Model routing should optimize accepted outcomes, not token price alone.
• OpenAI Presence Moves Agents From Demos Into Operations — Enterprise agent roadmaps now need explicit handoffs, controls, and release discipline.

Loop engineering adds a control layer

The familiar way to work with an AI agent is conversational. We describe a task. The agent acts. We inspect the result, add context, correct a mistake, and send the next prompt.

A loop moves that coordination into the system around the agent. In practice, it looks less like a superhuman engineer and more like a small operations team encoded in software.

A trigger finds work. A coding agent receives a scoped task in an isolated workspace. Tests or another agent inspect the output. A durable artifact records what happened. The system then stops, retries, escalates, or selects the next task.

Anthropic’s Claude team defines a loop as an agent repeating cycles of work until a stop condition is met. It distinguishes four useful forms:

• A turn-based loop, where a person starts the task and checks the result.
• A goal-based loop, where the agent iterates until measurable completion criteria are met.
• A time-based loop, where the same process runs on an interval.
• A proactive loop, where an event or schedule starts a recurring workflow without a person present.

This is a more precise frame than “agents that work while we sleep.” The trigger, the stop condition, and the evidence of completion matter more than the number of autonomous hours.

Osmani’s implementation stack includes automations, worktrees, skills, connectors, subagents, and durable state. The names will vary across tools, but production implementations tend to need several layers:

1. Something must decide when work begins.
2. The agent needs enough context and access to act.
3. Parallel work needs isolation.
4. Progress must survive beyond one conversation.
5. Another mechanism must judge the output.
6. The loop needs limits and an escalation path.

Those layers are not all part of the loop’s kernel. The smallest loop only needs repeated action, feedback, and a rule for continuing or stopping. Worktrees prevent parallel file collisions. Connectors provide access. Skills and state improve continuity. Human gates contain risk. They are scaffolding that makes a loop usable in production, not proof that a loop exists.

None of this is magic. Schedulers, queues, state machines, CI pipelines, sandboxes, and approval gates have existed for years. The new ingredient is a probabilistic worker that can interpret messy inputs and choose actions inside that machinery.

That difference is large enough to matter. It is also why copying a cron example and calling it an agent strategy is dangerous.

Repetition is not progress

Anthropic’s work on long-running agent harnesses shows what happens when capable models are simply left to continue.

Agents tried to implement too much at once, ran out of context midway through a feature, left unclear state for the next session, and sometimes declared the project complete because the repository already looked busy. Compaction helped, but it did not reliably preserve intent across long runs.

The fix was operational rather than rhetorical. Anthropic used an initializer agent to create the environment, decomposed the product into a detailed feature list, asked later agents to make incremental progress, and stored state in files and git history. The conversation could disappear because the work record did not.

Their later work on planner, generator, and evaluator agents exposed a second problem: agents are generous reviewers of their own output. A page can be functional and still look generic. Code can pass tests and still misunderstand the product. Asking the same agent whether its work is good often produces confident approval.

A separate evaluator helps, provided it has a real rubric and access to evidence. Even then, Anthropic reports added orchestration complexity, token overhead, and latency. In one multi-hour application experiment, its full planner-generator-evaluator harness took six hours and cost $200; the solo run took 20 minutes and cost $9. The harness delivered a working core function that the solo attempt missed, but it still shipped UX and physics defects.

The experiment cuts both ways. Iteration bought a better outcome at more than 20 times the cost, without eliminating defects. More agents are not free, and an evaluator without taste is only a second opinion from the same blind spot.

Every loop optimises against a definition of “done.” If that definition is shallow, the loop becomes very efficient at producing shallow success.

The bottleneck moves to review

Agent throughput is already running into human capacity.

GitHub reported in May that Copilot code review had processed more than 60 million reviews and that more than one in five code reviews on GitHub involved an agent. The same guidance warns reviewers to look for disabled tests, duplicated utilities, missing permission checks, changes that pass CI while remaining behaviourally wrong, and prompt injection through untrusted workflow inputs.

Prompt injection becomes more dangerous inside a loop because the system can ingest the same poisoned premise repeatedly, preserve it in task state, and act through credentialed tools. Anthropic’s guidance on trustworthy agents treats permissions and human check-ins as a balancing problem: too many pauses destroy the workflow, while too few let an agent push through uncertainty. Sandboxes, task-scoped credentials, reversible actions, and approvals for consequential steps belong in the product design.

A loop can create branches, patches, tests, and pull requests faster than a team can understand them. That may increase visible output while slowing the path to a trustworthy release.

DORA’s 2026 analysis of AI in the software lifecycle describes a similar trade-off. AI speeds up initial generation and helps people start work, but teams often spend the saved time on auditing and verification. Higher AI adoption was associated with both greater delivery throughput and greater instability. DORA’s conclusion is blunt: AI amplifies the organization around it. Strong platforms, clear APIs, and good tests get leverage. Fragmented tools and fragile infrastructure generate debt faster.

Productivity evidence also deserves restraint. METR’s early-2025 randomised study covered 16 experienced open-source developers working on 246 real repository tasks and found that they took 19% longer with the AI tools available at the time. METR now labels that result out of date.

Its February 2026 follow-up produced raw estimates consistent with a possible speed-up, but the confidence intervals crossed zero and participation bias made the result unreliable. A May 2026 survey of 349 technical workers found a median self-reported 1.4–2x increase in value and a 3x increase in speed. METR also cautioned that people can overstate counterfactual productivity gains and that speed is not the same as value.

The evidence does not support a single verdict that AI agents are inherently slow or fast. The effect depends on the task, the user, the repository, and the operating system around the model. Loop engineering is an attempt to improve that operating system. It should be measured by completed, trusted work rather than prompts avoided or code generated.

A practical test for loopability

Before putting a workflow into a loop, ask seven questions.

The last question is easy to ignore. If a person can complete the task in 15 minutes but needs 45 minutes to review the agent’s output, the loop has shifted labour rather than removed it.

The economic metric should be cost per accepted outcome: model and tool spend, reviewer time, rework, and incidents divided by work that a named owner was willing to accept. Cost per run hides the expensive parts.

The strongest early use cases tend to be repetitive, narrow, observable, and reversible: issue triage, test repair, dependency updates, documentation checks, support summarisation, analytics QA, content validation, and bounded code changes.

Most of the primary evidence behind loop engineering still comes from coding agents. Applying the label to support, finance, content, or product operations is a reasonable extension, but it is still an extension. Those domains often have weaker ground truth and more consequential edge cases.

Roadmap strategy, sensitive customer decisions, large architectural changes, and high-stakes production actions need tighter human ownership. Agents can prepare evidence or explore options. They should not inherit authority simply because a tool can schedule them.

What a useful loop looks like

Consider a customer bug reported through support.

A weak implementation forwards the ticket to a coding agent every hour and asks it to fix anything new. The agent can misunderstand the report, edit the wrong component, weaken a test, and open a large pull request. The automation technically works.

A better loop has more structure:

1. The trigger accepts only reports with reproducible steps, affected version, and expected behaviour.
2. A triage agent checks for duplicates and turns the report into a scoped issue.
3. A coding agent works in a disposable worktree with limited credentials.
4. The repository’s tests, browser checks, and security rules produce evidence.
5. A separate reviewer checks critical paths, permissions, duplicated logic, and changes to CI.
6. The system records attempts, test results, spend, and unresolved questions outside the chat.
7. A human owns the merge decision. High-risk changes escalate earlier; low-confidence attempts stop.

The agent may do most of the mechanical work. The loop still encodes organizational judgment: what counts as a valid bug, which systems may be touched, what evidence is sufficient, and who accepts the remaining risk.

PMs have a direct role in loop design. Someone has to define the user promise, acceptable failure modes, confidence thresholds, escalation experience, and economics of each run.

Where the product advantage will sit

The first buyers will be teams with recurring queues, expensive coordination, and a way to verify outcomes: software organizations with issue backlogs, support operations with repeatable resolutions, security teams processing findings, and content or analytics teams running frequent quality checks. Their pain is not a lack of generated output. It is the cost of moving work from intake to trusted completion.

That makes the best wedge narrower than “an agent that can do anything.” A startup may begin with dependency upgrades, a specific class of security remediation, or support tickets that can be reproduced and checked. Each completed run adds failure examples, exception rules, and better evals. Expansion can follow trust.

A generic loop builder is easy to copy. Most of its primitives are becoming standard product features. The closer the product sits to a real workflow, the more defensible it becomes:

• Proprietary rubrics that capture what good work looks like.
• Historical traces connecting agent decisions to real outcomes.
• Trusted access to repositories, tickets, support systems, and approvals.
• Exception handling built around domain-specific risk.
• A review surface that helps humans judge quickly instead of dumping more output on them.

Distribution matters as much as model quality. The strongest products will meet work where it already arrives: GitHub, Linear or Jira, Slack or Teams, support desks, and CI. A separate agent dashboard asks users to create another queue. An embedded loop can inherit the existing queue, permissions, ownership, and audit trail.

Incumbents have an advantage because they already own that state and distribution. Startups can still win by owning one expensive loop end to end and encoding better domain verification than a horizontal platform. A product that resolves a narrow class of security findings with strong evidence may beat a broad agent platform that can attempt everything but prove little.

The durable switching costs are the accumulated evals, exception rules, audit history, integrations, and human trust. Prompts alone will not hold a customer.

The operator’s job is the outer loop

Loop engineering is a useful name for a change already underway. We are spending less time telling agents which file to open next and more time designing the environment in which they can make progress.

But autonomy is a poor north-star metric. “How long did the agent run?” tells us almost nothing about whether the work was valuable.

A better scorecard is harder and more grounded: how much trusted work reached completion, how much human review it consumed, how often the loop escalated correctly, what failures escaped, and whether the economics held at production volume.

A team has built a serious loop when it can point to the exact boundary where automation stops and a named human accepts the remaining risk.