Loop Engineering Explained: Designing Loops That Prompt Your Coding Agents

The short answer

Loop engineering is designing the system that prompts your coding agent, so you stop being the person who types the next prompt. The system finds work, hands it out, checks the result, writes down what is done and decides what comes next. Addy Osmani, whose June 2026 post popularized the term for coding agents, says the pieces now ship inside the products: scheduled automations, worktrees, skills, connectors and subagents, plus a file that remembers state. Claude Code and Codex both document most of them.

Three cautions run through every source we read. First, a loop that runs unattended also makes mistakes unattended, so verification stays your job. Second, loops spend tokens in ways a single prompt does not, and Osmani himself says he is sceptical and that you have to be careful about cost. Third, the term is young: it comes from a handful of June to July 2026 posts, a DeepLearning.AI course and an IBM explainer, not from a standard or a vendor spec. Where a claim is Osmani’s, IBM’s or LangChain’s, we say so, and where a feature is confirmed in a vendor doc, we link the doc.

This guide is built from Osmani’s post (dated June 7, 2026), LangChain’s “The Art of Loop Engineering” (June 16, 2026), IBM’s explainer (July 17, 2026) and the DeepLearning.AI course (updated October 29, 2026), then checked against the Claude Code, Claude Agent SDK, Codex, OpenAI Agents SDK and LangGraph docs. We did no hands-on testing of the commands below beyond reading their documentation, and we give no dollar costs because we did not measure any. Everything is as of October 30, 2026.

What loop engineering is

Osmani’s opening line is the shortest definition: loop engineering is replacing yourself as the person who prompts the agent, and designing the system that does it instead. He quotes Peter Steinberger (“You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”) and Boris Cherny, head of Claude Code at Anthropic (“I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops”). Both quotes come through Osmani’s post; we did not locate the original statements.

For about two years, he writes, you got value from a coding agent by writing a good prompt, reading what came back and typing the next one, holding the tool the whole time. A loop replaces that hand-holding with a small system that finds the work, hands it out, checks it, writes down what is done and decides the next thing. In his words, a loop can be thought of as a recursive goal: you define a purpose and the AI iterates until it is complete.

IBM’s explainer gives the same idea an academic shape. It defines loop engineering as the practice of designing agentic workflows that iteratively guide AI agents toward user-defined goals with minimal human intervention, and it describes a standard cycle of four stages:

IBM adds a point worth underlining: a good goal also controls token cost, because it prevents unnecessary iterations. “Make my website load faster” is vague, while a measurable stopping condition gives the agent something it can verify. That sentence is the seed of most of the practical advice below.

Loop vs prompt, context, harness and spec-driven engineering

Searches for this topic often pair loop engineering with four neighbouring terms. They are not rivals; they sit at different altitudes. The table orders them from the smallest unit of work to the largest.

The relationships come from the sources. IBM draws the prompt line: prompt engineering is suited to one-off interactions or single model calls, while loop engineering suits long-running agents handling autonomous code generation, maintenance or multi-step work. IBM also lists context engineering as one component inside a loop, since each cycle generates data that feeds the next, and it warns that excessive context reduces relevance and raises cost. Osmani places loop engineering one floor above the harness, describing a loop as the harness that runs on a timer, spawns helpers and feeds itself. IBM mentions agent harness engineering as the practice of designing complete execution environments around an agent.

Spec-driven development is the one row the four primary sources do not define, so treat that row as our framing. The natural fit is that a spec supplies the “definition of done” a loop needs: a goal condition is only as good as the acceptance criteria behind it. Our spec-first development post covers the planning side, and Codex’s own use-case page says a good goal tells the agent what to achieve, what not to change, how to validate and when to stop, which is a spec in miniature.

LangChain’s four loops

LangChain’s post, written by Sydney Runkle, approaches the topic from agent building rather than from the coding-assistant seat. It credits swyx’s idea of “loopcraft” and stacks four loops, each wrapping the one inside it. The same framework is taught in the DeepLearning.AI course, whose instructors are Runkle and Esmaeil Gargari.

