What is an agentic loop?

An agentic loop is what makes a model an agent. It picks an action, the action runs, and what comes back is the state it thinks from next time. Without tools there’s nothing to loop over, just an agent thinking.

The wrapper holding those tools is the harness, and it isn’t the loop. The harness is a thing: the tools, the permissions, the environment the calls land in. The loop is the cycle that runs inside it.

A turn is one trip around that cycle. A pass is one whole agent session, from start to exit, and one pass is many turns. Repeating whole passes at the same goal, each starting from a fresh context, is a different job with different failures, and loop engineering is where it lives.

What changes between one loop and the next

The cycle is always the same shape. What differs is what each turn has to work with:

• Which tools exist. The loop can only reach what it was given.
• What context each turn starts from. The whole conversation, a summary, or a fresh read of the files.
• What runs between turns. A linter, a test suite, a check on what the last action changed.
• What the model may touch. Which files, which systems, which credentials.

All four are settled in the harness before the loop starts running, which is the practical reason to keep the two apart. A check written into the harness runs. A check written into the prompt is one more thing the model is weighing.

What actually ends the loop

The loop keeps going for as long as the model asks for another tool call. So the ordinary ending is the model answering instead of calling: it decided there was nothing left to do, and nothing checked that decision.

Everything else is something cutting in from outside, and those stop a pass without finishing it:

This is where “tests pass” gets misfiled as a property of the loop. An agent that runs the suite, sees green and stops didn’t stop because the tests passed. It stopped because it read the result, decided that was enough, and asked for nothing more. On another turn it could weigh the same result differently.

The harness can also be wired so a failing suite sends the work back and only a green one releases it. Then the tests are the stopping condition, because something outside the model is reading them. Same green suite, two different arrangements: in one it’s evidence the model weighed, in the other it’s a gate the model can’t talk past.

What a few turns look like

Say the job is “the checkout tests are failing, fix them”. Nothing in that sentence tells the model what’s wrong. The cycle is how it finds out.

The first run of the suite turns up a helper the instruction never mentioned. That’s what the cycle buys: each action gets chosen after the last result is known, rather than before.

Which calls are safe to make twice

A pass will repeat a call after a timeout, or after a result that looked wrong. Reading a file or fetching a page costs time and nothing else. Sending the customer an email, charging a card, filing a ticket: the second one lands in the world next to the first, and no later turn takes it back.

The model can normally tell those apart, because the tool it is calling says which kind it is. What it can’t read is the ambiguous case. The call timed out, and whether the charge landed before the connection dropped isn’t in anything the model can see, so a sensible-looking retry is how the customer gets billed twice.

That’s why the protection sits outside the model. The tool checks what already landed before it fires again, or carries a key that makes the second call do nothing, or the harness doesn’t offer it inside the loop at all.

The context grows every turn

Every result that comes back joins the prompt for the next turn: test output, file contents, a fetched page. The conversation gets longer, and the instruction that mattered ends up further from the end of it.

The answer inside a pass is compaction. Before the context window fills, the model writes down what it learned and what’s still open, and the pass carries on from those notes. What survives is a summary the model wrote about itself, after the evidence behind it has gone.

The other answer is to stop carrying history at all: end the pass and start a clean one. What the next pass has to be handed, and who writes it down, is loop engineering.

What goes wrong

Three failure modes follow from that:

• Nothing but the model decides it’s over. The job sounded bounded when you wrote it down and isn’t, and without a ceiling the pass carries on for as long as the model keeps finding something to try.
• The loop’s shape enforces nothing by itself. If a check has to run before an irreversible action, the harness has to call it and block when it fails. A prompt that asks the model to check its own work leaves that decision inside the model, and where those boundaries belong is the next thing to work out.
• Every turn costs something, including the ones that go nowhere. A stalled loop bills for going in circles. A spend cap that halts the run is what stops that.

The cycle leaves all three open. Closing them is work for the harness, the tool, or the system the tool calls.