Loop Engineering With AI Coding Agents: A Practical Guide From Hermes Agent

Loop Engineering —also known as loops engineering— is the design of autonomous systems that discover work, dispatch it to coding agents, verify the results and document everything — with no human intervention at every step. In essence, loop engineering —what it is and how it works— replaces manual prompting with an autonomous system that discovers, executes and verifies work. Instead of writing manual prompts turn by turn, you build a loop that runs in the background and keeps the rhythm on its own. It's the difference between operating the machine and designing the factory.

The term was coined by Peter Steinberger (@steipete), creator of Hermes Agent, and developed further by Boris Cherny (@bcherny), head of Claude Code at Anthropic. Addy Osmani, Director of Google Cloud AI, has also written about loop engineering and his vision of the 5 building blocks — automations, worktrees, skills, connectors and sub-agents. I explored both visions in detail there, and why they matter.

A well-designed loop combines five building blocks: automations, worktrees, skills, connectors and sub-agents — plus external memory that survives between runs. What follows is how each one works.

Two years ago, the way to get something out of a coding agent was to write a good prompt and share enough context. Today the pendulum has swung toward the agentic model: instead of guiding the agent step by step, you design a loop that guides it on its own. You write something, read what comes back, write the next thing. The agent is a tool and you're the one holding it the whole time, turn after turn. That stage is over — or at least some people think it's going to be.

@steipete said recently: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." And @bcherny, head of Claude Code at Anthropic, went further: "I don't prompt Claude anymore. I have loops running that prompt Claude and decide what to do. My job is to write loops."

Now you build a small system that finds the work, distributes it, verifies it, documents what's done and then decides the next step. You let that system hit the agents instead of doing it yourself.

I've written before about the cousin of this: agent harness engineering, which is building the environment a single agent runs in, and the factory model, the system that builds the software. Loop Engineering sits one floor above the harness. The harness, but running on a timer, spinning up little helpers, and feeding itself.

What surprised me is that this is no longer a question of tooling. A year ago, if you wanted a loop you wrote a pile of bash and maintained that pile forever, and it was yours and yours alone. Now the pieces ship inside the products. Steinberger's list maps almost exactly onto the Codex app, and nearly the same onto Claude Code. And once you notice the shape is the same, you stop arguing about which tool and just design a loop that works no matter which one you're sitting in.

A loop needs five things and one place to remember:

1. Automations — they fire on a schedule and do discovery and triage on their own.
2. Worktrees — so two agents working in parallel don't step on each other.
3. Skills — to write down the project knowledge the agent would otherwise guess at.
4. Plugins and connectors — to plug the agent into the tools you already use.
5. Sub-agents — so one has the idea and a different one verifies it.

And then the sixth thing: memory. A markdown file, a Linear board, anything that lives outside the individual conversation and records what's done and what's next. It sounds too dumb to matter. But it's the same trick every long-running agent depends on: the model forgets everything between runs, so memory has to live on disk, not in context. The agent forgets, the repo doesn't.

Both products already have all five.

Automations are what make a loop an actual loop instead of a run you did once.

In the Codex app you create one in the Automations tab: you pick the project, the prompt that will run, how often, and whether it runs in your local checkout or in a background worktree. Runs that find something go to a Triage inbox, and the ones that find nothing just archive themselves — which is a nice touch. OpenAI uses them internally for boring stuff like daily issue triage, summarizing CI failures, writing commit briefings, hunting for bugs someone added last week. And an automation can call a skill, so you keep the recurring task maintainable: you fire $skill-name instead of pasting a wall of instructions into a schedule nobody will ever update.

Claude Code gets to the same place but through scheduling and hooks. You can run a prompt or a command on an interval with /loop, you can schedule a cron task, you can fire shell commands at certain points in the agent's lifecycle with hooks, or you can push the whole thing to GitHub Actions if you want it to keep running after you close the laptop. Exactly the same idea: you define an autonomous task, give it a cadence, and the findings come to you instead of you being the one going to check.

There's a second in-session primitive worth knowing, and it's the one closest to what this article is about. /loop re-runs on a cadence. /goal keeps going until a condition you wrote is actually true, and after every turn a separate small model checks whether you're done — so the agent that wrote the code isn't the one evaluating it. You give it something like "all tests in test/auth pass and lint is clean" and walk away. Codex has the same thing, also called /goal; it keeps working between turns until a verifiable stop condition is met, with pause, resume and clear.

This is the part that surfaces the work. The rest of the loop is what acts on it.

The second you run more than one agent, files start colliding. That's the failure mode. Two agents writing the same file is exactly the same headache as two engineers committing to the same lines without talking first. A git worktree solves it: it's a separate working directory on its own branch, sharing the repo's history, so one agent's edits literally cannot touch the other's checkout.