Two details are useful. The verification loop’s grader can be deterministic (run tests, check that links resolve) or agentic, such as an LLM acting as judge, and LangChain says plainly that verification increases latency and cost per run. The fourth loop is the one most coding-agent users have not built: it analyses traces across runs and files changes against the prompt, tool or grader, so each outer cycle makes the inner loops better. LangChain’s advice is that focus should shift from loops 1 and 2 toward loops 3 and 4, where value compounds. That is a vendor’s view; LangChain sells the tooling it names.

The DeepLearning.AI course is listed as eight lessons with four code examples, and it applies the loops to a requirements-review agent rather than a coding agent. Its learning outcomes mirror the stack: build an agent loop, add a verification loop with an evaluator and explicit criteria, trigger the agent from events such as a Slack message or Jira ticket, and analyse traces to improve the harness.

Five pieces mapped to Claude Code and Codex

Osmani’s version is built for the coding-assistant seat. A loop needs five things and one place to remember stuff: automations, worktrees, skills, plugins and connectors, and subagents, plus memory. His table maps them to the Codex app and Claude Code. We re-checked each mapping against the vendors’ own documentation and kept only what the docs confirm. Where Osmani’s wording differs from the current docs, the last column says so.

The pieces, one by one

Automations: the heartbeat

In Claude Code, the scheduling page lists three ways to run recurring work. Cloud tasks run on Anthropic-managed infrastructure without your machine and have a one-hour minimum interval. Desktop tasks run on your machine with local files. /loop runs inside an open session, with a one-minute minimum, and inherits the session’s permissions and MCP servers. A bare /loop runs a built-in maintenance prompt that continues unfinished work, tends the current branch’s pull request (review comments, failed CI, merge conflicts) and runs cleanup passes; you can replace it with your own .claude/loop.md. Session loops are not durable: recurring tasks expire after seven days, and tasks only fire while Claude Code is running and idle. For unattended work the page points to cloud scheduled tasks, GitHub Actions or Desktop scheduled tasks.

In Codex, scheduled tasks run in the background in the ChatGPT desktop app. For Git repositories you choose between your local project and a new worktree; the docs warn that local mode can modify files you are still working on. Runs with findings land in a Scheduled view that works as an inbox. They run unattended with your default sandbox settings, and the docs advise starting with the narrowest access that lets the task succeed. Project-scoped tasks need the machine on and the app running. A scheduled task can call a skill, so you keep the recurring instruction in one maintainable place instead of pasting a long prompt into a schedule nobody updates.

Both tools also have an in-session primitive that matters more to loop design than a timer: a goal that runs until a condition is true. Claude Code’s /goal sets a completion condition, and after each turn a separate model checks whether it holds. The docs stress that completion is decided by a fresh model rather than the one doing the work. Codex’s /goal works toward one durable objective with pause, resume and clear. Osmani notes that both tools ship the same primitive under the same name, which is the pattern of his whole article.

Worktrees: parallel without collisions

Two agents writing the same file is the same problem as two engineers committing to the same lines. A Git worktree gives each agent a separate working directory on its own branch, sharing one repository history. Claude Code’s common-workflows guide shows claude --worktree feature-auth, and the subagents doc says isolation: worktree runs a subagent in a temporary worktree that is cleaned up automatically if the subagent makes no changes. Codex’s worktree docs describe the same Git mechanism, with a Handoff flow that moves a chat between your local checkout and a worktree, and a note that Git only lets a branch be checked out in one place at a time.

Osmani’s caution is the human one: worktrees remove the mechanical collision, but your review bandwidth decides how many parallel agents you can actually run. That is his claim, not something the vendor docs address.

Skills: stop re-explaining the project

A skill is a folder with a SKILL.md plus optional scripts and references. Claude Code loads a skill’s body only when it is used, so long reference material costs little until needed, and you can invoke one with /skill-name. Codex starts with each skill’s name, description and path and loads the full instructions only when it decides to use the skill. Because implicit matching depends on the description, the Codex docs advise short descriptions with clear scope and front-loaded trigger words. For a loop, the benefit is that every cycle starts from your written conventions instead of re-deriving them. Our agent skills guide goes deeper on authoring.

Plugins and connectors: reach your real tools

