ReAct Prompting: Combining Reasoning and Action

The Problem ReAct Solves

Chain-of-thought prompting improved reasoning dramatically, but it has a fundamental limitation: the model reasons entirely from its internal knowledge. If the answer requires information the model does not have, if a calculation needs to be verified, or if the task requires interacting with the outside world, pure reasoning fails. The model either halluccinates facts it does not know or produces reasoning that sounds correct but is based on outdated or incorrect premises.

Conversely, models that can call tools (search engines, calculators, databases, APIs) but do so without explicit reasoning often make poor tool choices. They call the wrong function, pass incorrect parameters, or use the results incorrectly because they have no reasoning trace guiding their decisions. Tool use without reasoning is like having hands without a brain.

ReAct combines both. The model reasons about what information it needs, then acts to obtain it, then reasons about what the information means, then acts again. This Thought-Action-Observation loop continues until the model has enough information to produce a final answer. The reasoning ensures good tool choices, and the tool results ensure the reasoning is grounded in real data rather than hallucinated facts.

Yao et al. introduced ReAct in their 2022 paper and showed that it outperformed both pure chain-of-thought (reasoning without tools) and pure action (tools without reasoning) on knowledge-intensive tasks like multi-hop question answering and fact verification. The combination was greater than the sum of its parts because each component compensated for the other's weakness.

The Thought-Action-Observation Loop

A ReAct trace follows a structured pattern. Each iteration has three parts:

Thought: The model reasons about the current state of the problem. What does it know so far? What information is still missing? What should it do next? This step is explicit chain-of-thought reasoning, written out in natural language.

Action: Based on the thought, the model selects and invokes a tool. This could be a web search, a database query, a code execution, a file read, or any other available action. The action includes the tool name and the specific parameters.

Observation: The result of the action is returned to the model. This is the actual data from the tool: search results, query output, calculation result, or error message. The model then uses this observation as input for its next thought.

Here is what a ReAct trace looks like for a factual question:

Notice how each thought builds on previous observations, and each action is directly motivated by the preceding thought. The model does not search randomly. It identifies a specific information gap, formulates a targeted query, uses the result, and decides what to do next. This is the pattern that makes ReAct reliable: reasoning governs action, and action informs reasoning.

Writing ReAct Prompts

A ReAct prompt has three essential components: the instruction that establishes the Thought-Action-Observation format, the list of available tools with their descriptions, and one or two examples showing the expected trace pattern.

The few-shot examples in a ReAct prompt are more important than in standard prompting because they teach the model the specific Thought-Action-Observation rhythm. Without examples, models tend to either skip the Thought step (jumping straight to actions) or produce overly verbose reasoning that does not lead to clear actions. Two well-structured examples are enough to establish the pattern reliably.

The tool descriptions matter enormously. The model decides which tool to use based on your descriptions, so they need to be precise about what each tool does, what input it expects, and what output it returns. "search(query): Search the web" is too vague, the model does not know whether to use it for current events, definitions, or calculations. "search(query): Search the web for current factual information, returns text snippets from top results" is much better.

ReAct vs Modern Tool Use APIs

When ReAct was introduced, models did not have native tool-calling capabilities. The entire Thought-Action-Observation pattern had to be implemented through prompt engineering, with the developer parsing the model's text output to extract tool calls and feeding observations back as text. This was fragile because the model could format tool calls inconsistently, making parsing difficult.

