An agent that’s genuinely useful for an hour can be useless across a week. The job doesn’t fit in one agent session, so it gets split across many. Each session is one pass: it reads the state left outside the conversation, takes a bounded item, proves the result, and hands over. The failure shows up at that handover, when pass four leaves behind a claim and pass five has no way to check it.
The vocabulary trips people up, because three words name three different sizes of thing:
- A turn is one step inside a session: the model chooses an action, it runs, and the result comes back.
- A pass is one whole agent session, from start to exit, and that’s the unit loop engineering works in.
- A run is the larger written-down process, which can hold repeated passes or named stages.
Turns sit inside a pass, and passes sit inside a run. What happens inside a pass is the agentic loop. What happens between passes is the harder problem.
Is one repeated stage enough?
An engineered loop can be one stage repeated. A single agent takes the defined end state, works on it with a fresh context each pass, and stops when the state is reached. It can fan work out to subagents inside a pass, and the loop itself is still one thing repeating rather than a set of named steps.
The dashed edge is the whole difference. In a graph it would carry work back to a stage that got something wrong; here it carries nothing at all. The next pass starts with an empty context and has to rebuild its picture from what the last one left on disk.
Whether that’s enough depends on the work. If every pass has the same access and the work is sequential, named stages add handoffs without adding an independent check. A loop with real checks then gets you what a graph would, without the coordination that comes with splitting things up.
It falls down when one big structured skill carries everything. A skill can hide separate pieces of work inside it, and if those pieces need their own evidence or their own permissions, name them. Nothing can check a piece that was never named.
Splitting into stages doesn’t fix that by itself either. You can loop a graph too. The difference that matters is whether the conditions between pieces are enforced or merely requested: a hard gate the pass cannot skip, or a model deciding for itself that the check passed. Which decisions belong to you is that question on its own.
What a fresh pass knows
Pass five is no less capable than pass four. It just knows less. A fresh session carries no memory of the last one unless something outside the conversation puts it back, so what pass four tried and rejected is gone unless it was written somewhere the next pass reads.
The obvious patch is to carry a summary forward, and it helps less than you’d hope. Anthropic, running an agent across many context windows, found compaction alone wasn’t enough. A summary can carry a conclusion forward without the evidence that produced it. If pass four decided the login flow was finished, pass five inherits that as settled and has nothing to check it against. The repository holds evidence the next pass can reconstruct, but only if the harness makes it reread the code and rerun fixed checks. Require both, and a wrong summary has something concrete to disagree with.
So before you start a long job, work out which parts of the situation a fresh agent could reconstruct by reading. Whatever it can’t reconstruct is what you have to write down.
Where the state lives between passes
Four places do the remembering, and they’re good at different things.
| Where | What it holds | Where it lets you down |
|---|---|---|
| The working tree | The only honest account of what the project currently is. It can’t misremember itself. | It says nothing about intent: what was tried, what got rejected, why the odd part is odd. |
| A progress file | The last pass’s account of what it did and what it ran into. Cheap to write, fast to read. | A model wrote it, so it’s a claim. It drifts from the tree unless every pass updates it. |
| Git history | Ordered, timestamped, and every entry points at a diff you can open. | It only records what got committed, so a pass that dies mid-work leaves nothing. |
| The list of what’s still failing | The definition of done, item by item, written before any of the work started. | It’s only as trustworthy as whatever gets to flip an item to done. |
The list answers what the tree and the history can’t: what is still open, and who is allowed to mark it done. The cleanest way to get one is a setup pass that runs before any working pass and writes the scaffolding: the setup script, the progress file, the first commit, and the item list itself. Each item is a plain sentence about behaviour, and every one starts marked failing. The passes that do the work then never have to guess what finished looks like, and they aren’t the ones who decided what counts.
So write the list before the working passes start, and keep the success criteria outside their control. Whoever writes the list shouldn’t be the one measured against it.
That same setup script gives every pass the same opening routine, and the routine surfaces a broken tree before the next pass builds on top of it.
Bound each pass to one item
Give an agent a big goal and a fresh window and it will reach for the whole thing. A pass that goes after five features spends its window half-finishing all five, and the next pass inherits five half-things with no way to tell which parts are real. One item per pass is the boundary that stops it.
The item stays small for a second reason too, and it only bites late in a long job. A pass that arrives to find a lot already built can read that as the work being finished, and stop with real items still open. An explicit list of what’s still failing takes that reading off the table.
Geoffrey Huntley’s Ralph, a bash loop that reruns the same prompt until the work is done, shows the fresh-context half of this. Every loop reloads the plan and the specifications instead of carrying the previous conversation forward, and the plan is what carries the next pass forward. What matters across passes is narrower: the instructions each pass receives don’t change, and the state it works from doesn’t live in them.
So keep the invariant instructions in one file the pass can’t edit: what the job is, what the rules are, how to pick an item. The things that move between passes get read at the start instead, from the tree, the open-item list and the latest check results.
When is a pass done, and when is the loop finished?
A pass is only finished when fixed evidence says its item passed. Left alone it ends earlier, when the model stops asking for tools, so the evidence has to be something the pass couldn’t have authored: a test suite it isn’t allowed to change, or the project actually starting. If the only evidence is a paragraph the agent wrote, you have a claim rather than a finished item. Keeping that evidence out of the model’s reach is its own problem with its own answer. What belongs to the loop is what happens next: the result gets written back before any other pass can claim the item.
The loop is finished when the list is, which is most of the reason to have written one. The harder problem is telling a loop that’s moving slowly from one that’s stuck, because both look like passes going by. Four signals are cheap to watch:
- Passes that end with no diff.
- The same item failing across several passes in a row.
- Items flipping back to failing as fast as they flip forward.
- Cost climbing while the count of open items stays where it was.
Any of those means the loop is spending without moving, and the answer is a person rather than another pass. A spend cap that halts the run is what catches it when nobody’s watching.
What goes wrong between passes
Four failures cost whole nights, and each one is stopped by something structural rather than by a better prompt.
| The failure | What it looks like | What stops it |
|---|---|---|
| Waking up to a broken tree | Pass eleven builds a feature on top of pass ten’s half-finished refactor, and now neither works. | Every pass starts by running the project and fixing what’s broken before it takes an item. |
| Specs that contradict each other | Passes keep rediscovering the same conflict and resolving it differently, so the work oscillates instead of advancing. | One source for the plan, edited by a person. A pass that finds a conflict stops and asks rather than picking a side. |
| Two passes doing the same work | Two passes take the same item, or a pass redoes something already finished because the list never said so. | An item gets claimed atomically before the work starts, with an owner and an expiry recorded, so a second pass takes a different one and a dead pass’s item comes back. |
| A pass reporting success it didn’t get | The item flips to done and the progress file says shipped, while the feature doesn’t run. | Whatever flips the item is something the pass can’t author or edit. |
Two of those decisions can’t sit inside the pass at all: who gets to claim an item, and what’s allowed to close it. Which decisions belong to you covers where those boundaries belong.
When to move from a loop to a graph
A loop and a graph aren’t a beginner and an advanced version of the same thing, and a loop that’s working keeps working. What changes is that a specific pressure turns up, and one repeated stage has no way to express it.
| What you’re seeing | What one repeated stage can’t express |
|---|---|
| Passes spend most of the window waiting on one slow step while unrelated work sits untouched | Parts that don’t depend on each other running at the same time. One stage repeated does everything in order, whether or not the order matters. |
| Every pass carries the credentials the riskiest step needs | Different access per stage. The step that reads customer records and the step that sends mail outward are equally trusted, because there’s only one kind of pass. |
| A failed check throws away a whole pass when one part of it was wrong | A rejection with somewhere particular to go. In a loop the only way back is another full pass from the top. |
| The check script has grown a pile of conditionals about which item is being worked on | Different evidence per stage. A loop has one definition of a finished item. |
The pressure is what earns the stages, not the drawing. A named boundary is somewhere a condition can be enforced, and an unnamed one isn’t. If none of the four is biting, splitting costs you the handoffs and buys nothing back.
Those are the same boundary questions graph engineering works through, asked from the other end. Here you’re reading them off a loop that’s already running. There you’re looking at a job and deciding what shape it wants.
It runs both ways, too. A graph whose stages all share the same access and never run in parallel is a loop that someone drew out.
When to reach for a playbook
A playbook is a graph of stages, so the shape question is the one the four pressures above already answer. What a playbook adds is who checks the conditions between those stages.
That only starts costing you when you stop watching. A graph where each stage decides for itself that it’s ready to hand over is one long chain of model judgement drawn with more boxes, and while you’re reading every handover that’s fine, because you are the enforcement. Once nobody is reading, the gap between the model saying a condition held and the condition holding is the whole thing.
So reach for a playbook when a run has to survive being left alone. The stages are named, the conditions between them are written down, and the runner is what checks them, which leaves judgement where judgement is actually the right tool: inside a stage rather than at its boundary. Working out which parts get which is its own question.
What breaks when you run four loops
One loop running well is a project. Then you have four of them, and what breaks is no longer inside any single loop: it’s which loop can claim which work, and what state all four of them can trust. What changes as you add more of them is its own question, and so is what gets fixed before a run starts.
How is loop engineering different from an agentic loop?
Do I need a progress file if I already have git history?
How big should one pass be?
Does this work on an existing codebase?
Watch a playbook run live
→One run end to end, with the checks and what it cost. No signup.