Loop engineering

Loop engineering is the practice of designing self-running systems in which an agent operates repeatedly, with minimal human involvement, on a recurring cadence rather than a single request-response turn.

Loop engineering is a specialized form of agent orchestration. It coordinates agents over repeated turns and long-running goals, but with a narrower focus on unattended execution and self-running loops.

The term and framework come from Peter Steinberger, Boris Cherny, and Addy Osmani’s paper Loop Engineering: The Anthropic Playbook for Designing Systems That Prompt Your Agents.

Don’t confuse this with the agent loop, which is the cycle within which an agent runs. Loop engineering operates at a higher level of abstraction. It is the design of an agentic away-from-keyboard workflow that autonomously decides when and how often to run that inner agent loop, unattended, until a goal is reached. In other words, loop engineering is the design of a system that runs an agent loop, rather than the design of an agent loop itself. Or, to explain it another way, loop engineering is the practice of designing automated systems that prompt agents on behalf of humans, rather than humans prompting agents directly.

Loop engineering builds on prompt/context and harness engineering. Context engineering curates what a model sees on one turn. Harness engineering builds a machine for running one or more agents. Loop engineering sits a level above the harness. It designs a system that decides when and how often an agent runs, often with agents prompting other agents, rather than a human managing the turns.

The explicit objective of loop engineering is to remove the human from the loop entirely. Loop engineering designs for the human to step back into a supervisory role — setting up discovery, verification, and scheduling once, then letting the system run unattended across many iterations. Agent execution in this detached, no-chat-interface mode is sometimes described as AFK.

As per the original paper, loop engineering decomposes the design of a recurring agent system into five concerns:

Discovery: Finding what work needs to be done, eg. scanning a queue, an inbox, a repository, or a schedule for items that warrant a run.
Delegation: Handing the work to an agent (or a team of agents) equipped to carry it out.
Verification: Checking the quality of an iteration’s output before it is acted on or trusted.
Persistence: Maintaining state and memory across iterations, so each run can build on what came before rather than starting cold.
Scheduling: Deciding when the loop fires — locally on a fixed interval, or in the cloud against an event or queue — trading off responsiveness against state-management complexity.

The paper’s central architectural principle is to structurally separate the agent that generates work from the agent that evaluates it, rather than asking one agent to critique its own output. Self-evaluation is prone to self-praise bias. A generator grading its own work tends to rate it more favorably than an independent evaluator would.

Verification layering

The "verification" concern is operationalized as a layered set of checks, each catching a different class of failure at a different cost.

Automated check

An automated check is a deterministic verification in the environment — tests, type checks, lints, build, pre-commit hooks. It is pass/fail with no judgement. The signal is something an agent can self-correct from without involving anyone else. Self-correction works as a loop: the agent makes a change, runs the check as a tool call, and the failure output lands in its context — a type error with file and line, a failing assertion with expected and actual — enough to fix and re-run, around and around until it passes, with no human in the loop.

Determinism is what makes the loop trustworthy. A flaky check poisons it: the agent "fixes" code that was fine, or retries past a real failure. Good checks are a large part of a codebase’s AX. A check only catches what it asserts — green checks mean the asserted properties hold, not that the code is right. See automated testing.

Automated review

An automated review is an agent reviewing another agent’s work, often with a different model or a review-specific system prompt. It is non-deterministic — it forms a judgement. The separation from the working agent is what makes it work. Asking the agent that wrote the code to review itself gets little: the session that produced the bug contains the reasoning that produced it, so a fresh-context reviewer sees the diff the way a stranger would. A different model or review-specific system prompt sharpens this.

Automated review slots between the other layers. Automated checks are deterministic and catch the mechanical. Human review is expensive and scales worst. Automated review catches judgement-shaped problems — a misleading function name, a missed edge case — at machine cost. It is non-deterministic, so it can miss things and flag non-issues. It is a filter that raises the floor before a human looks, not a gate that replaces one.

Human review

Human review is the user reading the code the agent produced and forming a judgement. Reading the diff or changed files counts; reading the agent’s description of what it did does not. Narration is not the artifact — the description is a secondary source written by the party being reviewed, while the diff is the primary source (see agent handoff).

Agents raise the volume of code produced, so review becomes the bottleneck. Layer the strategies: automated checks catch mechanical failures, automated review catches describable ones, and human review is reserved for what only you can judge — is the change the right change, does the approach fit, should this exist at all. Review is cheaper earlier. Reading a plan before work starts, or a small diff mid-flight, takes minutes; excavating a finished branch after an AFK run takes longer. Dropping review entirely is what vibe coding names.

Trajectory evaluation

Testing AI-generated work requires evaluating not just the final artifact but how the agent got there. Output evaluation checks the result – does it compile, do tests pass. Trajectory evaluation checks the full sequence of tool calls and intermediate reasoning that produced it. Both are necessary. A fluent output that skipped its verification steps is a more dangerous failure than one with a visible error, because the silence hides the gap. This is why the generator/evaluator separation matters – an independent evaluator with fresh context judges the trajectory, not just the result. See agent loop for the loop and automated testing.

The paper catalogs six structural components that recur across loop-engineered systems: automations, worktrees, skills, connectors, sub-agents, and memory systems. Further patterns are emerging in early open source implementations (see below). For example, a common pattern is to define agentic workflows declaratively as a directed acyclic graph (DAG) — typically expressed in YAML or JSON — where each node is a task or specialized agent and each edge is a dependency.

Implementations

The Open Agent Spec is an attempt to define a common schema for defining agents declaratively. It is strictly linear and cannot orchestrate multiple agents or complex workflows involving a mix of agentic and deterministic steps. It is unclear how widely this has been implemented as of July 2026.