Modern model APIs (Claude's tool use, OpenAI's function calling, Gemini's function calling) have built the action step directly into the API. You define tools as structured schemas, and the model returns tool calls as structured data rather than text. The API handles the formatting, so you never need to parse text to extract tool invocations.

However, the reasoning component of ReAct remains a prompting technique. Even with native tool use, you benefit from instructing the model to reason before acting. Without explicit reasoning instructions, models with tool access sometimes call tools reflexively (searching for information they already know) or inefficiently (calling three tools when one would suffice). Adding "Think about what information you need before calling any tool" or "Explain your reasoning in a thought step before each action" to your system prompt produces more deliberate, efficient tool use.

The modern equivalent of ReAct is a system prompt that instructs the model to reason before tool calls, combined with the API's native tool-calling capability. You get the structured reliability of the API for the action and observation steps, and the accuracy benefit of explicit reasoning for the thought step. This is how most production agent architectures work in 2026.

When ReAct Outperforms Other Approaches

Multi-hop question answering is the benchmark case. Questions like "Who was the president when the company that makes the iPhone was founded?" require looking up multiple facts in sequence, where each lookup depends on the previous answer. Pure chain-of-thought fails because the model may not know the founding date or the president at that time. Pure tool use fails because the model does not know to decompose the question into sequential lookups. ReAct handles it naturally: reason about what to look up first, look it up, reason about what to look up next, look that up, combine the results.

Tasks requiring current information benefit because ReAct allows the model to search for data that postdates its training cutoff. "What is the current stock price of Apple?" cannot be answered by reasoning alone, but ReAct handles it trivially by searching for the current price.

Tasks with verification steps benefit because the model can check its reasoning against external sources. "Calculate the compound interest on $10,000 at 5% for 7 years" can be solved by reasoning, but ReAct lets the model calculate with a tool and verify the result, which catches arithmetic errors that chain-of-thought would miss.

Complex research tasks that require synthesizing information from multiple sources are ReAct's strongest real-world use case. Competitive analysis, literature review, due diligence, and investigative research all involve iterative search-and-reason loops that map directly to the ReAct pattern.

Common ReAct Failure Modes

Reasoning loops occur when the model keeps searching for the same information in slightly different ways, never concluding that it has enough data to answer. This happens when the available tools do not return the specific information the model needs, and the model keeps trying rather than acknowledging the gap. Set a maximum step count (5 to 10 iterations) and instruct the model to give its best answer when the limit is reached, even if it has incomplete information.

Premature conclusion is the opposite problem: the model answers after one search without verifying or finding all necessary information. This typically occurs with simple-seeming questions where the model's first search returns a plausible but incomplete answer. Few-shot examples that demonstrate multi-step verification help train the model to be thorough.

Tool misselection happens when the model chooses the wrong tool for a task, typically because tool descriptions are ambiguous. If the model keeps using search when it should use calculate, or vice versa, the tool descriptions need refinement. Clear, specific descriptions with examples of appropriate use cases prevent most misselection.

Observation misinterpretation occurs when the model misreads or selectively interprets tool results to support a hypothesis formed during the reasoning step. This is a form of confirmation bias. The model forms a belief in Thought 1, then interprets Observation 1 to support that belief even when the data contradicts it. Instructing the model to "evaluate observations objectively and update your reasoning if the data contradicts your hypothesis" reduces this bias.

ReAct in Agent Frameworks

Every major agent framework implements some variant of ReAct. LangChain's agents use an explicit ReAct-style loop with Thought-Action-Observation formatting. CrewAI's agents reason about tasks before delegating to tools. AutoGen's conversable agents interleave reasoning with function calls. The agent loop patterns guide covers how different frameworks structure the reasoning-action cycle.

The key differences between frameworks are in how they manage the loop: how many iterations they allow, how they handle tool errors, how they decide when the agent has finished, and how they manage the context window as the trace grows long. These are engineering decisions around the ReAct pattern, not replacements for it. Understanding ReAct at the prompt level helps you debug agent behavior in any framework, because you can examine the Thought steps to understand why the agent made specific tool choices.

For building agents with memory, ReAct traces interact directly with memory systems. Each Thought-Action-Observation triple represents a unit of agent experience that can be stored, recalled, and used to inform future reasoning. Adaptive Recall's memory MCP server stores agent reasoning traces alongside their outcomes, enabling agents to learn from past ReAct loops and make better decisions on similar future tasks.