ReAct Agents Explained: The Reasoning + Acting Loop | Rerun
ReAct Agents: How the Reasoning-and-Acting Loop Actually Works
In the paper that named the pattern, a ReAct agent beat imitation and reinforcement learning baselines by an absolute success rate of 34% on ALFWorld and 10% on WebShop, just by letting the model think and act in the same loop (Yao et al., 2022). That loop is now the engine inside almost every modern AI agent.
This guide explains the ReAct loop the way an engineer actually needs it: what each step does, a real worked example you can follow cycle by cycle, how it compares to the alternatives, and the part nobody on page one says out loud, which is why the raw loop breaks the moment you put it in production.
Quick note before we start: this is about ReAct (Reasoning + Acting), an AI pattern introduced by Yao et al. in 2022. It has nothing to do with React, the JavaScript UI library. Same spelling, completely different world.
What is a ReAct agent?
A ReAct agent is an AI agent that solves tasks by looping through three steps, Thought (reasoning about what to do next), Action (calling a tool), and Observation (reading the result), repeating until it reaches an answer. ReAct stands for Reasoning + Acting, a pattern introduced by Yao et al. in 2022.
The insight is small and powerful. A plain language model can reason out loud, but it cannot check anything or touch the outside world. A tool-calling script can act, but it cannot decide what to do when the situation changes. ReAct interleaves the two. The model reasons to decide an action, takes the action, reads what came back, and reasons again with that new fact in hand. Reasoning steers the actions, and the actions keep the reasoning honest.
That is the whole idea. Everything else is detail.
The ReAct loop, step by step
Every ReAct cycle has the same three beats. The loop runs them over and over until the model decides it has a final answer.
Thought
The model reasons in plain language about the current state and what to do next. This is the chain-of-thought trace, made visible. A Thought might be "I need the host country of the 2022 World Cup before I can look up its population." The reasoning is not decoration. It is how the agent plans its next move.
Action
The model emits a structured action, almost always a tool call: a web search, a database query, a calculator, an API request, or code execution. The action is chosen by the Thought that came just before it. This is where the agent stops talking and does something.
Observation
The system runs the tool and feeds the result back into the model's context. A search returns a snippet, an API returns JSON, a calculator returns a number. The Observation grounds the next Thought in a real fact instead of a guess, which is exactly what cuts hallucination. Then the loop repeats.
The loop keeps going, Thought, Action, Observation, Thought, Action, Observation, until the model reasons that it has enough to answer. Then it emits a Final Answer and stops.
A real worked example
Say the task is: "What is the population of the country that hosted the 2022 FIFA World Cup?" A single reasoning step cannot answer it reliably, but a ReAct loop nails it in a few cycles.
Question: What is the population of the country that hosted the 2022 FIFA World Cup?
Thought 1: I need to find which country hosted the 2022 World Cup.
Action 1: search("2022 FIFA World Cup host country")
Observation 1: The 2022 FIFA World Cup was held in Qatar.
Thought 2: Now I need the current population of Qatar.
Action 2: search("current population of Qatar")
Observation 2: Qatar's population is approximately 2.9 million.
Thought 3: I have the host country and its population. I can answer.
Final Answer: Qatar hosted the 2022 FIFA World Cup, and its population is about 2.9 million.
Notice what happened. The model never tried to answer from memory in one shot, where it could easily have confused a host country or an outdated figure. It broke the task into steps, verified each fact with a tool, and reasoned over real observations. That is the ReAct loop earning its keep.
Where ReAct came from
ReAct was introduced in the 2022 paper "ReAct: Synergizing Reasoning and Acting in Language Models" by Yao et al., from Princeton and Google Research, later presented at ICLR 2023. It is the canonical reference, and it is worth reading if you build agents.
The core finding was that interleaving reasoning and acting beats doing either one alone. On knowledge tasks like HotpotQA and Fever, letting the model pull facts from a Wikipedia API mid-reasoning reduced the hallucination and error-propagation that pure chain-of-thought suffers from. On interactive decision-making benchmarks, ALFWorld and WebShop, the gains were large: an absolute improvement of 34% over baselines on ALFWorld and 10% on WebShop.
ReAct vs the alternatives
ReAct is not the only pattern for getting a model to reason and act. Here is how it stacks up against the three you will hear about most.
ReAct vs Chain-of-Thought
Chain-of-Thought (CoT) prompts the model to reason step by step, but it never leaves its own head. It cannot call a tool, check a fact, or touch a database. ReAct keeps the step-by-step reasoning and adds actions, so every reasoning step can be grounded in a real observation. CoT is great for closed problems like math word problems. ReAct is what you need when the answer lives outside the model.
ReAct vs function-calling agents
This one confuses people, so let us be blunt. Native function calling and tool-calling APIs are not a competitor to ReAct. They are one modern way to implement it. When a model decides which function to call, calls it, reads the result, and decides again, that is the ReAct loop, just encoded through a structured API instead of parsed out of free text. ReAct is the pattern. Function calling is the plumbing.
ReAct vs Plan-and-Execute
Plan-and-Execute writes the full plan upfront, then runs the steps. ReAct decides one step at a time, reacting to each observation. Planning ahead saves model calls and stays on track for predictable tasks. Reacting step by step handles surprises and changing state, at the cost of more calls and some risk of drift. Many production agents blend the two.
| Pattern | Reasons? | Acts on tools? | Plans ahead? | Best for |
|---|---|---|---|---|
| Chain-of-Thought | Yes | No | Partial | Closed reasoning, math, logic |
| Function calling | Partial | Yes | No | The encoding of a ReAct loop |
| Plan-and-Execute | Yes | Yes | Yes | Predictable multi-step tasks |
| ReAct | Yes | Yes | Partial | Open-ended tasks with live tools |
How to build a ReAct agent
Stripped to its core, a ReAct agent is an LLM in a while-loop with three things around it: a tool registry, a prompt that teaches the Thought-Action-Observation format, and a stop condition. That prompt, the one that teaches the model to emit reasoning and actions in the ReAct format, is what people mean by ReAct prompting.
- A model that can reason and emit structured actions
- A registry of tools it is allowed to call, each with a clear description
- A loop that runs an action, appends the observation, and calls the model again
- A stop condition (a "Final Answer" signal, a step limit, or a budget)
Most teams do not hand-roll this. Frameworks like LangGraph and LangChain ship a create_react_agent helper that wires the loop, the tool calls, and the message history for you. The framework saves you the boilerplate, but it does not answer the question that actually decides whether your agent survives production: what happens when the loop misbehaves.
Here is the same idea as a brief you could hand to an agent:
Minimal ReAct agent brief
{ "goal": "Answer the user question using tools", "loop": ["Thought: reason about the next step", "Action: call one tool from the registry", "Observation: read the tool result", "repeat until confident"], "tools": ["search", "calculator", "database.query"], "stop_when": "you can give a Final Answer, or step_limit reached", "guardrails": ["no destructive action without approval", "max 12 steps", "log every step"] }
Look at that guardrails line. The raw ReAct loop does not have one. That gap is the whole story of the next section.
Why the raw ReAct loop breaks in production
The ReAct loop is a beautiful research pattern. It is also deliberately naive. It knows how to think and act, and nothing else. Ship it as-is and you meet the same five walls that raw ReAct agents hit every time.
It has no memory of its own limits. The loop will call any tool in its registry, including the one that deletes rows or sends the email. There is no notion of "ask first" and no scope on what it is allowed to touch. The reasoning decides, and the action fires.
It has no observability. When a twelve-step loop fails at step nine, you cannot see the Thought, Action, and Observation trail unless you built the tracing yourself. A bare loop gives you a final answer or an error, not the reasoning that led there. Debugging blind is not debugging.
It is fragile to bad observations. One malformed tool result can send the reasoning into a spiral. Agents get stuck repeating the same failing action, or confidently reason over a garbage observation. Practitioners have found agents self-correct far better when a tool error returns the current state and the valid next actions, but the raw loop does none of that for you.
It has no cost ceiling. Every iteration is a full model call. An unbounded loop is unbounded spend, and a stuck agent can burn a real budget before anyone notices.
It is a security surface. Prompt injection can hijack the Thought or Action step, turning your helpful agent into a confused deputy that runs the attacker's tool calls. The loop has no instinct for "this observation is trying to manipulate me."
None of these are fixed by a better prompt. They are fixed by the layer you build around the loop. The ReAct loop is the engine. Production needs the rest of the car.
What production ReAct actually needs: the control plane
Take those five failure modes and flip each into a requirement. What you get is a checklist every serious team ends up building around a ReAct loop.
- Governance: scoped tool access, allow and deny lists, least privilege per agent
- Human-in-the-loop: approval gates on risky actions, so the loop pauses for a human on the calls that matter
- Observability: the full Thought-Action-Observation trace, live, not reconstructed after the fact
- Guardrails and budgets: step limits, spend caps, and recovery when a tool call goes wrong
- Coordination: a way to run and supervise more than one agent without them stepping on each other
This is exactly the layer Rerun provides. You build the agent, connect its tools, and then watch the reason-act loop run live on a dashboard anyone can read. Every Thought, every Action, every Observation is visible as it happens, not buried in a log file. When the loop reaches for something risky, it pauses and asks for approval, and you can approve from the app or from Slack and it resumes exactly where it left off. The loop is the engine. Rerun is the cockpit.
The bottom line
ReAct is the loop that made modern agents work: think, act, observe, repeat. It is elegant, well-proven, and the right mental model for how an agent actually operates. But the loop by itself is a demo. What turns it into something you can trust with real tools and real data is the control plane around it: governance, approvals, observability, and budgets.
You can build all of that yourself, or you can start with a platform where it is already there and you simply watch the work get done.