An agent has been working for six hours. It has read forty files, edited a dozen, run the test suite nine times. Then the machine it runs on reboots. You start it again the next morning and it begins exactly where it began yesterday: opening the first file, with no idea that any of it ever happened. Nothing was wrong with the model. It made reasonable decisions for six hours straight. What failed was everything around it, the part that was supposed to remember those six hours occurred. That part has a name now, and it is where most of the actual engineering has quietly moved.

Every station gets only the tools bolted to its floor

Think about how a car moves down an assembly line. The station that fits the windshield does not have a paint sprayer within reach. Not because the worker there is untrusted, but because reaching for one at that point in the line would be a mistake, and the cheapest way to prevent a mistake is to make it unreachable. The line is a sequence of stations, each with a deliberately narrow set of tools.

An agent loop can be built the same way. Instead of handing the model every tool it might ever need and hoping it picks well, you define phases, planning, implementing, testing, and declare which tools each phase is allowed to touch. In planning it can read but not write. In implementing the editing tools unlock. A call that does not belong to the current phase gets refused, with a note explaining what is available instead. Unlike a fixed pipeline, the phases can loop backward: a failing test sends the agent from testing back into implementing, which is what real work requires.

The effect of this is larger than it sounds. In one published setup, narrowing the visible tools from more than forty down to three during the planning phase took two local models from solving two tasks out of ten to solving ten out of ten. Same models, same hardware, same prompts. The only thing that changed was what they were allowed to reach for.

Anchors, so a fall costs you one pitch

The six-hour run has a second problem, and it is not about tool choice. A climber on a long route places anchors along the way, not because falling is expected but because an unanchored fall costs the entire climb rather than the last few meters. A long agent run needs the same discipline.

In practice this means the harness writes progress to disk as it goes: the step it reached, intermediate outputs, the variables it was holding. Each run gets its own timestamped directory so that runs do not overwrite one another. When something interrupts the work, a crash, a timeout, someone closing a laptop, restarting with a resume flag picks up from the last saved point rather than the beginning. The model does not do any of this. It cannot. It has no disk, no memory between calls, and no way to know that a previous attempt existed.

The thing you are actually building

Once the loop has phases and anchors, a further question appears: who starts it, and how often? That is where this turns into a discipline of its own, one concerned with schedulers, with state that survives between runs, with one agent implementing while a second verifies, and with the gate that decides whether a result ships automatically or waits for a person. Designing that system is a different job from writing a better prompt, and it is increasingly the job.

This is the same boundary that shows up in What an Agent Loop Actually Is, seen from the construction side rather than the definition side. The model supplies judgment, one call at a time, and forgets everything the instant the call ends. Everything that makes that judgment add up to finished work, the phases, the anchors, the schedule, the gate, is ordinary software you write and own. When an agent fails at hour six, it is almost never the model that broke.