ReAct
Think, act, look at what happened, think again — the loop underneath essentially every agent, and it's four lines of pseudocode.
When not to use it
- When the sequence is known. If you know the steps, write them. A loop that rediscovers your workflow each time is slower, costlier, and occasionally wrong.
- For long-horizon tasks. Error compounds multiplicatively. Twenty steps at 95% is 36%.
- When latency matters. Each iteration is at least two round-trips.
- Without an iteration cap. It will not notice it's stuck. That's not pessimism, it's the observed behaviour.
Reach for something else instead
- A fixed pipeline — when the steps are known, which is more often than agent enthusiasm suggests.
- Single tool call — many "agent" tasks are one function call with extra ceremony.
- Plan-and-execute — plan once, then run. Cheaper, and worse at recovering from surprises.
- Human-in-the-loop — put a person at the step that actually needs judgement.
95% per step over five steps is 77%.
Reliabilities multiply, so the chance a whole trajectory survives is pN — the same arithmetic as the vanishing gradient, applied to your agent. The curve is exact, not simulated. What makes it bite is how good the per-step number sounds before you raise it to a power: 95% feels shippable, and ten steps of it fails four times in ten. This is why adding steps to improve an agent so often makes it worse, and why the highest-leverage change is almost always making one step more reliable rather than adding another.
The full account
The loop, and why it caught on
Yao and colleagues proposed ReAct in 2022, and the idea is one line: interleave reasoning and acting. Instead of a model that thinks and then answers, or a model that calls tools blindly, you get a loop — Thought, Action, Observation, repeat. The model writes what it is trying to do, takes one step, sees what came back, and reconsiders.
It caught on for two honest reasons. It works better than either half alone on tasks needing external information, because the observation grounds the next thought in something real rather than in the model's recollection. And it is legible: you can read the trace, which made it the default agent pattern almost immediately and put a Thought field into every framework built since.
The arithmetic nobody runs
The figure above computes the thing that determines whether your agent ships, and it is not sophisticated. p^N.
An agent that is 95% reliable per step, over 5 steps, succeeds 77.4% of the time. At 90% over 10 steps, it succeeds 34.9% of the time. Those are not pessimistic numbers — 95% per step is good, better than most tool-calling loops manage in production, and the demo you saw was three steps long.
Every agent failure story is this equation. Nobody's agent is bad; everyone's agent is 90% good, ten times in a row. The compounding is the whole phenomenon, and it is invisible in a demo because demos are short and curated by definition.
This is why the governance question and the engineering question are the same question. You cannot fix p^N by improving p a little — going from 90% to 95% at ten steps takes you from 35% to 60%, which is better and still not a product. You fix it by reducing N, which means: do the deterministic parts deterministically, and reserve the loop for the parts that genuinely need judgement. Most agent architectures do the opposite.
| Per-step reliability | 5 steps | 10 steps | 20 steps |
|---|---|---|---|
| 99% | 95.1% | 90.4% | 81.8% |
| 95% | 77.4% | 59.9% | 35.8% |
| 90% | 59.0% | 34.9% | 12.2% |
The Thought field is not a reason
The most consequential mistake with ReAct is treating the Thought as an explanation of the Action. It is not, and this is not a philosophical quibble — it is a published empirical result.
Turpin and colleagues showed in 2023 that chain-of-thought reasoning can be systematically unfaithful: models produce plausible reasoning that does not describe the process which actually determined the output, and they do it consistently rather than randomly. In their experiments, biasing features that demonstrably changed the answer went entirely unmentioned in the reasoning, which instead constructed a respectable-looking justification for the biased conclusion.
So the trace is text generated alongside the action, not a log of the computation that produced it. That distinction matters most exactly where people rely on it most: when the trace is used as an audit artefact, a safety argument, or a debugging tool. A ReAct log can be fluent, coherent, and a poor description of why the agent did what it did — and it will look like a good one, because it was optimised to.
This is the same error the field made with attention maps, which were printed as explanations for years until Attention is not Explanation forced the question. The literature establishing that a legible intermediate artefact is not a causal account already exists. It has not been applied to the next legible intermediate artefact.
And it cannot plan
There is a second load-bearing assumption in the ReAct loop: that the model can figure out what to do next. Valmeekam and colleagues tested this directly on classical planning problems — the kind where a correct sequence of actions exists and can be verified — and found LLM performance poor, far below what the fluency of the plans suggests. Models produce plans that read well and don't work.
Combine the two results and the picture is unflattering: the loop depends on the model planning the next step, which it does badly, and reports its reasoning in a field that doesn't reliably describe its reasoning. What ReAct genuinely contributes is the grounding — the Observation, which is real information from the world, injected between steps. The Thought is the part everyone looks at and the Observation is the part doing the work.
What to actually build
Reduce N before you improve p. Every step you can move out of the loop and into a deterministic call is a factor you remove from the product. The best agent architectures are mostly not agents.
Put a verifier after each action where one exists. p^N assumes independent failures; a check that catches errors early breaks the chain rather than propagating it, and this is worth more than a better model.
Gate anything irreversible on a human. At 90% per step, an agent that can send money or delete records will eventually do so incorrectly, and the arithmetic says roughly when.
And don't read the Thought as a reason. Read it as a hint about what the model was attending to, treat it with the scepticism you'd apply to an attention map, and get your evidence from the Observations — those, at least, came from outside the model.
Further reading
- Yao et al. (2022), ReAct: Synergizing Reasoning and Acting in Language Models — the paper; interleaving beats either half alone.
- Valmeekam et al. (2023), On the Planning Abilities of Large Language Models: A Critical Investigation — why the loop's short horizon is doing more work than the model's planning.
- Liu et al. (2023), Lost in the Middle: How Language Models Use Long Contexts — why long traces degrade even though nothing is deleted.
- Turpin et al. (2023), Language Models Don't Always Say What They Think — chain-of-thought explanations can be systematically unfaithful to the process that produced the answer.
Primary sources, listed so you can check the claims on this page rather than take them on trust.
Where people go wrong
- Treating the Thought trace as an explanation. It's generated text alongside the action, not a record of the computation.
- Dumping raw tool output into the observation. It poisons every subsequent step.
- Expecting per-step accuracy to be end-to-end accuracy. 95% over five steps is 77%.
- Using an agent where a script would do. Most of them would.
At a glance
Often compared with
Where this sits
A destination. 28 concepts lead here, and nothing in the corpus depends on it.
Computed from the prerequisite graph, not assigned. How this works