ReAct Agent Loop: How Reason-and-Act Agents Actually Work

A ReAct agent loop is what makes an AI agent go look something up before it answers, instead of guessing from memory. A plain model guesses. A ReAct agent stops, decides it needs to check something, calls a tool, reads what came back, and only then answers.

That stop-check-then-continue rhythm is the whole idea behind a ReAct agent loop. It is one of the most copied patterns in agent design, and once you see its three repeating steps, most other agent behavior gets easier to read.

TL;DR: A ReAct agent loop interleaves reasoning and acting. The model writes a Thought about what to do, takes an Action by calling a tool, reads the Observation it returns, then thinks again. It repeats that cycle until it can give a final answer, checking its work at every step.

What a ReAct agent loop actually is

A ReAct agent loop is an agent loop that interleaves reasoning and acting in one repeating cycle. The model does not reason in one phase and act in another. It alternates: think a little, do a little, look at the result, think again.

ReAct is short for Reasoning and Acting. The name describes the pattern exactly: the model produces a reasoning trace and a task action in the same loop, so each informs the other.

The loop runs on three moves that repeat. A Thought is the model reasoning about what to do next. An Action is a tool call, with its input. An Observation is whatever that tool returns, which the model reads before writing its next thought.

That third move is what sets ReAct apart from a model that just thinks harder. The observation is a real result from outside the model, so the next thought is built on a fact the tool returned, not on an assumption the model made.

It is called a loop because those three moves repeat. One thought, action, and observation is a single turn, and the agent takes as many turns as the task needs before it stops and answers. An easy question might take one turn; a messy one might take six.

Where the ReAct pattern came from

Getting this attribution right matters, because “ReAct” gets used loosely and often misquoted. The pattern was introduced in the 2022 paper “ReAct: Synergizing Reasoning and Acting in Language Models,” by Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. It is arXiv:2210.03629, and it was presented at ICLR 2023.

The paper’s own framing is the clearest one to keep. Before ReAct, reasoning (like chain-of-thought prompting) and acting (like generating an action plan) were mostly studied as separate topics. The paper’s move was to let a model generate reasoning traces and task actions together, in an interleaved way.

The two directions feed each other. Reasoning traces help the model track and update its plan and handle surprises. Actions let it reach outside itself, to a search index or an environment, to pull in facts it did not already have.

The idea caught on fast because it was simple to adopt. You do not need a special model to run ReAct; you prompt an ordinary one to write its reasoning as a thought, name a tool as an action, and wait for the observation before continuing. Several popular agent frameworks ship a ready-made version of this loop.

The paper backed the idea with real numbers, not just a nice framing. It tested ReAct on question answering (HotpotQA) and fact verification (Fever), where reading real observations cut down on made-up answers. On two interactive benchmarks, ALFWorld and WebShop, it reports ReAct beating imitation and reinforcement learning methods by an absolute success rate of 34 and 10 percentage points, using only one or two examples in the prompt.

So when you read that an agent “uses ReAct,” it traces back to this one paper and this one idea: reason and act in the same loop, not in two separate stages. Everything below is a consequence of that choice.

Thought, Action, Observation: the three repeating steps

The three steps are easier to hold onto with a concrete shape. Here is what each one does and what it looks like in a trace.

The cycle repeats. After the observation, the model writes a new thought, takes a new action, reads a new observation, and continues until it has enough to answer.

Here is an illustrative transcript, not a log from any real system, written in the format the paper itself uses, of the shape a ReAct loop produces on a simple lookup task:

Thought: I need the release year of the film, I don't know it.
Action: Search[Blade Runner]
Observation: Blade Runner was released in 1982.
Thought: Now I can answer the question.
Action: Finish[1982]

Read the transcript top to bottom and the loop is obvious. Each thought sets up an action, each action produces an observation, and the model only writes a final answer once an observation has given it what it was missing.

Why interleaving reasoning and acting wins

The natural question is why bother alternating. Why not have the model plan every step first, then run the plan? For many tasks, interleaving is simply more reliable, and the reason is easy to state.

A plan made entirely up front commits to assumptions before checking any of them. If the first assumption is wrong, every step after it inherits the mistake, and nothing in the run catches it until the end.

A ReAct loop checks after every action. If the model guesses wrong on step one, the observation from step one contradicts the guess, and the next thought can correct course. The error gets caught early instead of compounding.

Think of a lookup where the first search returns nothing useful. A plan-first agent keeps executing the rest of its now-broken plan. A ReAct agent sees the empty observation, reasons that the query was bad, and tries a different search on its next action.

That recovery is the practical payoff. Interleaving does not make the model smarter, it makes the loop self-correcting at each step, so a single bad move does not sink the whole run.

Plan-first agents vs ReAct agents

It helps to line the two approaches up directly, since real systems use both and the choice is not always ReAct.

The table is not a verdict that ReAct always wins. A task with a fixed, known sequence of steps often runs fine with a plan made once, and skips the overhead of reasoning before every action.

ReAct earns its keep when the path is not knowable in advance: when the agent has to look something up, react to what it finds, and possibly change direction. That describes a large share of real agent work, which is why the pattern spread so widely.

The overhead is real, though. Reasoning before every action means more model calls and more tokens than a plan made once, so for a short, predictable job the extra thinking is cost you do not need to pay.

Where ReAct agent loops break down

ReAct is not magic, and it fails in specific, recognizable ways. Knowing them is the difference between trusting a loop and debugging one at 2 a.m.

The most common failure is a loop that never stops. If no observation ever satisfies the model, it keeps writing thoughts and calling tools, running up cost and time. Every ReAct loop needs a stop condition, a cap on steps, or both. Diagnosing an agent that gets stuck this way is its own topic.

A second failure is a bad observation the model trusts anyway. If a tool returns a wrong or empty result and the model treats it as fact, the next thought is built on bad ground. The loop is only as reliable as the tools feeding it observations.

A third is a thought that does not match the action taken. The model reasons about doing one thing, then calls a tool that does another. The reasoning trace looks fine on its own, so this one hides until you read the thought and the action side by side.

Each of these is easier to catch when the thoughts, actions, and observations are recorded step by step, rather than collapsed into one final answer you have to reverse-engineer.

How the ReAct loop fits the bigger agent loop

A ReAct loop is one shape an agent loop can take, not a separate machine. The underlying parts, a model, memory, tools, and something to drive the cycle, are the general agent-loop architecture, and that architecture is worth understanding on its own. The named stages that any agent moves through over time are their own separate topic too.

What ReAct pins down is the interleaving: reason, act, observe, repeat. You can drop that pattern into most agent setups without changing the parts around it, and it sits alongside other named agent patterns as one of the most common choices.

The three moves also map cleanly onto how you would watch the loop run. In trace terms, each Thought, Action, and Observation cycle and each tool invocation is a span, and Future AGI’s traceAI captures tool invocations as spans, so a run reads as a sequence of steps instead of one block of text.

That is the same reason the pattern is easy to reason about. Because a ReAct loop leaves a thought before every action, the ReAct pattern makes an agent’s reasoning legible, which is exactly what you need when a run goes wrong and you have to figure out why. ReAct settles the shape of each step. For the wider conversation about designing the loop that shape runs in, loop engineering is the related topic to read next.