Codex builds worktree support right in so several threads can hit the same repo at the same time without colliding. Claude Code gives you the same isolation with git worktree: a --worktree flag to open a session in its own checkout, and an isolation: worktree setting you put on a sub-agent so each helper gets a fresh checkout that cleans itself up afterward. I've written about the human side of this in the orchestration tax: worktrees remove the mechanical collision but YOU are still the ceiling — your review bandwidth decides how many you can actually run, not the tool.

A skill is how you stop re-explaining the same project context every session like a goldfish. Both tools use the same format: a folder with a SKILL.md inside that holds instructions and metadata, plus optional scripts, references, assets.

Codex runs a skill when you call it with $ or /skills, or just when your task matches the skill's description — which is why a tight, boring description beats a clever one. Claude Code does the same.

Skills are also where intent stops costing you over and over. I argued in the concept of intent debt that an agent starts every session cold and will fill any hole in your intent with a confident guess. A skill is that intent written down on the outside: the conventions, the build steps, the "we don't do it this way because of that incident," written once where the agent reads it on every run. Without skills, the loop re-derives your whole project from scratch every cycle. With skills, it actually compounds.

One thing to be clear about: the skill is the authoring format, and a plugin is how you distribute it. When you want to share a skill across repos or bundle several together, you package them as a plugin. It works in Codex, it works in Claude Code.

A loop that can only see the filesystem is a small loop. Connectors, which are built on MCP, let the agent read your issue tracker, query a database, hit a staging API, drop a message in Slack. Codex and Claude Code both speak MCP, so the connector you wrote for one generally works in the other. And plugins bundle connectors and skills together so your teammate can install your setup in one shot instead of rebuilding it all from memory.

This is the difference between an agent that says "here's the fix" and a loop that opens the PR, links the Linear ticket and pings the channel when CI is green, on its own. Connectors are why the loop can act inside your real environment instead of just telling you what it would do if it could.

The most structurally useful thing in a loop, by far, is separating the writer from the reviewer. The model that wrote the code is too good at grading its own homework. A second agent with different instructions — and sometimes a different model — catches the things the first one convinced itself of.

Codex only spawns sub-agents when you ask it to, runs them at the same time and then folds the results into a single response. You define your own agents as TOML files in .codex/agents/, each with a name, description, instructions and optional reasoning model and effort — so your security reviewer can be a strong model at high effort while your explorer is something fast and read-only. Claude Code does the same with sub-agents in .claude/agents/ and agent teams that hand work to each other.

The usual split in both is: one agent explores, one implements, one verifies against the spec. I've made this case twice, once as the code-agent orchestra and once as adversarial code review. The reason it matters specifically inside a loop is that the loop runs while you're not watching — so a verifier you actually trust is the only reason you can leave. Sub-agents do burn more tokens since each one does its own model and tool work, so spend them where a second opinion is worth paying for.

This is basically what Claude Code's /goal does under the hood: a fresh model decides whether the loop is done instead of the one that did the work — the maker-checker split applied to the stop condition itself.

Put it all together and a single thread turns into a small control panel. This is one shape I've been using.

An automation runs every morning over the repo. Its prompt calls a triage skill that reads yesterday's CI failures, open issues and recent commits, and writes the findings to a markdown file or a Linear board. For each finding worth acting on, the thread opens an isolated worktree and sends a sub-agent to draft the fix, and a second sub-agent reviews that draft against the project skills and the existing tests.

Connectors let the loop open the PR and update the ticket. What the loop can't handle lands in the triage inbox for me. The state file is the backbone of the whole thing: it remembers what was tried, what happened, what's still open — so tomorrow morning's run picks up where today's stopped.

And look at what you actually did there. You designed it once. You didn't prompt any of those steps. That's Steinberger's whole point made real. And it's the same loop in Codex or Claude Code because the pieces are the same.

The loop changes the work. It doesn't remove you from the work. And three problems get sharper as the loop gets better, not easier.

Verification is still yours. A loop running unsupervised is also a loop making mistakes unsupervised. The whole reason to separate the verifying sub-agent from the one doing the work is so the loop's "it's done" means something — and even then "done" is a claim, not proof. I keep saying the same line about code review in the AI era: your job is to ship code you confirmed works.

Your understanding rots if you let it. The faster the loop ships code you didn't write, the wider the gap between what exists and what you actually understand. That's comprehension debt, and a smooth loop only makes it grow faster — unless you read what the loop produced.

And yes, the comfortable posture is probably the risky one. When the loop runs on its own, it's very tempting to stop having an opinion and just accept what it returns. I called that cognitive surrender. Designing the loop is the cure when you do it with judgment — and the accelerant when you do it to avoid thinking. Same action, opposite outcome.