A loop that only sees the filesystem is a small loop. Osmani says connectors, built on MCP, let the agent read an issue tracker, query a database, hit a staging API or post to Slack, and that plugins bundle connectors and skills for sharing. The docs we read confirm the plumbing in pieces: scheduled Claude Code tasks inherit or configure MCP servers, Codex scheduled tasks can use plugins and skills, and Codex custom agent files can carry mcp_servers. IBM lists MCP servers alongside other APIs as the usual way loops get tool access, noting that without tools an agent can only describe what it would do. For the approval implications of giving a loop write access to real systems, see the human-in-the-loop section below.

Subagents: keep the maker away from the checker

The most useful structural idea in the whole approach is splitting the writer from the checker. Osmani argues the model that wrote the code grades its own homework too kindly, and a second agent with different instructions, sometimes a different model, catches what the first talked itself into. Claude Code defines subagents in .claude/agents/ with frontmatter that includes tools, model, permissionMode, hooks, skills, background and isolation. Codex defines custom agents as standalone TOML files under .codex/agents/ and allows keys such as model, model_reasoning_effort, sandbox_mode, mcp_servers and skills.config, which lets a reviewer run on a stronger model than an explorer. A common split is one agent explores, one implements, one verifies against the spec. The /goal evaluator applies the same maker and checker split to the stop condition itself.

If you want the multi-agent side in a different tool, our Antigravity agent orchestration guide covers orchestrating several agents in Google’s editor.

State: the file that remembers

Osmani calls the sixth piece memory: a markdown file, a Linear board, anything that lives outside the single conversation and holds what is done and what is next. His reasoning is that the model forgets everything between runs, so the memory has to sit on disk, and as he puts it, the agent forgets but the repo does not. This is the one piece neither vendor documents as a loop feature, so there is nothing to look up: you pick the format and keep it short enough to be read at the start of every run.

What one loop looks like

Osmani’s worked example is a morning loop on a repository. An automation runs every morning. Its prompt calls a triage skill that reads yesterday’s CI failures, open issues and recent commits and writes findings into a markdown file or Linear board. For each worthwhile finding, the thread opens an isolated worktree, sends one subagent to draft a fix and a second to review the draft against the project skills and existing tests. Connectors open the PR and update the ticket. Anything the loop cannot handle lands in your inbox. The state file records what was tried, what passed and what is still open, so tomorrow’s run picks up where today’s stopped.

The useful observation is what you did: you designed the loop once and prompted none of those steps. Because the pieces are the same in Codex and Claude Code, he argues the loop survives a change of tool. We have not run this exact loop, so read it as a design pattern, not a benchmarked recipe.

Build your first loop

A conservative path for a first loop, assembled from the docs above. Start small, bound everything and read the output yourself.

1. Write the stopping condition first. One measurable end state, one check that proves it and any constraint that must not change. Claude Code’s docs give the shape: one measurable end state, a stated check such as npm test exits 0, and constraints such as no other test file modified. Codex’s page says the same: name one objective and one stopping condition.
2. Pick the trigger that matches the work. A time interval fits polling a deploy or a pull request. A condition fits a migration or refactor with tests. An event fits CI failures or tickets. A cron schedule fits daily triage.
3. Isolate each run. Use a worktree so a loop never edits the checkout you are working in. Codex’s docs say worktrees keep scheduled-task changes separate from unfinished local work.
4. Move recurring instructions into a skill and call the skill from the schedule, so the prompt stays one line and the knowledge stays editable.
5. Separate the maker from the checker. Use a subagent, a second model or a deterministic check such as tests and lint. A Stop hook in Claude Code can run a script for deterministic checks after each turn.
6. Choose a state file and tell the loop to read it first and update it last.
7. Set the approval posture and a spend cap before you walk away. Decide which actions pause for a human and which are allowed; see the next sections. Put a turn or time limit in the goal.
8. Review on a fixed cadence. Read the diffs and the state file yourself, daily at first.

Examples of the two in-session primitives, using the syntax shown in the docs:

# Claude Code: run until a condition holds, with a turn bound
/goal all tests in test/auth pass and the lint step is clean, or stop after 20 turns

# Claude Code: poll on an interval inside a session
/loop 15m check CI on this branch and address new review comments

# Codex: enable the goal command if it is missing, then set a goal
[features]
goals = true
# or: codex features enable goals

