The ReAct pattern is a simple loop: an agent writes out a thought, takes an action based on that thought, observes the result, and thinks again. It's one of the most common building blocks in agentic AI, and it's the reason many agents can explain why they did something, not just what they did.
If you've read an agent's raw output and seen lines like "I should check the calendar before booking" followed by a tool call, you've already seen ReAct in action. It's not a product or a framework — it's a prompting pattern that shapes how the model reasons at each step.
Once you recognize the shape of it, you'll see it inside most agent frameworks, even when they don't use the name.
What ReAct actually stands for
ReAct combines Reasoning and Acting into one repeating cycle. At each step the model:
- 1.Writes a short thought about the current situation.
- 2.Chooses an action — usually a tool call.
- 3.Receives an observation — the tool's result.
- 4.Uses that observation to form the next thought.
This repeats until the agent decides it has enough information to give a final answer. The pattern comes from a 2022 research paper, but the idea has since been absorbed into nearly every agent framework, even ones that never mention it by name.
Why thinking before acting helps
Without an explicit reasoning step, a model tends to jump straight to an action based on pattern-matching the prompt. That works for simple requests but breaks down on anything multi-step.
Forcing the model to write a thought first has a few practical effects:
- It slows the model down enough to consider alternatives before committing to a tool call.
- It creates a visible trail you can read to understand why the agent did what it did.
- It gives the model a chance to notice when a previous observation contradicts its plan.
- It makes debugging much easier, since you can point to the exact thought that led to a bad action.
That last point matters more than it sounds. When an agent misbehaves, the thought log is usually where you find the root cause — a wrong assumption, a misread tool result, a plan that never adjusted.
A simple ReAct trace
Here's a stripped-down example of what a ReAct-style trace looks like for an agent booking a meeting room:
Thought: I need to know which rooms are free at 2pm before booking.
Action: check_room_availability(time="14:00")
Observation: Room A is free, Room B is booked.
Thought: Room A works. I'll book it now.
Action: book_room(room="A", time="14:00")
Observation: Booking confirmed.
Thought: The task is complete.Each thought is short and grounded in the most recent observation. Notice that the second thought didn't repeat the whole plan — it just reacted to what the tool returned.
ReAct vs plain tool calling
Tool calling alone lets a model call functions, but it doesn't require the model to explain its reasoning first. ReAct adds that explanation as a deliberate step in the loop. You can think of ReAct as a discipline layered on top of tool calling: the tools are the same, but the agent is forced to reason before and after each one.
| Plain tool calling | ReAct pattern | |
|---|---|---|
| Reasoning step | Optional, often skipped | Explicit, every step |
| Debuggability | Harder — only actions are visible | Easier — thoughts show intent |
| Cost | Lower (fewer tokens) | Higher (extra reasoning tokens) |
| Best for | Simple, single-step tasks | Multi-step tasks with uncertainty |
Where ReAct shows up in real agents
You don't usually implement ReAct from scratch. It shows up as:
- The default reasoning style in many single-agent setups built on frameworks like LangGraph.
- The inner loop of research and coding agents that alternate between "think" and "search" or "run command."
- A building block inside larger multi-agent systems, where each agent runs its own ReAct loop before handing off.
It also pairs naturally with plan-and-execute agents: a planner can lay out the high-level steps, while each step is carried out by a smaller ReAct loop that reasons and adjusts in the moment.
Limitations worth knowing
ReAct is not free. Every thought costs tokens, and a long ReAct trace can get expensive and slow if the task takes many steps. It also doesn't guarantee good reasoning — a model can write a confident-sounding thought that's still wrong, especially if it misreads an earlier observation.
The value of ReAct isn't that it makes agents smarter. It's that it makes their reasoning visible, so you can catch mistakes before they compound.
For tasks that need a fixed, predictable sequence of steps, a rigid plan can outperform ReAct's step-by-step improvisation. The pattern shines most when the next step genuinely depends on what just happened.
FAQ
Is ReAct a framework or a prompting technique?
It's a prompting technique, not a piece of software. ReAct describes a pattern — alternate reasoning and acting — that you can implement with a simple prompt template or find built into agent frameworks as a default behavior.
Does ReAct make agents more accurate?
It often does, mainly because it slows the model down and gives it a chance to catch inconsistencies before acting. It's not a guarantee of correctness, though — a flawed thought can still lead to a flawed action, so ReAct works best alongside good tool design and error handling.
How is ReAct different from chain-of-thought prompting?
Chain-of-thought is reasoning without action — the model thinks through a problem and gives a final answer in one pass. ReAct interleaves that reasoning with real tool calls and observations, so the model's thinking changes based on what actually happens in the world, not just what it imagines might happen.
Do I need to code ReAct myself?
Rarely. Most agent-building tools already implement some version of the ReAct loop under the hood. Understanding the pattern still matters, because it's what you're reading when you inspect an agent's execution trace to figure out why it made a particular decision.