The term “loop” is currently fashionable in agent‑driven development, but people mean different architectures when they use it. Laurie Voss — republishing a piece originally on LinkedIn — identifies four distinct loop types and outlines why distinguishing them matters for engineering autonomy safely and effectively.
1) The execution loop: the agent’s act‑observe cycle
This is the loop most people imagine for an agent: call a tool, read the result, decide the next action, and repeat. Addy Osmani calls this the inner execution loop: the part an agent can run largely on its own. The loop terminates on environment feedback (test output, API response, file contents) or when the agent decides it is finished — correctly or not. A practical mitigation is to wrap this loop in another loop that does not accept the agent’s self‑assessment at face value.
2) The task (Ralph) loop: restart until the spec is satisfied
Geoffrey Huntley’s Ralph loop reinvokes an agent against the same specification repeatedly, giving a completely fresh context window each iteration and doing exactly one task per loop. The apparent waste is intentional: refeeding the full spec every time prevents context rot and compaction that degrade long‑running sessions. The loop iterates on a single artifact; it ends when the spec is complied with and tests pass. Humans write the spec, judge done‑ness, and watch the loop for failure patterns to fix so they don’t recur.
3) The product (software factory) loop: the whole development lifecycle
This version dominated discussion at the AI Engineer World’s Fair. Tereza Tizkova (Factory) defined a software factory as “the whole loop, the whole lifecycle of developing software with autonomy.” Zach Lloyd (Warp) described the lifecycle as triage, specification, implementation, review, verification, shipping, and monitoring. Warp is dogfooding the idea: it placed an open repo under its factory platform Oz and increases automatic PR merge rates from low towards higher percentages (for example from 20% toward 60%). Anthropic reports that 65% of its product team’s code is created by its internal Claude Tag, and Mike Krieger described using it to delegate responsibility proactively — not “fix this bug” but “own this part of the codebase, monitor feedback, and pick up tasks.”
Unlike the task and execution loops, which have clear exit conditions, the product loop continuously iterates on a codebase and backlog. Its closing signals come from outside the codebase: new issues, production logs, user feedback, and review outcomes. Human involvement is configurable: organizations choose which lifecycle parts to automate and where to require human checkpoints (e.g., human code review for high‑risk changes).
4) The system (autoresearch) loop: agents that improve the system
Roland Gavrilescu (Introspection) calls this autoresearch. The inner loop performs user‑facing work; the outer loop studies and maintains the primary system, iterating on prompts, harnesses, model choices, and even the evaluations themselves. There are concrete examples: Andrej Karpathy’s March 2026 autoresearch was about 630 lines of Python running 50 hypothesis‑edit‑evaluate experiments overnight on one GPU. Meta’s Brain2Qwerty v2 (announced in late June 2026) reportedly had agents iteratively modify the codebase to invent better decoding architectures and achieve substantial word error‑rate improvements; Meta noted that final training configurations were still chosen by hand. The system loop’s exit signals are the most demanding: evals, human judges, filtered product feedback, and, in Roland’s design, an explicit ask‑a‑human tool by which the agent accumulates tacit knowledge.
What about Agentic MapReduce?
A pattern called Agentic MapReduce (e.g., Cognition’s Devin Security Swarm) fans parallel bounded agents across a repo and aggregates results. Voss argues this is a pipeline — dispatch, gather, validate — not a loop, because it lacks feedback into a next cycle. Fan‑out is a topology you can deploy inside any of the four loops, but it isn’t a loop itself.
The unnamed outer ring: the oversight loop
Swyx’s diagram had an outermost ring labeled “???? loop.” Voss names it the oversight loop: where goals are set, budgets allocated, and work culled. It’s the ring where a human should live. Addy Osmani put it succinctly: “That inner loop is capability. The outer loop is agency.”
Debates at the World’s Fair largely reduced to who runs that top ring. Zach Lloyd and Roland Gavrilescu argue for incrementally ratcheting autonomy and deliberately choosing checkpoints (Roland’s metaphor: build orchestras — systems with a human conductor — before factories). Others worry that delegating understanding replaces people and robs them of ownership and purpose: Geoffrey Litt of Notion called fully automated factories a depressing vision, and Paul Bakaus stated bluntly, “There is no auto, and there will be no auto.”
Autonomy is a dial per loop; the engineering question is information
Autonomy can be dialed independently for each loop. You can run a fully autonomous execution loop inside a heavily supervised product loop, or give agents the system loop while keeping goal‑setting human. The key engineering question is not which camp wins but what signals and instrumentation you need to set each autonomy dial correctly. A loop without its closing signal won’t converge; it will run until an external force stops it.
Voss’s taxonomy gives practitioners a map: four named loops plus the oversight ring. Knowing which loop(s) you are building clarifies where to climb the stack and what to instrument so that higher autonomy produces safe, useful outcomes.
