Agent loop (ReAct)

What is an agent loop?

An agent loop is the cycle that turns a single model call into an agent. The model reads the goal and the conversation so far, works out what to do next, and asks for a tool. The program around the model runs that tool, puts the result back into the conversation, and calls the model again. That repeats until the model answers without asking for anything, or until a limit stops it.

Anthropic's engineering write-up on building effective agents puts it in one line: agents are typically just LLMs using tools based on environmental feedback in a loop. The prompts, the permissions and the logging all sit around that cycle.

One pass through it is a turn. Anthropic's Agent SDK documentation defines a turn as one round trip: the model produces output containing tool calls, the program executes them, and the results feed back automatically, without control returning to your own code in between. A simple question takes one or two turns. Rebuilding a set of reports can take dozens.

You meet the same cycle under different labels: as a runner you configure in a framework such as LangGraph or the OpenAI Agents SDK, as a coding agent working through your files, or as an ambient agent that fires on a trigger with nobody watching.

One thing about the cost of that cycle is worth knowing up front. The model keeps no state between calls, so every turn resends the whole conversation, and each turn is heavier than the one before. The coding agent entry works that out on a real session. What it means here is that a run gets expensive through its length, not through the difficulty of the job.

Reason and act in the same trace

The pattern has a name and a paper behind it. In October 2022 researchers at Princeton and Google published ReAct, short for reason and act, and presented it at a machine learning conference the spring after. Their move was to interleave two things that had been studied separately: the model writes a short thought, then an action, then reads the observation that comes back, then writes the next thought.

The thought is not decoration. It lets the model notice that a lookup returned the wrong thing and change course, while the observation keeps the reasoning tied to something real instead of to what the model expected to find. Google is blunt about that in its own write-up: a model reasoning alone, as in chain-of-thought prompting, will happily invent a fact. The trace is also readable afterwards, so you can see which step went wrong and fix that step rather than rerun the job.

How the loop stops

Five things end a run, and only the first is the model's own call.

1. The model answers. It produces a turn with no tool call in it. Anthropic's and OpenAI's SDKs define the end of the loop in exactly those terms: text output, no tool calls, done.

2. A turn cap. The Agent SDK's max turns setting counts tool-use round trips and returns a result flagged as having hit the limit instead of a finished answer. The OpenAI Agents SDK raises a max-turns-exceeded error. LangGraph limits how many steps a graph may take in one run, a thousand by default in current versions.

3. A spend cap. The same SDK takes a maximum budget in dollars and stops when the run reaches it, subagent spend included. For anything running unattended this is the more useful cap, because it is stated in the unit you actually watch.

4. A person interrupts. You can stop the run outright, or type a correction while a tool is still running and let the agent read it before it picks its next step. That is the cheapest control there is, and it only exists while somebody is watching.

5. A check passes. Give the agent something it can run itself, a test, a row count, a total that has to reconcile, and the loop gets a finish line that is not the model's opinion. The verification loop entry covers what makes a check worth building.

The first condition is the one you cannot lean on, which is why the other four exist. Anthropic's guidance says as much: it is common to include stopping conditions, such as a maximum number of iterations, to keep control.

A run through one job

A customer mails to ask why invoice 2026-0418 is 640 euro higher than the quote they signed. The agent may read the invoicing system, the CRM and the ERP, and has exactly one write tool: save a draft reply in the shared mailbox.

1. It reads the mail and asks the invoicing system for invoice 2026-0418. Back come eleven lines and a total.

2. The invoice proves nothing on its own, so it asks the CRM for the quote on that customer and project. It gets quote 2026-Q77, nine lines.

3. It lines the two up. Two items are new: a second installation day at 520 euro and 120 euro of transport. Together they are the 640.

4. Transport is covered by the terms printed on the quote. The extra day is not, so it asks the ERP for the work orders on the project and gets a signed one for that day.

5. It writes the reply, naming both lines and the work order number, and calls the draft tool. The mail lands in the mailbox, unsent.

6. It produces a last turn with no tool call: draft ready, both differences documented, and one thing flagged, that the signature on the work order is a scan and it cannot tell whose it is.

Six turns, six model calls, the sixth carrying everything from the first five. The model decided whether the CRM was worth looking at, whether the ERP deserved a fourth call, and when it had enough to write. It did not decide whether the mail went out, because sending was not a tool it had.

One model call versus an agent loop

Both start with a question and end with an answer. The difference that decides which one you want is who gets to say the work is finished.

A single model call. You decide. The model answers once, you read it, and if it is thin you ask again with more context. Your judgement is the stop condition. That is entirely reliable, and it does not scale past what you are willing to sit and read.

An agent loop. The model decides. It keeps calling tools until it judges the goal reached, then stops on its own. That is the point of it and the risk of it at once: the property that lets it work through a job you never broke into steps is the property that lets it work for twenty minutes on the wrong thing.

Which is why the caps are not a safety feature bolted on at the end. A loop with no cap has handed the question of whether the work is finished to the model and kept nothing back.

What to watch out for with an agent loop

It repeats the call that fails. A tool returns an error, the model reads it, tries something barely different, gets the same error, tries again. Anthropic's guidance on writing tools for agents points at the fix: error messages that say in plain words what to do differently, rather than an opaque code or a stack trace. Worse is a tool that swallows the failure and returns an empty result, because the model believes it and builds on nothing.

Tool output fills the window. One verbose command or one large file can take thousands of tokens in a single turn, and it stays there for the rest of the run. A tool that pages or filters by default is worth more than one that returns everything and leaves the model to sort it out.

The goal drifts. By turn thirty the original instruction is a long way back, and compaction may have reduced it to a sentence. Restate the goal where it matters, and keep the standing rules somewhere the harness reloads every request.

Nobody can reconstruct the run. If the tool calls and their results were not logged, a run that went wrong cannot be replayed, and the model chose differently that day is what you are left saying during an audit. Log every step with its input and its output before you let a loop near anything that moves money.