What is a loop in agentic coding?
Published 29/10/2026
A loop is the fixed sequence of steps every change goes through on its way from "someone asked for this" to "it is merged". In agentic coding the agent does the typing, so the loop is the part that decides what happens around the typing: where the work happens, who checks it, which tests run, and when it is allowed to land.
Think of a car wash. Every car goes through the same arches in the same order, whatever state it arrived in. Nobody decides afresh, for each car, whether to rinse before or after the wax. That sameness is the point: a car that comes out dirty tells you which arch failed.
Why agents need one#
Without a loop, each session invents its own process. One run edits on the main branch, the next runs the whole test suite three times, the next forgets the tests entirely. The agent is not being careless; nothing told it what the steps are, and the transcript that would have reminded it was compacted away.
A loop moves that knowledge out of the conversation and into the tooling. It holds three things steady:
- The order. Build before review, review before test, test before merge.
- The exits. Every step either advances or stops with a reason. There is no "sort of done".
- The cost. Steps that are scripts stay scripts. A model is only asked to think where a person would have to think.
A loop, step by step#
A minimal loop for one change looks like this:
| Step | What happens | Who does it |
|---|---|---|
| Lane | the change gets its own branch and working copy | a script |
| Build | the smallest change that meets the stated goal | one agent |
| Review | one light round: approve, or a patch | a second agent role |
| Test | the tests that reach the changed files | a script |
| Land | merge, record the outcome, clean up | a script |
Only two of the five steps wake a model. That is where most of the token savings in a loop come from: the steps that are scripts cost nothing to repeat.
Stops: wait, or needs judgement#
A good loop distinguishes two kinds of stop:
- Wait: something outside the loop has to change first, such as uncommitted work on the main branch. Nobody needs to think about it; it needs time or a person's hands.
- Needs judgement: someone has to decide, such as a review patch that does not apply cleanly.
Mixing them up is expensive. A loop that wakes a model for every wait burns tokens asking "is it ready yet?". A loop that treats a judgement call as a wait stalls forever.
A loop inside a loop#
Once one change has a loop, the next question is the board: who picks the next change, and what happens to stopped ones? That outer loop is a conductor. It takes the next open piece of work, runs the inner loop on it, routes any stop by a fixed table (retry once, wait for a condition, wake a model, or park it for a person) and moves on. A person is asked only for the decisions that are genuinely theirs.
/loop and /goal: loops inside one session#
Both engines now have commands that keep a single session working without you prompting each step. They answer a different question from the loop above: not "what steps does a change go through?" but "what starts the next turn?"
| Command | Next turn starts when | Stops when |
|---|---|---|
Claude Code /loop 5m check the deploy | the interval passes | you cancel it, or after seven days |
Claude Code /loop check the deploy | Claude picks a wait, between one minute and an hour | Claude decides the work is done, or you press Esc |
Claude Code /goal all tests in test/auth pass | the previous turn ends | a separate small model reads the conversation and judges the condition met, or impossible |
Codex /goal | the previous turn ends | the goal is met, or you pause or clear it |
A bare /loop in Claude Code runs a built-in upkeep prompt (finish open work, tend the branch's pull request), or your own .claude/loop.md if you write one. Loops live inside the session: close it and they stop.
Write a goal the way you would write a done line: one measurable end state, how to prove it, and what must not change on the way. The judge only sees what the agent printed, so "npm test exits 0" works and "the code is clean" does not. Add a bound, such as "or stop after 20 turns".
The difference from a full loop is what is checked. /goal checks that a condition is met. A loop like the one above also checks how it was met: on its own branch, reviewed, with the tests that reach the change.
Where ADE fits#
Atlas ADE is built around exactly this shape. ade loop runs the five steps for one card, and ade conduct is the outer loop that flies the whole board, with the routing table in a file you can read. How it flies walks through it, and the quickstart lands a first change in a few minutes.