In Claude Code, a goal does not change your permission mode. The goal docs say that to let goal turns run unattended you run /goal in auto mode; in Manual mode Claude still asks before tool calls your settings do not already allow. That one sentence is the bridge to the next section.

Human-in-the-loop vs human-on-the-loop

Loop engineering does not remove humans; it changes where they sit. We use two labels. Human-in-the-loop means the run pauses at a specific action until a person approves, edits or rejects it. Human-on-the-loop means a person supervises from outside the run, reading diffs, state files and reports after the fact and stopping the loop if it drifts. The second label is our shorthand; the primary sources do not define it, although IBM argues that even robust loops require human involvement and LangChain lists four places where oversight belongs.

Claude Code: permission modes and the SDK callback

The permissions doc lists the modes: default (labeled Manual in the CLI) prompts on first use of each tool, acceptEdits accepts file edits and common filesystem commands in the working directory, plan explores without editing source files, auto runs without routine prompts while a background classifier checks actions such as shell commands and network requests against your request, dontAsk auto-denies anything that would prompt, and bypassPermissions skips prompts except for actions no mode auto-approves. Each step along that list moves you from in-the-loop toward on-the-loop, and each carries more risk if the loop goes wrong.

If you build your own app on the Agent SDK, the approvals doc describes a canUseTool callback that fires when Claude needs permission for a tool or asks a clarifying question through AskUserQuestion. Execution stays paused until your callback returns, and the callback can stay pending indefinitely. If a human might take longer than your process can stay alive, the doc recommends a PreToolUse hook that returns the defer decision so the process can exit and resume later from the persisted session. It also notes that the callback never fires for auto-approved tools, so logic that must apply to every call belongs in a PreToolUse hook, and that a PermissionRequest hook can send Slack, email or push notifications when Claude is waiting. That last one is a practical way to make an unattended loop ping you only when it needs a decision.

OpenAI: approvals as interruptions

The OpenAI Agents SDK models human-in-the-loop as a pause. A tool declares needs_approval as True or as an async function that decides per call. When approval is needed, execution pauses and the run result contains interruptions; you convert the result to a RunState, call state.approve(...) or state.reject(...) and resume the original run. The state can be serialized so a run can wait for a person across process restarts. Two details deserve attention in a loop. Callable approval rules fail closed: if arguments are missing or malformed, the call requires manual approval. And for local shell and apply_patch tools, sticky decisions made with always_approve=True match the tool type and name rather than the owning agent, so after a handoff one agent’s blanket approval can apply to another agent’s tool of the same name. In a multi-agent loop, avoid sticky approvals for shell and file edits. Our OpenAI Agents Python SDK guide compares the SDK with LangGraph and CrewAI.

A practical rule

Put a human in the loop for actions you cannot undo or that touch shared systems, and a human on the loop for everything that lands in a worktree and a pull request you will review. If you cannot say which category a step belongs to, treat it as in-the-loop until you can. Our Claude Code Remote Control guide is relevant if you want to answer approval prompts from a phone while a loop runs.

Where LangGraph fits

Claude Code and Codex give you ready-made loop pieces. LangGraph is for the other case: you are writing the agent yourself in Python and need durable pause and resume. It does not replace the ideas above; it is one way to implement them.

LangGraph’s interrupts pause graph execution at a point you choose and wait for external input. When you call interrupt() in a node, LangGraph saves graph state through its persistence layer, returns a JSON-serializable value to the caller and waits indefinitely until you resume with Command(resume=...). You need a checkpointer (a persistent one in production) and a thread_id, which the docs describe as your persistent cursor. One behaviour to design around: when resumed, the node restarts from its beginning, so code before the interrupt() runs again. Unlike static breakpoints, which pause before or after specific nodes, interrupts can be placed anywhere and can be conditional.

On top of that, LangChain’s human-in-the-loop middleware checks each tool call against a policy and offers four decisions: approve, edit, reject and respond. The docs say to use reject to deny an action and respond only when the human is acting as the tool, such as answering an ask-user prompt, because a respond message is treated as a successful tool result. An interrupt_on mapping decides which tools pause, and a when predicate can gate interrupts on the call’s arguments, for example pausing only writes outside the workspace.

