What Is a ReAct Agent?
A ReAct agent alternates a reasoning step with a tool call, feeding each result back in before the next step is produced. The name contracts "reason" and "act", and the pattern is the control loop most tool-using agents are built on.
One iteration of the loop
An iteration has three parts: a thought, an action with its arguments, and the observation the action returned. The observation is appended to the context, and the next thought is produced from a context that now contains it. The loop ends when a step produces a final answer instead of an action, or when a bound is reached.
The bounds are the part that gets omitted and then added after an incident. A maximum iteration count, a wall-clock limit, a token budget and a rule for what happens when an identical action is repeated are all load-bearing, because a loop whose only terminating condition is success does not terminate on failure.
The pattern is older than the tool-calling interfaces most current implementations use, and the two forms fail in different places. In the original text form the thought, the action and the action input are written as free text in an agreed layout and the runtime parses them back out of it; a step that misformats its action, or names an action plausibly but not from the declared set, produces a parsing failure rather than a tool call, which is why implementations of that shape carry repair and retry logic wrapped around the parser and why their transcripts contain steps that did nothing. In the structured form the action comes back as a typed call against a declared schema, so the tool name and the argument shape are checked by the interface and the parser disappears along with that whole class of failure. The loop is identical in both. What differs is whether malformed steps are something the runtime has to handle at all.
| Element | Content |
|---|---|
| Thought | Generated text stating what to do next and why. |
| Action | The tool selected, named from the declared set. |
| Action input | The arguments supplied, which have to satisfy the tool’s schema. |
| Observation | What the tool returned, appended to the context verbatim or summarised first. |
| Stop condition | A final answer, or a bound on iterations, time or tokens. |
The observation row is where context grows fastest. One unbounded tool result placed straight into the loop can consume the remaining budget in a single iteration.
Where the loop goes wrong
Three failures recur. Repetition: the same action is issued with the same arguments and the same observation returns, indefinitely. Drift: successive steps move away from the original request without any single step being unreasonable. Overflow: observations accumulate until the earliest part of the task no longer fits in the context and is silently dropped.
There is a fourth that is not a loop failure but arrives through the loop. Every observation is untrusted input placed directly into the context that decides the next action, so a tool returning content written to be read as instruction has a direct route into the next step. The mechanism is described on this registry's page for prompt injection.
Cost behaves in a way worth stating separately, because it is the constraint that decides how long a loop may run. The accumulated transcript is resubmitted on every iteration — each earlier thought, action and observation, plus whatever the newest observation added — so the tenth step pays for the nine before it as well as for itself, and the total grows faster than the count of steps. Two devices hold that down and both are chosen before the run. Observations are bounded before they enter the context: truncated, or reduced to the fields the next step needs, with the full result kept outside the loop and referred to. And the transcript is compacted rather than carried, earlier iterations replaced by a short record of what was established and what is outstanding. Both discard something on purpose. A loop that discards nothing reaches its limit and then discards the opening of the task, which is the one part it cannot proceed without.
How the Registry classifies a reason-and-act loop task
Answering an operational question by alternating reasoning steps with search tool calls until the answer is confirmed is filed as information retrieval here: what the loop produces is assembled from material it located, and the iteration is machinery.
The Registry's canonical brief for this entry is filed as:
Answer an operational question by alternating reasoning steps with search tool calls until the answer is confirmed.
Submitted for assessment it is
classified as Information retrieval, and its wording is hashed once — to
942cd80f636f4443…, the first sixteen of sixty-four hexadecimal
characters — with the wording itself never stored. The hash is what the derivation
reads.
That class's own page is /tasks/retrieval.
Classification is one of three inputs. The other two are the configuration submitted with the task, and the permanent chart derived from that configuration — fixed by the model name, the training cutoff and the temperature alone, and never reading the task at all. The same ascendant, ruling planet and harmony therefore appear on every assessment a given configuration receives, whatever it was asked to do. The derivation is published in full at /method.
What this page does not claim about react agent
How many iterations a given question takes, and whether the loop converges at all, are properties of a deployment and its tools. The canonical brief above fixes the shape of the task and nothing about its run.
The Registry does not run this task, does not inspect any system's output for it, and validates no assessment it issues against what afterwards happens. What it does is compute — from a published method, for one submitted task and one submitted configuration — a verdict and a recommended execution window. It computes neither on this page.
Questions about react agent
- What is a ReAct agent?
- A ReAct agent alternates reasoning steps with tool calls, appending each observation to the context before the next step is produced. It repeats until a step yields a final answer or a bound on iterations, time or tokens is reached.
- What is the difference between ReAct and chain-of-thought?
- Chain-of-thought produces reasoning steps and then an answer, with no external action between them. ReAct interleaves the steps with tool calls, so each subsequent step is conditioned on something that came from outside the context rather than from within it.
- How is a ReAct loop stopped?
- By a final answer, or by an explicit bound: a maximum iteration count, a wall-clock limit, a token budget, or a rule that fires when an action repeats with identical arguments. Without such a bound the loop has no terminating condition for the cases that fail.
- Is ReAct the same as function calling?
- No. Function calling is the mechanism by which a tool is named and its arguments are supplied in a structured reply. ReAct is a control pattern that uses such a mechanism repeatedly. One is the interface; the other is the loop built on top of it.
- Why does each iteration of the loop cost more than the last?
- Because the accumulated transcript is resubmitted every time. Each iteration is charged for every thought, action and observation that came before it as well as for its own, so a run’s cost grows faster than its number of steps. Bounding what an observation may add, and compacting earlier iterations into a short running record, are the usual responses.
Related entries
Multi-agent system · Function calling · Chain-of-thought prompting
Order an assessment for information retrieval tasks
The Registry issues a permanent, numbered task risk assessment for one submitted task and one submitted configuration. EUR 1.90 Standard, EUR 4.90 Extended, EUR 14.90 Full Chart, which adds the permanent chart. Assessments from EUR 1.90; machine-readable at /pricing.json.