Skip to content
Search

Loop Engineering

lastmod 2026-08-20created 2026-06-147 edits

Designing systems that prompt agents

About

  • A shift away from prompting a coding agent directly every turn, toward a way of working where you design a system that prompts the agent for you
  • A loop is a recursive goal: you define the objective and the AI iterates until it is done; it consists of about five components
  • The five components are Automations, Worktrees, Skills, Plugins·connectors, and Sub-agents; both Claude Code and Codex now have all five
  • The sixth component, memory, is a markdown file or Linear board that stores state outside a single conversation, compensating for a model that forgets on every run
  • Still early; watching token costs is essential, and verification and understanding are still up to humans (build the loop, stay the engineer)

Definition and background of loop engineering

  • Loop engineering means replacing yourself, the person who prompts the agent, with a system, and designing the system that does that job yourself
    • A loop is a recursive goal: you define the objective and the AI iterates until it is done
    • It may be the future way of working with coding agents, but it is still early and watching token costs is essential (usage patterns differ greatly depending on whether you are token rich or poor)
  • Quotes
    • Peter Steinberger "Stop prompting coding agents; design the loops that prompt the agents"
    • Boris Cherny (head of Claude Code at Anthropic) "I no longer prompt Claude. I run loops that prompt Claude and decide what to do. My job is writing the loops"
  • For the past two years or so, the approach was to give a good prompt and enough context and hold the agent directly as a tool, going back and forth one turn at a time, but that approach is coming to an end
  • Now you build a small system that finds and dispatches work, verifies it, records what is done, and decides the next task, and let that system poke the agent
    • Sits above the earlier posts' agent harness engineering (the environment one agent runs in) and factory model (the system that builds software)
    • A harness that runs on a timer, spawns small helpers, and feeds itself
  • It is no longer a tooling problem — a year ago, if you wanted a loop you had to write and maintain a pile of bash yourself, but now the components ship built into the products
    • Steinberger's list matches the Codex app almost exactly and is nearly identical to Claude Code too, so instead of arguing over which tool, design a loop that works in either

The five components of a loop, plus memory

  • A loop needs five things, plus one place to remember state
    • Automations — fire on a schedule and perform discovery and triage on their own
    • Worktrees — keep two agents working in parallel from colliding with each other
    • Skills — record the project knowledge the agent would otherwise fill in by guessing
    • Plugins·connectors — connect the agent to the tools you already use
    • Sub-agents — one side proposes ideas and the other verifies them
  • The sixth is memory: lives outside a single conversation, such as a markdown file or Linear board, and holds what is done and what comes next
    • Looks too simple, but it is the same trick every long-running agent relies on (earlier post: long-running agents)
    • The model forgets everything between runs, so memory must be on disk, not in context — the agent forgets, but the repo does not
  • Both products now have all five; only the names differ slightly, the capabilities are the same

Automations — the heartbeat of the loop

  • Automations are what turn a loop into an actual loop rather than a single run
    • In the Codex app you create one in the Automations tab, choosing the project, the prompt to run, the frequency, and whether to use the local checkout or a background worktree
    • Runs that find something go to the Triage inbox, and runs that find nothing archive themselves
    • OpenAI uses them internally for boring work such as daily issue triage, summarizing CI failures, writing commit briefings, and hunting bugs added last week
    • Automations can call skills, so instead of pasting a giant wall of instructions you invoke $skill-name, keeping recurring work maintainable
  • Claude Code reaches the same point with scheduling and hooks
    • /loop runs a prompt or command at a fixed interval; you can schedule cron jobs and fire shell commands with hooks at specific points in the agent lifecycle
    • To keep it running after you close your laptop, you can hand the whole thing off to GitHub Actions
  • There is a second in-session primitive, a feature close to the heart of this post
    • /loop reruns on a fixed cycle
    • /goal keeps going until the condition you wrote actually becomes true; after every turn a separate small model checks whether it is done, so the agent that wrote the code does not become the grader
      • e.g., give a condition like "all tests in test/auth pass, lint clean" and walk away
    • Codex provides /goal in the same way, working turn after turn until a verifiable stop condition holds, and supports pause·resume·clear

Worktrees — so parallelism does not become chaos

  • The moment you run more than one agent, files start colliding; this is the point of failure
    • Two agents writing the same file is the same headache as two engineers committing the same line without talking to each other
    • git worktree solves this — each is a separate working directory on its own branch while sharing the same repo history, so one agent's edits cannot touch the other's checkout
  • Codex has built-in worktree support, so multiple threads can touch one repo at the same time without clashing
  • Claude Code provides the same isolation with git worktree, the --worktree flag that opens a session in its own checkout, and the isolation: worktree setting attached to a subagent (each helper gets a fresh checkout that cleans itself up when finished)
  • Worktrees remove mechanical conflicts, but you are still the ceiling — how many you can actually run is decided by your own review bandwidth, not by the tool (earlier post: the orchestration tax)