Map that back to LangChain’s four loops. LangGraph persistence underpins the agent loop’s approval points and the human-as-grader variant of the verification loop; the event-driven and hill-climbing loops use LangSmith tooling. For orchestration beyond agents, such as scheduled data pipelines, see our AI and ML orchestration tools comparison. If you are driving Claude Code or Codex directly, you probably do not need LangGraph for a first loop.

Token cost warnings

Osmani says you have to be careful about token costs and that usage can vary wildly depending on whether you are token rich or poor. We found no public numbers for what a typical loop costs, and we did not measure, so the table lists the cost levers the sources and docs actually name rather than dollar figures.

Notice the pattern. The cheapest controls are the ones that run no model at all: a stop clause, an expiry, a deterministic test, a hook. The expensive ones, such as fresh-model evaluators, subagents and fan-out, buy quality. Spend there on purpose. If your plan or subscription caps usage, a loop that runs while you sleep is also a loop that can consume your quota before you wake, so check how your plan meters usage before you schedule anything.

What the loop does not do for you

Osmani lists three problems that sharpen as loops improve. Verification is still on you: a loop running unattended makes mistakes unattended, and even a separate verifier’s “done” is a claim, not a proof. Understanding rots: the faster the loop ships code you did not write, the larger the gap between what exists and what you understand. IBM names this comprehension debt, the gap between the amount of code in a system and the degree to which humans understand it, and notes it accrues silently when code passes its automated tests. The comfortable posture is dangerous: Osmani calls taking whatever the loop returns cognitive surrender. IBM adds intent debt, the loss of recorded rationale, which agents.md and skill files are meant to prevent.

His closing point applies to every practice in this guide: two people can build the same loop and get opposite results, one moving faster on work they understand and the other avoiding understanding the work. The loop does not know the difference. He also says that prompting an agent directly remains effective and that the aim is balance, not full automation.

Claim and evidence table

Limitations of this guide

• We read documentation and posts; we did not run the loops, so no performance, quality or cost result here is measured.
• Loop engineering has no standard definition. The sources emphasize different things: Osmani the coding-assistant primitives, LangChain the agent-building stack, IBM the cycle and governance.
• LangChain and DeepLearning.AI present a framework that leads to LangChain products. We report the framework and label the tool names as vendor choices.
• Vendor docs change quickly. Osmani’s table uses names such as Automations tab and Triage inbox that OpenAI’s current page renders as scheduled tasks and Scheduled. Command availability can depend on version, plan and feature flags; check your own installation.
• We did not locate first-party posts from Steinberger or Cherny, so no X posts are embedded and the two quotes are secondhand.
• Subagent and loop token costs are described qualitatively. We found no published per-loop figures, so we give none.

Verdict

Loop engineering is a useful name for something developers were already doing with scripts and cron jobs: moving the point of control from the prompt to the system around it. The practical value is the checklist. Give every loop a measurable stop condition, a trigger, an isolated workspace, a written-down body of project knowledge, a separate checker, a state file, and a decision about where a human approves and where a human merely reviews.

Start with one low-risk loop, such as a goal-bound test fix in a worktree or a scheduled triage that only writes a report. Watch the token spend, read what it produces, and widen it only when the output earns trust. Osmani’s own conclusion is the right one to end on: build the loop, but build it like someone who intends to stay the engineer.

FAQ

Sources

Sources checked October 30, 2026.

• Loop Engineering, Addy Osmani, June 7, 2026 (five pieces, Codex and Claude Code mapping, risks)
• The Art of Loop Engineering, Sydney Runkle, LangChain, June 16, 2026 (four loops, human oversight points)
• What is loop engineering? IBM, July 17, 2026 (definition, loop stages, components, risks)
• Loop Engineering with LangChain Deep Agents, DeepLearning.AI (course outline, updated October 29, 2026)
• Claude Code docs: scheduled tasks and /loop, /goal, subagents, permissions, skills, common workflows and hooks
• Claude Agent SDK: handle approvals and user input
• OpenAI Codex docs: follow a goal, scheduled tasks, worktrees, skills and subagents
• OpenAI Agents SDK: human-in-the-loop
• LangGraph interrupts and LangChain human-in-the-loop middleware

Related reading: Claude Code best practice guide, Agent orchestration in Antigravity, OpenAI Agents Python SDK deep dive and AI and ML orchestration tools compared.