Loop Engineering
Loop engineering is the practice of defining repeatable AI workflows where automation assigns tasks, the loop executes bounded actions, evidence is checked every iteration, and a clear stopping condition controls when to continue or hand back to the engineer.
As model prompts grow more capable, the bottleneck shifts from writing one good prompt to managing many iterations safely. A loop reduces context drift and manual re-prompting by separating planning, execution, and verification into explicit surfaces.
Addy Osmani defined the shift directly in his June 7, 2026 essay and described it as a loop above agent harnesses. He cites Peter Steinberger’s prompt-then-harness framing, then details five loop pieces and one memory layer, including automation, worktrees, skills, plugins/connectors, and sub-agents. OpenAI Codex docs and cookbook show recurring thread workflows, goal mode, and durable project settings such as Automations, worktrees, skills, and /goal-like loop controls. Anthropic Claude Code docs formalize the same pattern: `/goal` keeps running with a separate evaluator until a condition is met.
- Treat /goal and scheduled automations as execution primitives, then design the control contract around them.
- Design the stopping condition first, then design the loop mechanics.
- Persist project state outside context windows so long loops can resume safely.
- Use worktree isolation and separate checker roles to reduce collision and over-trust.
- Loop quality is mostly governance quality: constraints, reviewers, evidence, and handoff clarity.
Loop engineering treats an AI agent as a worker inside a control system, not as the system itself. Instead of prompting every turn, you build a loop that keeps selecting the next step, executing it, checking evidence, and then deciding whether to continue.
- You design repeatable behavior before prompting, then let the loop run the mechanics.
- Each iteration should reduce uncertainty and produce measurable state changes.
- A loop should fail clearly: blocked, out of scope, budget exceeded, or stopped by policy.
A practical loop often contains five recurring parts plus external memory: scheduled discovery, file/worktree isolation, project knowledge files, connector/plugins integration, and role-separated sub-agents.
- Automations discover issues on schedule and queue work.
- Worktrees isolate parallel work and avoid file-level collisions.
- Skills capture reusable context and conventions outside the short window.
- Plugins/MCP connectors let the loop act on tickets, staging, and messaging systems.
- Sub-agents split maker/checker responsibilities while the loop carries the objective.
- Persistent memory files (or equivalent) keep what must survive context reset.
Loop engineering is not a promise of autopilot quality. It is a governance layer. Without explicit quality gates, bounded tasks, and external review, an infinite loop can still produce low-quality or dangerous changes.
- The loop can increase throughput, but not automatically increase correctness.
- Maker-checker split and test gates are required inside long-running workflows.
- Verification and stop criteria are the loop’s control valves, not optional niceties.
The strongest loop design starts from conditions, not prompts. A condition must be measurable and checkable from transcript evidence or tests, and the loop should include explicit budget or turn limits.
- Ask for explicit finish lines such as “all tests pass”, “CI green”, or “issue queue empty”.
- Limit iteration count, token spend, and runtime to avoid unbounded compute.
- Pause or reassign work when the same error repeats, rather than waiting for accidental recovery.
A harness is the runtime surface for one agent; loop engineering is the orchestration control plane across agents and iterations. The two are complementary, and a strong workflow needs both.
Agent system that exposes teams and automation flows built around sub-agents, skills, and scheduling.
Terminal coding agent with sub-agents, hooks, permissions, and loop-oriented workflow controls.
Open-source coding agent platform with plan/build roles, install surfaces, and desktop/terminal loop workflows.
Team runtime that emphasizes sandboxes, integrations, and orchestration for repeated AI workflows.
The runtime layer around one agent; loop engineering adds the repeated execution control above it.
Local and self-hosted agents that often rely on stronger loop controls for quality and cost control.
Reusable skills and sub-agent instructions become high-risk inputs in long-running loops.
The production-risk gap that loop-based quality gates are designed to narrow.
Source confidence
Addy Osmani
X / Peter Steinberger
X / Addy Osmani
OpenAI Developers
OpenAI Cookbook
OpenAI Developers
Anthropic
Reddit / r/ClaudeCode
Loop Engineering FAQ
Page-level questions for Loop Engineering.
What is the practical difference between loop engineering and prompt engineering?+
Prompt engineering optimizes one-turn instruction quality. Loop engineering optimizes repeated execution: task selection, state, validation, and stop conditions across many turns.
Does using /goal remove my review responsibility?+
No. /goal and similar loop primitives reduce mechanical prompting, but production safety still needs explicit human review gates, test/lint checks, and a decision rule for when to stop.
How should a loop stop safely?+
Use measurable finish lines (tests green, CI green, or an empty issue queue), plus hard limits on turns, tokens, and retries. Add a manual block path for repeated errors or external blockers.
Why do loops help with context overflow?+
If state is persisted outside context (for example, task files or AGENTS.md), each iteration can start from a clean window while preserving progress and constraints.
What is the first thing to change in a current workflow?+
Convert “keep telling the agent what to do” into one measurable objective, then add explicit check logic and a fail-stop condition before expanding automation.