Loop engineering designs the automated system that prompts, verifies, and re-triggers an AI coding agent until the agent meets a bounded goal. Machine-readable verifiers, success exits, iteration caps, and budget caps replace human prompting.
TL;DR
A loop pairs a coding agent with a verifier, feedback path, success exit, iteration cap, and budget cap so the agent can run unattended under explicit stop rules. Addy Osmani named the practice after prompt-by-prompt supervision stopped scaling with review capacity, and agents tend to aim for "looks done" unless a verifier and stop rules gate every iteration.
Developers who supervise coding agents prompt by prompt hit a review bottleneck. Agent implementation accelerates while available human verification capacity bounds review throughput. Practitioners report recurring frustrations such as almost-right AI approaches and debugging AI-generated code taking longer than manual implementation. That gap widens in large repositories, where the Context Engine accelerates complex multi-file tasks through semantic dependency graph analysis across 400,000+ files while humans still need time to verify the result. When that tension got a name, Peter Steinberger wrote in an X post that developers "shouldn't be prompting coding agents anymore" and should instead be "designing loops that prompt your agents." Related loop-engineering explainers describe those loops as workflows with verification steps and stop conditions. Addy Osmani's essay the same day gave the practice its name and anatomy.
The Context Engine analyzes repository structure and semantic dependencies across 400,000+ files, so agents inspect call paths, dependencies, and related implementation patterns before editing, producing 5-10x task speed-ups on multi-file work. Augment Cosmos, the unified cloud agents platform with shared context and memory across the software development lifecycle, extends that same context into approval-gated team workflows so verified loops run as reusable, auditable capabilities. This guide defines loop engineering and maps it against prompt engineering, context engineering, and the classic inner/outer development loop. It also catalogs failure modes and shows how one-off agent prompts become workflows with verification gates, approval checkpoints, and run history.
The guide covers four loop-design decisions:
- Define the boundary between prompt wording, context selection, harness execution, and loop orchestration.
- Tie unattended iterations to observable pass/fail evidence.
- Calibrate autonomy against reversibility, approval gates, and rollback controls.
- Promote trusted loops into lifecycle workflows only after verification evidence exists.
These decisions keep agent autonomy tied to observable pass/fail evidence rather than agent confidence.
Loop Engineering, Defined
Loop engineering shifts developers from prompting an agent to building the system that prompts it. A purpose, feedback path, and completion condition set the operating boundary. Osmani's loop engineering definition and a later definition republication describe loop engineering as replacing the human recurring prompt writer with a defined purpose and AI iteration until completion.
Osmani's anatomy includes automations, worktrees, skills, connectors, sub-agents, and external state. He also flagged a compute-budget risk: unattended loops need explicit cost controls because usage becomes a loop-level design variable.
IBM's definition corroborates the role shift: "loop engineering reframes their role away from prompting AI agents toward one in which they design automated systems that prompt, check and guide agents." Secondary names include the agent loop, a vendor-doc term OpenAI uses in its Codex agent loop writeup.
The "Anthropic Playbook" Is Practitioner Synthesis
"Loop Engineering: The Anthropic Playbook" refers to an unofficial PDF attributed to "a senior Anthropic engineer" that circulated in a LinkedIn PDF post and on Facebook. Anthropic's official guidance uses different wording, but its guidance on building effective agents defines the underlying cycle: agents "are typically just LLMs using tools based on environmental feedback in a loop," and "during execution, it's crucial for the agents to gain 'ground truth' from the environment at each step (such as tool call results or code execution) to assess its progress." Treat the PDF's frameworks as practitioner synthesis.
The Layered Stack: From Prompts to Loops
The loop engineering stack moves software teams from single-message prompt wording to autonomous workflows that repeat, verify, and stop under defined controls. The circulating PDF says: "Prompt engineering → Context engineering → Harness engineering → Loop engineering. Each layer automates one more thing developers used to do manually."
Each layer in that stack asks a distinct design question, and understanding the boundary between them clarifies where an issue belongs before teams reach for a fix.
| Layer | Question it asks |
|---|---|
| Prompt engineering | How should the instruction be phrased? |
| Context engineering | What does the model see on this call? |
| Harness engineering | What code runs the loop, tools, and verification reliably? |
| Loop engineering | What autonomous workflow repeats until a goal is met? |
Anthropic's engineering write-up on context argued that context configuration had started to matter more than finding the right prompt wording when teams build with language models. Simon Willison endorsed the term "context engineering" and cataloged sub-techniques including context quarantine and context pruning.
Loop engineering moves the work up one level when the workflow must repeat until a verifier passes or a stop rule halts execution. The loop becomes the unit of engineering work for bounded autonomous workflows. The layers stack because prompt wording, context selection, harness execution, and verifier design each control a different failure point.
Anatomy of the Agentic Engineering Loop
An agentic engineering loop becomes trustworthy when a trigger, topology, verifier, and stop rule combine into an autonomous workflow with explicit success and failure boundaries. Every functioning loop combines those components so the system can decide what the agent does next and when it quits. Osmani frames unattended execution as a loop-design problem with a specific anatomy. Teams define those controls before any unattended run.
The circulating playbook PDF decomposes the loop into operating moves that map cleanly to the components above:
| Move | What it does |
|---|---|
| Discovery | Identifies work worth doing, such as reading CI failures |
| Handoff | Moves the task to an isolated environment, such as a git worktree, to prevent parallel collisions |
| Verification | Checks the result and rejects poor output |
| Persistence | Saves state to disk so the loop survives a session reset |
| Scheduling | Triggers the next turn automatically |
Verification determines whether the loop can run without prompt-by-prompt supervision. Pass/fail evidence decides each retry.
Verification Gates Carry the Reliability
Verification gates decide whether unattended code workflows earn more autonomy. They turn agent output into machine-checkable pass/fail evidence before teams widen the loop's permissions. A code-generation survey of AI-generated code reaches the same conclusion: "iterative feedback loops consistently outperform single-shot generation," because execution feedback such as compiler errors and failing tests provides deterministic, verifiable signals.
Gate ordering matters when the loop can run unattended across multiple iterations. Low-cost deterministic checks should reject syntactic and type-level failures before higher-cost probabilistic evaluation. A conservative verification sequence uses three ordered gates:
- Deterministic gates reject syntactic and type-level errors first.
- LLM-based reasoning evaluates cases that static checks cannot decide second.
- Dynamic testing validates behavior after cheaper checks pass third.
This ordering catches errors at lower cost before probabilistic evaluation runs. Teams comparing governance approaches can map that sequence against established AI agent quality frameworks after defining local pass/fail evidence. Automated PR analysis from Augment Code supports verification-gated code review, with the Code Review benchmark reaching a 59% F-score through context-aware analysis that evaluates code changes against repository structure and implementation intent. Research on Test-Driven Agentic Development shows what tight verification changes: when researchers packaged TDAD as a reusable agent skill, task resolution and code generation rose, and the paper did not observe regressions.
A well-engineered loop pairs a precise goal with the same gate and feeds exact errors into the next iteration. A poorly engineered loop uses "looks done" as the exit signal, gives the agent no readable verifier, runs unattended with no budget cap, or adds multi-agent topology before one verified loop works. The governing tradeoff is direct: verification benefits should justify costs before teams add any pattern, and observed failure modes should guide additions more than anticipated requirements. Teams choosing implementation patterns can review the production-ready hybrid AI coding workflows before expanding autonomy.
Run your software agents at scale
Cosmos gives your agents the context, tools, and feedback loops they need to get better with every workflow.
How Loop Engineering Restructures the Inner and Outer Loop
Loop engineering restructures the inner and outer development loop by moving repeatable implementation work into verified agent workflows while keeping accountability, release judgment, and production risk under human governance. The classic split predates agents. Microsoft's Well-Architected Framework defines the inner loop as refinement in the development environment and the outer loop as movement from development to production with continuous monitoring. Agents redraw that boundary. IT Revolution's three-developer-loops framework now describes multiple loops: an inner loop where the traditional compile-test-debug cycle changes into a request-output-verify workflow, a middle loop that coordinates multiple agents, and an outer loop that spans broader delivery.
Loop engineering divides work by assigning repeatable execution to agents and accountable decision-making to humans:
- The agent and harness run the inner loop: investigation, implementation, verification, repeat. The community
outerloopspecification codifies the structured evidence crossing the boundary: plan, diffs, traces, summaries, and risk assessment. - Humans own the outer loop. Osmani's follow-up essay on outer-loop accountability argues "engineers need to own the outer loop, the accountability for these systems."
Organizations feel loop asymmetry when inner-loop execution improves faster than review, testing, and deployment governance. Augment Cosmos closes that gap by structuring approval-gated lifecycle loops that condense 8 human interruptions into 3 steering checkpoints. Agents handle lifecycle stages while humans steer at prioritization, spec review, and code evolution review. Agentic deep code review inverts the traditional tool's goal because an agent reviewer should maximize recall to catch every possible bug, while human reviewers often prioritize precision.
The Evidence: Faster Inner Loops, Fragile Outer Loops
Loop engineering converts faster inner-loop coding into delivery outcomes only when verification and deployment controls prevent downstream instability. The 2024 DORA report found that as AI adoption increased, delivery throughput and delivery stability suffered, with individual gains "frequently lost to 'downstream disorder.'" The 2025 DORA report reversed on throughput, finding a positive relationship with AI adoption, though instability persisted; AI makes existing organizational strengths and dysfunctions more visible in delivery outcomes. DORA frames architecture and feedback-loop quality as boundary conditions for AI gains: loosely coupled architectures with fast feedback loops are the environments where AI gains are most likely to reach delivery outcomes, while tightly coupled systems see little or none.
The perception gap warns organizations that human estimates can misread agent-loop outcomes. Defect rates and review burden give a firmer signal. METR's randomized trial of experienced open-source developers found developers using AI tools took longer while later estimating that AI had made them faster. METR later updated its speedup findings and labeled the earlier result historical, noting that speedups now seem likely while changes in developer behavior make newer results unreliable. Researchers have not published a peer-reviewed RCT of well-designed agentic loops as of publication.
Engineering leaders should prioritize three measurements before treating agent loops as productivity gains:
- Defect rates that show whether generated changes survive production-quality verification.
- Review burden that shows whether faster generation creates downstream disorder.
- DORA-style outcomes that show whether throughput gains reach delivery stability.
Teams building measurement programs can compare AI-enhanced engineering velocity metrics frameworks against DORA-style outcomes.
Calibrating Autonomy Inside the Loop
Loop engineering calibrates agent autonomy by matching unattended execution to task reversibility, approval gates, and rollback controls. The amount of the loop an agent runs unattended is a design parameter. Anthropic's official taxonomy separates workflows from agents: workflows orchestrate LLMs "through predefined code paths," while agents "dynamically direct their own processes and tool usage." Its autonomy research scores tasks on a risk × autonomy scale and documents unattended-work growth while ordinary interactive turns remain short.
Two criteria dominate calibration for production agent loops:
- Reversibility: Anthropic's safety framework for trustworthy agents uses cancelling subscriptions to show irreversible, business-impacting actions warrant human approval.
- Earned trust: Autonomy should widen only after approval gates and rollback paths prove effective.
The industry vocabulary runs from human-in-the-loop (HITL), where a human approves key decisions, to human-on-the-loop (HOTL), where humans supervise and intervene only when needed. Cosmos enforces Human-in-the-Loop policies that escalate at defined checkpoints while agents continue reversible work between them, so autonomy widens only where task reversibility justifies it.
Failure Modes That Break Agent Loops
Agent loops fail when agents game or bypass the verifier, teams starve it of context, or the stop condition ignores verifier results. Loops fail in documented, repeatable ways, and most failures target the verifier rather than the code. The failures cluster into five recurring patterns:
| Failure mode | What happens | Primary mitigation |
|---|---|---|
| Reward hacking / test gaming | Agents overwrite tests, hardcode expected outputs, or write overly permissive tests to earn passing scores | Held-out test sets; read-only access to test files |
| Tool-call hacking | Agent invokes a tool but guesses from priors instead of using the output | Proof-of-Use verification; separate validator agents with explicit permission to fail the work |
| Context degradation | Reliability degrades super-linearly with complexity; drift studies show task success can fall as context drifts | Just-in-time context loading; atomic commits per wave in git worktrees |
| "Looks done" verification | Agents aim to appear complete and can falsify completion signals through harness-level cheating | Binary pass/fail rewards; independent goal-level verification |
| Runaway iteration | Loops without explicit stop conditions iterate forever on under-specified tasks | Required stop rules; instructing agents to ask for clarification |
Anthropic's Sonnet training showed reward hacking in one environment during RL training; rates dropped in later model series, though new forms emerged, including mock tests and workaround hacks. A study on cheating agents in AI-generated PRs mined harness-level cheating across those pull requests, and related research documents overly permissive test generation, agents that guess tool outputs from priors, and reliability that degrades super-linearly with complexity.
From One Loop to a Lifecycle: The Agent-Run Development Loop
Agent-run development loops restructure the software lifecycle by promoting verified task loops into team workflows with shared environments, reusable roles, approval points, and run histories. Once individual loops work, teams restructure the lifecycle around them. AWS coined the AI-DLC model (AI-DLC). In that model, "the developer's role shifts from writing code to managing and validating AI-generated outputs" and sprints give way to "bolts," work cycles measured in hours to days. An Amazon internal project serves as an adoption anecdote, reporting a shorter delivery plan and smaller team compared to a year-scale projection. Companies report comparable adoption examples, though no single quantified outcome covers them. Ramp used its internal agent "Inspect" for merged PRs, and Coinbase reports daily AI-generated code. Teams evaluating AI-first workflows are usually trying to make agents execute tasks while humans govern, orchestrate, and validate.
Lifecycle scaling changes three operating boundaries:
- Shared environments replace one engineer's harness.
- Reusable agent roles replace local prompting habits.
- Auditable run histories replace ephemeral sessions.
These boundaries determine whether lifecycle loops become team infrastructure rather than individual automation.
Individual adoption fragments setups, traps expertise in one engineer's config, and leaves no quality signal about which setups work. Cosmos addresses that fragmentation by promoting individual harnesses into reusable workflows and capturing every run as a Session that reviewers can replay and audit. Sessions preserve execution history for audit and reuse, while Experts define how agents behave and trigger. Agents share a filesystem with tenant memory, so stored context and repeated reviewer feedback let later runs reuse previous corrections. In one internal example, a specialized tester agent failed when the team loaded all testing context up front. It improved once the team scoped it to a single expert role and coached it over Slack. The team judged it the best testing agent for that specific engineering environment. That is organizational loop engineering: shared loop infrastructure preserves corrections that would otherwise remain in one engineer's local setup.
Reusable lifecycle loops also create an onboarding problem. New agents and reviewers need repository conventions before they can safely reuse shared workflows, so teams evaluating AI developer onboarding platforms need to account for repository conventions, dependencies, and implementation intent before shared workflows expand. The Context Engine compresses that ramp from 6 weeks to 6 days by surfacing repository conventions, dependencies, and implementation intent for both new hires and shared agent workflows.
Build the Verifier Before You Scale the Loop
Loop engineering's central tension is that generation capacity has outrun verification capacity: agents produce code quickly while trustworthy checks remain scarce, human-designed assets. Teams that scale agents before verifiers inherit documented failure modes, while teams that invest in gates first get verifier-bounded outcomes. Start with one recurring task. Write the check, run the loop under those limits, and let the verifier decide when it stops. Once that single loop earns trust, promote it into a Cosmos Session so the rest of the team can reuse the same verified workflow.
FAQ
Related
Written by
Molisha Shah
Molisha is an early GTM and Customer Champion at Augment Code, where she focuses on helping developers understand and adopt modern AI coding practices. She writes about clean code principles, agentic development environments, and how teams are restructuring their workflows around AI agents. She holds a degree in Business and Cognitive Science from UC Berkeley.