Skills — so you do not re-explain the project every time

  • Skills are how you stop re-explaining the same project context every session like a goldfish
    • Both tools use the same format — a folder containing a SKILL.md with instructions and metadata, plus optional scripts, references, and assets
    • Codex invokes them with $ or /skills, or runs them on its own when a task matches the skill description, so a concise, boring description is better than a clever one
    • Claude Code works the same way (earlier post: agent skills)
  • Skills are where intent stops being a recurring cost
    • An agent starts every session cold and fills gaps in intent with confident guesses (earlier post: the intent debt)
    • A skill is that intent written down externally — write conventions, build steps, and things like "we don't do it this way because of that incident" once, and the agent reads them on every run
    • Without skills the loop re-derives the whole project from zero every cycle; with them it accumulates and compounds
  • A skill is the authoring format and a plugin is the distribution method — package as a plugin to share across or bundle for multiple repos (same in both Codex and Claude Code)

Plugins·connectors — so the loop reaches real tools

  • A loop that can only see the file system is a small loop
    • MCP-based connectors let the agent read the issue tracker, query the DB, call the staging API, and send Slack messages
    • Both Codex and Claude Code speak MCP, so a connector for one usually works as-is in the other
    • A plugin bundles connectors and skills so a colleague installs it all at once instead of rebuilding the whole thing from memory
  • This is the difference between an agent that says "here is a fix" and a loop that opens a PR, links the Linear ticket, and pings the channel when CI goes green
    • Connectors are why the loop acts inside the real environment instead of merely talking about possibilities

Sub-agents — separate the maker from the checker

  • By far the most useful structure in a loop is separating the side that writes code from the side that checks it
    • The model that wrote the code is too lenient when grading its own homework
    • A second agent with different instructions, and sometimes a different model, catches what the first one talked itself into
  • Codex spawns subagents only when asked, runs them concurrently, then merges the results into a single answer
    • Define your own agents as TOML files in .codex/agents/ (name·description·instructions, optional model·reasoning effort)
    • e.g., a security reviewer on a strong model with high effort, an explorer on a fast read-only model
  • Claude Code handles the same with subagents in .claude/agents/ and agent teams that pass work back and forth
    • The usual split in both tools is one agent explores, one implements, and one verifies against the spec (earlier posts: the code agent orchestra, adversarial code review)
  • The loop runs while you are not watching, so you can only walk away if there is a trustworthy verifier
    • Each subagent does its own model and tool work, so it consumes more tokens; use them where a second opinion is worth it
    • This is also what Claude Code's /goal does internally — a fresh model judges completion instead of the side that did the work, applying the maker·checker split to the stop condition itself

What a single loop looks like

  • Put together, a single thread turns into a small control panel; one shape used repeatedly
    • An automation runs on the repo every morning; its prompt calls a triage skill that reads yesterday's CI failures, open issues, and recent commits, and records the results in a markdown file or Linear board
    • For each item worth doing, the thread opens an isolated worktree and has a sub-agent draft a fix, and a second sub-agent reviews that draft against the project skills and existing tests
    • Connectors let the loop open PRs and update tickets; whatever the loop cannot handle goes into the triage inbox
    • The state file is the backbone of the whole thing — it remembers what was tried, what passed, and what is still open, so the next morning's run picks up where today's stopped
  • The key point is that you prompted none of those steps; you designed them once — whether Codex or Claude Code, the components are the same, so it is the same loop

What the loop still does not do for you

  • The loop changes the work but does not erase the person; in fact, there are three problems that get sharper the better the loop gets
  • Verification is still your job
    • A loop that runs unattended is also a loop that makes mistakes unattended
    • The reason to separate the verifier sub-agent from the maker is to give the loop's "finished" some meaning, but even so "done" is a claim, not proof (earlier post: code review in the age of AI — the job is shipping code you have confirmed works)
  • Understanding rots if neglected
    • The faster the loop ships code you did not write yourself, the wider the gap between what exists and what you actually understand
    • This is comprehension debt; a smooth loop widens that gap faster if you do not read what the loop made
  • The comfortable posture is the dangerous posture
    • When the loop runs on its own, it is easy to stop having opinions and just accept whatever comes back (cognitive surrender)
    • Loop design is a cure when done with judgment and an accelerant when done to avoid thinking — same action, opposite outcome

Build the loop, but stay the engineer

  • It looks like a preview of how work is evolving, but if you do not review code yourself or rely only on automated loops, product quality drops and you can get trapped in a downward spiral, falling into an ever-deeper hole
  • Set up loops, but prompting the agent directly is still effective; the key is finding the right balance
  • Loops produce opposite results depending on the person — of two people who build the same loop, one uses it to do work they deeply understand faster, the other uses it to avoid understanding the work
    • The loop does not know the difference, but you do
  • This is why loop design is not easier than prompt engineering but harder — Cherny's point is not that the work got easier but that the leverage point moved
  • Conclusion: build the loop, but build it like someone who will stay the engineer, not just someone who presses the start button

See also

Favorite site

author Zer0 sitemap