Why now

“Agent loop” gets used for almost anything that calls a model more than once, and most of the time nobody defines it. There’s now a fairly precise, shared definition circulating across docs, newsletters, and even an economics paper, and it’s worth pinning down before the term gets diluted further.

What happened

The core pattern is the same everywhere: the agent reasons about the next step, takes one action such as calling a tool or running code, observes what came back, checks it against the goal, and repeats until a stopping condition fires. The test for whether something is a real agent loop comes down to three questions: is there genuine reasoning about the next step, does the system act on feedback from its own actions rather than just streaming output, and can it self-correct without a human prompting each fix. If any of those is missing, it’s a workflow wearing a loop’s name. The formal version of this pattern is usually written as Reason, Act, Observe, Repeat, based on the ReAct method of alternating thought, action, and observation.

The distinction that matters most is statefulness. A single model call is stateless — you send a prompt and get a reply — while a loop is iterative and keeps accumulating context from each action it takes. The mechanics are plain: the model receives the prompt along with the system prompt, tool definitions, and history, evaluates the state, calls a tool, gets the result back, and keeps going until the task is done. Hooks can sit inside that cycle and stop a tool call before it ever executes.

Zoom out and the loop isn’t new at all. Loops have always existed in code; what’s new is running an agent inside one — reading project state on a schedule or trigger, doing work, updating the state, then going back to sleep. Some builders track that state externally, in an issue tracker, calling it a control plane, because unattended agents need somewhere visible to leave a trail.

Why it matters

What almost nobody is saying out loud: the loop never actually knows it succeeded. An agent reporting “task complete” just means it believes the stopping condition was met, not that the output is correct, so the result still needs an independent look. Even rigorous experiments running agents on forecasting tasks don’t trust the model to police its own budget — an outer process restarts sessions, reads results and history to recover state, and refuses to launch another run once a limit is hit. The verification always lives one layer outside the model: in a script, a hook, a human, or a file the agent doesn’t get to edit. That’s the actual boundary between a loop you can trust unattended and one you’re just hoping behaves.