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.

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 one level up. It is the design of an agentic system that decides when and how often that inner loop fires, unattended.

Loop engineering builds on prompt/context and harness engineering. Context engineering curates what a model sees on one turn. Agent harness 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.

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 — scanning a queue, an inbox, a repository, or a schedule for items that warrant a run.
  • Verification: Checking the quality of an iteration’s output before it is acted on or trusted.
  • 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.
  • 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.

The paper catalogs six structural components that recur across loop-engineered systems: automations, worktrees, skills, connectors, sub-agents, and memory systems.

Production examples cited include Stripe’s pipeline, which processes over 1,300 machine-written pull requests per week.


See also