Loop Engineering
The engineering discipline of designing the outer, autonomous system — automations, worktrees, skills, plugins/connectors, sub-agents, and externally-persisted state — that repeatedly invokes an agent harness without a human prompting each turn. Broader than the inner agentic-loop architecture and sibling to agent-harness engineering.
Also known as: outer loop, the loop that prompts for you, automations, worktrees, skills, connectors, sub-agents, persisted state (agentic)
Part of: Agent Harness
How authors use it
Oldest first (extraction date when no publication date is known).
| Author | Their term | Their meaning |
|---|---|---|
| Loop Engineering Addy Osmani · 2026-06-07 | Loop engineering | designing the outer, autonomous system — automations, worktrees, skills, connectors, sub-agents, persisted state — that repeatedly invokes an agent harness without a human prompting each turn |
| What is “loop engineering?” The Pragmatic Engineer · 2026-07-14 | loop engineering | Designing the system/harness-level scaffolding (goal, completion check, state persistence, re-invocation) that decides what to prompt an agent and when to stop, as opposed to manually writing and issuing individual prompts. |
| Zero to Agent in 30 Minutes: From Prompting to Loop Engineering with Ofer Mendelevitch Michelle Smith · 2026-08-18 | loop engineering | Replacing a sequence of individual human prompts with a single end-result the agent can check for itself -- the agent inspects code, adds tests, runs them, fixes failures, and verifies packaging, continuing until a defined goal is met, without a human prompting after each step. |
| Loop Engineering: Building Blocks, Adoption, and Impact Jai Lal Lulla; Vahram Nersesyan; Seyedmoein Mohsenimofidi; Christoph Treude; Sebastian Baltes · 2026-08-28 | Loop engineering | The practice of designing automated control structures that repeatedly invoke coding agents, triggered on a schedule or by events, with each run bounded by a machine-checkable stop condition; a well-engineered loop also persists state, verifies independently of the implementer, bounds cost, restricts unattended changes, and defines human escalation points. |
| How Anthropic Builds And How Engineering Will Change Soon | Thariq Shihipar Ryan Peterman · 2026-09-07 | Loop Engineering | Setting up a system that prompts Claude on your behalf (scheduled or triggered) instead of prompting it yourself turn by turn; at team scale this requires heavy investment in skills and verification so that autonomously-landed changes can be trusted. |
| Own the Outer Loop Addy Osmani · 2026-09-09 | outer loop | The human-owned boundary of decision, verification, and accountability that wraps an automated agent loop — where a person decides, verifies, approves, and owns the result; the site of Quality, Verdict, and Answerability. |
Documents (9)
- Own the Outer Loop Addy Osmani · 2026-09-09 source ↗ Reader 🖥️
Because agents supply capability but cannot inherit consequence, engineers must own the 'outer loop' of agentic systems — the boundary where Quality (checks/evidence), Verdict (the ship/block decision), and Answerability (the guarantee of being able to explain why) live — which means personal, attributable accountability, not code-writing skill, is what becomes scarce and valuable as harnesses, loops, fleets, and software factories absorb the inner work. - How Anthropic Builds And How Engineering Will Change Soon | Thariq Shihipar Ryan Peterman · 2026-09-07 Reader 🖥️
Inside Anthropic, engineering is already organized around treating Claude as a thought partner wrapped in an increasingly sophisticated harness/loop rather than around hand-writing code, and this shift will diffuse into the rest of the industry — leaving the durable human value in judgment, taste, verification design, and self-directed visibility rather than in code production itself. - Inside a Software Factory Paul Iusztin · 2026-09-04 Reader 🖥️
A 'software factory' — a human-operated automated pipeline of eight SDLC stages over a shared context layer — is the right unit of analysis for disciplined AI-assisted development because it locates humans precisely at brainstorming, planning, and final review while agents execute everything between, and the engineering skill lies not in maximizing automation but in calibrating how much of the factory to build, buy, or leave manual as team scale and trust in the plan grow. - Loop Engineering: Building Blocks, Adoption, and Impact Jai Lal Lulla; Vahram Nersesyan; Seyedmoein Mohsenimofidi; Christoph Treude; Sebastian Baltes · 2026-08-28 Reader 🖥️
"Loop engineering" has a stable, practitioner-agreed definition and set of building blocks (triggers, stop conditions, persisted state, verifiers, budgets, escalation points) for designing systems that repeatedly prompt coding agents instead of a human doing so turn by turn, but an exploratory mining study of 36,710 open-source repositories finds confirmed autonomous agent loops in only 0.59% of them, and shows that while loops' triggering configuration gets committed to version control, almost none of the prescribed runtime building blocks — state files, verifiers, budgets, machine-checkable goal conditions — do, leaving the practice's claimed value almost entirely untested by evidence. - Zero to Agent in 30 Minutes: From Prompting to Loop Engineering with Ofer Mendelevitch Michelle Smith · 2026-08-18 source ↗ Reader 🖥️
Moving a coding-agent workflow from fully human-prompted toward autonomous happens in two escalating steps -- replace a sequence of individual prompts with one verifiable goal the agent can check itself against, then add a second agent as an independent reviewer of the first -- and doing both reduces required human intervention while raising code quality. - What the Hell Is a Loop, Anyway? Laurie Voss · 2026-07-29 source ↗ Reader 🖥️
The word 'loop' in mid-2026 AI-engineering hype names at least four architecturally distinct systems — execution, task, product, and system loops, each defined by what it iterates on and what ends it — plus an unnamed fifth ring above them, the oversight loop, where a human sets goals, allocates budget, and culls work; so the real engineering question isn't whether to build loops or which camp in the autonomy debate is right, but what information is needed to set the autonomy dial correctly at each of those five levels. - Software Factories, Light and Dark AddyOsmani.com · 2026-07-20 source ↗ Reader 🖥️
Because verification, not generation, is the real bottleneck of an AI-driven 'software factory,' an engineer's central job is to decide loop by loop how much autonomy each part of the pipeline can earn — full automation ('dark') only where a check is cheap, fast, and hard to fake, human judgment ('lit') everywhere else — with the human's own role relocating from writing code to owning and verifying that outer decision. - What is “loop engineering?” The Pragmatic Engineer · 2026-07-14 Reader 🖥️
“Loop engineering” — designing the orchestration around an AI coding agent (goals, completion checks, state persistence, fresh-context iteration) rather than hand-writing one-off prompts — is a real practice that originated as a DIY workaround (the “Ralph loop”) for small context windows, but by mid-2026 major harnesses had absorbed most of it into a native /goal primitive, so for most developers besides those building AI infrastructure, it is a largely-already-commoditized skill rather than a durable new discipline. - Loop Engineering Addy Osmani · 2026-06-07 Reader 🖥️
Loop engineering means replacing yourself as the person who prompts the coding agent turn-by-turn with a designed system — automations, worktrees, skills, plugins/connectors, and sub-agents, plus externally-persisted state — that prompts the agent for you; but because that system can't distinguish between someone using it to move faster on work they understand and someone using it to avoid understanding the work at all, the engineer's judgement doesn't disappear, it relocates one level up, from prompting to system design, which Osmani argues is harder, not easier.
Propositions touching this concept (20)
By publication month, oldest first (extraction month when no publication date is known).
2026-04
- explicitcorroboratedHarness improvement can be automated as a selection loop: a Claude proposer adds exactly one mechanism per iteration and an outer loop keeps it only if it clearly beats the current best, so accepted mechanisms compound.
2026-06
- explicitcorroboratedLoop engineering is replacing yourself as the person who prompts the agent — you design the system that does the prompting instead.
- explicitdevelopedLoop engineering sits "one floor above" agent-harness engineering: the harness is the environment a single agent runs inside, the loop is the outer system that runs the harness on a timer, spawns little helpers, and feeds itself.
2026-07
- explicitdevelopedAs agentic work industrializes, the human's job moves from writing code to owning the 'outer loop' — deciding whether a proposed fix addresses the right problem, verifying the diagnosis and implementation are sound, approving the change, and bearing the consequences of being wrong — while the agent executes the 'inner loop' of investigation, implementation, and testing.
- explicitcorroboratedA new category of 'supervisory engineering' work — supervising, orchestrating, and evaluating AI output in a 'middle loop' between the automated inner loop of coding and the outer loop of delivery — is emerging, but its skills, career pathways, and even its dignity have not yet been designed.
- explicitAn AI agent is fundamentally an LLM wrapped in two loops: an outer loop that passes messages back and forth to the user (the basis of all AI chatbots), and an inner loop that lets the model choose and run tools — the inner loop is what turns an assistant into an agent.
- explicitMost developers' real-world 'loop engineering' use cases — event triggers and cron-scheduled jobs — are conceptually the same as automation patterns that predate LLMs (webhooks, Zapier, n8n, cron).
- implicitcontested'Loop engineering' as a named discipline may be substantially a rebranding of pre-existing automation and orchestration concepts (cron, triggers, retry-until-pass loops) rather than a genuinely novel engineering skill.
- explicitcontestedThe system loop ('autoresearch') is an outer loop in which the primary system does user-facing work while the outer loop studies and modifies the primary system itself — its prompts, harnesses, model choices, and evals — such that 'the loop is the product.'
2026-08
- explicitLoop engineering is the practice of designing automated control structures that repeatedly invoke coding agents, triggered on a schedule or by events, with each run bounded by a machine-checkable stop condition.
- explicitLoop engineering sits one abstraction level above harness engineering in a four-layer trajectory (prompt → context → harness → loop), where each layer subsumes the previous one and the harness layer refers specifically to the outer harness developers assemble.
- explicitLoop engineering's novelty as a discipline is genuinely contested among practitioners — critics call it 'a renamed cron job' and argue that explicit loop-building will be absorbed into tool vendors' default harness features (e.g., /loop, /goal), making the current explicit practice transitional.
- explicitThe large productivity claims attached to loop engineering (e.g., Stripe's internal 'Minions' system producing ~1,300 agent-written pull requests per week; a loop pointed at Firefox producing 423 security fixes in one month) rest entirely on self-reports and anecdotes, with no published study or dataset the authors could find supporting either figure.
- implicitFraming coding work as a definable, machine-checkable goal -- rather than as a sequence of prompts -- is the pivotal shift that unlocks the further autonomy gains of loop engineering and multi-agent review.
2026-09
- explicit'Loop engineering' means building a system that prompts Claude on your behalf instead of prompting it yourself turn by turn; at Anthropic's scale it only produces value when paired with heavy investment in skills and verification, so autonomously-landed changes can be trusted.
- explicitcorroboratedAs AI shortens the time needed to generate code, the bottleneck in software delivery shifts to the 'outer loop' — the deployment loop, security scans, and governance gates — putting pressure on platform teams to speed up self-service deployment.
- explicitcontestedThe recent wave of '___ engineering' labels (loop engineering, graph engineering) is not wrong so much as it overtheorizes and overexplains practices teams have already been doing since roughly 2024, and risks becoming marketing talk rather than solving delivery problems.
- explicitEngineers must own the outer loop — the accountability for agentic systems (harnesses, loops, fleets, software factories) — and this becomes more true, not less, as more powerful models become available.
- explicitThe shift underway is that agents now run the entire inner execution loop that engineers used to run; engineers correspondingly move to own the outer loop.
- explicitThere are three hidden costs of ceding the outer loop: cognitive surrender (a Wharton study found nearly three-quarters of people accepted a wrong AI answer anyway and felt more confident for having consulted it), cognitive debt (an Anthropic RCT found engineers who leaned on AI scored 17 percentage points lower on a comprehension quiz, 50% vs. 67%), and the orchestration tax (steering, sorting, and verifying agent output does not parallelize with a person's cognitive bandwidth).
Open gaps (14)
- illogicalThe piece argues both that free-running loops are dangerously unstructured (motivating the pivot to explicit graphs) and that short, low-stakes loops (the nightly lint-fix cron) legitimately earn full autonomy without any explicit graph structure — it never reconciles when a loop needs graph-discipline versus when it's fine to run as a pure loop; length and stakes are offered as the answer for automation-worthiness, but that criterion is never explicitly connected back to the separate loop-vs-graph argument.Software Factories, Light and Dark — read next: Read for a unified framework connecting loop-length/stakes-based autonomy criteria with graph/state-machine architecture choices, rather than treating them as two independent recommendations.
- incompleteThe rule of thumb that 'an agent holds up for three to ten steps, then starts losing the thread past twenty' is stated (attributed to Dex Horthy) without any grounding for why that specific numeric range holds, what model or context window it was measured against, or whether it's expected to shift as context windows and context-management techniques improve — it's treated as a durable constant rather than a fast-moving, model-dependent empirical measurement.Software Factories, Light and Dark — read next: Look for benchmark data on agent step-count reliability across model generations and context-management techniques, to see whether this threshold is already stale.
- incompleteThe claim that harnesses must grow in complexity as models improve is not reconciled with the corpus's competing observation (e.g. senior practitioners reportedly prompting agents less and less directly) about whether growing harness complexity is itself migrating into the product/model layer, so that the complexity becomes Anthropic's problem to solve rather than every user's.How Anthropic Builds And How Engineering Will Change Soon | Thariq Shihipar — read next: extract-osmani-loop-engineering and extract-bockeler-harness-engineering on where harness complexity is expected to live over time.
- uninformedNone of the conversation's strong quantitative-sounding claims (the autonomous-change percentage being unmeasured by design, the incident-rate increase, '100 times more testing code,' engineers 'not in the IDE for six months') are backed by cited internal eval or metrics data — they are informal, first-person estimates, despite Anthropic's own emphasis elsewhere in the corpus on evals as the standard of truth for claims about model/practice performance.How Anthropic Builds And How Engineering Will Change Soon | Thariq Shihipar — read next: Any published Anthropic internal engineering metrics or eval results on AI-assisted development adoption and outcomes, to check these estimates against measured data.
- illogicalThe article opens by criticizing '___ engineering' neologisms (loop engineering, graph engineering) as marketing talk that overtheorizes intuitive, already-established practice, then spends its own middle section formalizing 'software factory' into an eight-stage taxonomy with its own new vocabulary (context layer, ADR-plus-glossary as planning output, grill-the-plan) — the piece never explains why 'software factory' escapes the exact critique it levels at sibling terms.Inside a Software Factory — read next: Read against extract-osmani-loop-engineering, which shows the identical pattern (a piece critiquing terminology churn while itself coining new terminology) — useful for testing whether this is a recurring rhetorical feature of the 'next ___ engineering' genre rather than something specific to this author.
- incompleteEvery control in the 7-pillar architecture is justified by first-principles reasoning about non-determinism and by citing named threat patterns (slopsquatting, invisible payloads, Confused Deputy), but no incident data, overhead measurements, or cost-benefit comparison is offered for any proposed control — e.g., no data on how much the 'Vibe Diff' + hardware MFA step actually reduces blind-approval rates versus a simpler gate, or on the operational cost of running a continuous Red/Blue/Green triad alongside every development workflow.Vibe Coding Agent Security And Evaluation — read next: This corpus's own extract-lulla-loop-engineering-building-blocks-adoption-impact documents, for a structurally similar case (loop engineering's prescribed building blocks), that almost none of a comparably detailed practitioner-prescribed architecture shows up as committed, verified practice in real repositories — worth reading against this whitepaper's unverified 7-pillar prescriptions for the same pattern.
- incompleteThe mining study measures public open-source adoption only. The paper itself notes that 'high-volume internal deployments... leave no public trace,' but the headline anecdotes it discusses (Stripe's Minions, 1,300 PRs/week) are exactly such internal deployments. The 0.59% figure is therefore a floor on publicly-visible evidence, not a measure of practice overall, and the paper cannot adjudicate whether loop engineering is genuinely rare or merely rare in public repositories.Loop Engineering: Building Blocks, Adoption, and Impact — read next: An internal-tooling survey or structured practitioner-interview study of enterprise/internal loop adoption (the kind this corpus's Stripe and 'software factory' pieces gesture toward) to estimate private adoption rates that public GitHub mining cannot reach.
- incompleteThe paper documents in detail that almost no prescribed building block (state files, verifiers, budgets, goal conditions) is committed to version control, and raises — but does not test — the alternative explanation that for the loop types actually adopted (PR-review and issue-triage), the issue tracker or PR queue already carries the needed state, making committed state files unnecessary rather than merely unadopted. No comparison of issue-tracker/PR activity against committed-state absence is designed to check this.Loop Engineering: Building Blocks, Adoption, and Impact — read next: A follow-up study correlating confirmed-loop repositories' issue/PR activity patterns against their committed-state presence, to distinguish 'state exists but isn't in Git' from 'this loop type genuinely needs no cross-run state.'
- incompleteThe planned RQ3 controlled experiment explicitly excludes the 'proactive' loop condition (where the agent generates its own tasks), on the grounds that it makes it hard to establish a shared task set for comparison. But the discourse's most consequential value claims — Stripe's Minions, autonomous Firefox vulnerability triage — describe exactly this proactive, self-directed autonomy level. The planned study's eventual causal evidence, even once collected, will therefore not speak to the autonomy level the real-world claims of value are actually about.Loop Engineering: Building Blocks, Adoption, and Impact — read next: Compare against this corpus's other treatments of proactive/autonomous agent delegation (e.g., extract-own-the-outer-loop's 'agency ladder' and extract-human-oversight-is-not-a-human-in-the-loop's conditions for meaningful oversight) for how a study design might capture proactive-loop effects without a fixed shared task set.
- incompleteThe essay proposes an 'accountability contract' (checklist understood, evidence, who's accountable, system status) but never specifies how any of these fields get populated from an actual hour-scale agentic run whose intermediate decisions are, by the essay's own admission, not fully recorded and cannot all be traced back to input tokens — leaving the central operational question (how do you produce the evidence you're claiming to own) unanswered.Own the Outer Loop — read next: Read Osmani's own 'Quality in the Harness' and 'Software Factories, Light and Dark' for the concrete evidence artifacts (tests, static analysis, review gates) he specifies elsewhere, and read agent-governance / decision-provenance literature for concrete audit-trail mechanisms.
- incompleteThe article's evaluative back half (sections 5–7: cost/'tokenmaxxing' disappointment stories, the 'was it just a hack' argument, and the context-engineering conclusion) is paywalled; this extraction only had the one-line table-of-contents previews for that material, not the supporting evidence or full argument.What is “loop engineering?” — read next: Get subscriber access to read the full piece, especially the cost-tradeoff stories in section 5 and the closing argument in section 7 for why context engineering may matter more than loop engineering — directly relevant to the persona's 'rigorous adopter, not hype-follower' stance on AI-agent practice.
- misinformedThe distinction between vibe coding and building agentic applications is drawn too sharply. In practice, development workflow agents (the Discord-to-GitHub-issue agent described) are themselves agentic applications that need evals, blurring the boundary Bhagwat draws.Podcast: Tiger Teams, Evals and Agents: The New AI Engineering Playbook — read next: Inner loop / outer loop development frameworks; the concept of 'dogfooding' applied to AI agent development.
- uninformedLike the two other loop-engineering pieces already in this corpus, this piece offers no measurement of actual outcomes for any of its four-plus tiers — no data on defect rates, cost, review time, or throughput at any level. The concrete numbers it does cite (Karpathy's 630 lines, Warp's 20%-to-60% merge-rate ratchet, Anthropic's 65% figure) describe adoption or scale, not quality or net productivity, yet the whole taxonomy is built on top of these anecdotes and quoted authority.What the Hell Is a Loop, Anyway? — read next: Any empirical study comparing outcomes (defect rate, review burden, time-to-ship) across loop tiers rather than adoption percentages.
- incompleteThe piece never addresses what makes a goal 'verifiable' for genuinely ambiguous coding work. The demoed task (a package resolver) already had existing tests to check against -- a ready-made oracle. A large share of real coding work lacks that: the article gives no guidance for defining a verifiable goal when there is no pre-existing test suite or spec precise enough to check against mechanically.Zero to Agent in 30 Minutes: From Prompting to Loop Engineering with Ofer Mendelevitch — read next: extract-pragmatic-engineer-loop-engineering (on what a 'well-engineered' loop's completion criterion actually is) and extract-osmani-loop-engineering#p11 (verification remains a human responsibility even inside a well-designed loop, and 'done' is a claim the loop makes about itself, not a proof).