The ReAct Pattern: How AI Agents Reason and Act

How ReAct Works

ReAct was introduced in a 2022 paper by Yao et al. that showed language models perform better on multi-step tasks when they interleave reasoning traces with actions, rather than doing all reasoning first or all actions first. The mechanism is straightforward: at each step of the agent loop, the model generates a "thought" that explains its current understanding and its plan for the next action, then generates an "action" that specifies which tool to call and with what parameters. The tool executes, returns an "observation," and the model generates another thought based on the new information before taking the next action.

A concrete example makes the cycle clear. Suppose the task is "What was the revenue of Acme Corp in their most recent quarter?" The model's first thought might be: "I need to find Acme Corp's most recent quarterly earnings report. I'll search for it." The action is a web search for "Acme Corp quarterly earnings 2026." The observation is the search results. The model's second thought might be: "The search results mention Q1 2026 earnings of $4.2 billion. Let me verify this by checking the source." The action is a fetch of the specific earnings page. The observation is the page content. The third thought might be: "The page confirms Q1 2026 revenue of $4.2 billion. I have enough information to answer." The action is to generate the final response.

Each thought-action-observation cycle is one iteration of the agent loop. The pattern terminates when the model decides it has enough information to produce a final answer, when it encounters an unrecoverable error, or when the system hits a maximum iteration limit. The explicit reasoning at each step is what distinguishes ReAct from a model that simply calls tools without explaining why, and this explainability is the pattern's most important property for production systems.

Why the Reasoning Step Matters

The explicit reasoning step is not just a cosmetic feature for debugging. It measurably improves the model's performance on multi-step tasks. When a model jumps straight from observation to action without articulating its reasoning, it is more likely to make errors: calling the wrong tool, using wrong parameters, or losing track of the overall goal. The reasoning step forces the model to integrate new information with its existing plan before acting, which reduces errors and keeps the agent on track.

There is a direct analogy to how humans solve complex problems. A developer debugging a program does not randomly try fixes. They read the error, think about what it means, form a hypothesis, test it, and revise based on the result. The thinking step is what connects observations to productive actions. Without it, each action is disconnected from the last, and the problem-solving process degenerates into trial and error. ReAct gives language models the same structure, and the result is the same: more systematic, more effective problem-solving.

The debugging advantage is equally important. When a ReAct agent makes a mistake, you can read its reasoning trace to understand exactly where it went wrong. Was the thought incorrect (it misinterpreted the observation)? Was the action wrong (it chose the wrong tool despite correct reasoning)? Was the observation misleading (the tool returned bad data)? Each of these failures points to a different fix: improve the system prompt, adjust the tool definitions, or fix the tool itself. Without the reasoning trace, you see the wrong final answer but have no insight into why the agent produced it.

ReAct in Practice

Most modern agent frameworks implement ReAct implicitly rather than requiring you to format thoughts, actions, and observations explicitly. When you use LangGraph, CrewAI, or the OpenAI Agents SDK, the model generates tool calls as part of its response, and the framework handles executing the tools and feeding the results back. The "thought" may appear as the text the model generates before or alongside its tool calls, and the "observation" is the tool result that gets appended to the conversation. The pattern is the same, the labeling is just less explicit.

In OpenAI's tool calling API, for example, the model returns a response that contains both text content (the reasoning) and tool call objects (the actions). You execute the tool calls, return the results as tool messages, and call the model again. This is ReAct without the labels. In Anthropic's API, the model similarly generates thinking text and tool use blocks in the same response. The pattern has been absorbed into the standard model API design because it works better than the alternatives.

The practical challenge with ReAct is managing the context window as iterations accumulate. Each iteration adds the model's reasoning, the tool call, and the tool result to the conversation history. After 10 or 20 iterations, this history can consume a significant portion of the context window, pushing out the system instructions or earlier observations that are still relevant. The standard mitigation is to summarize older iterations, keeping only the key findings and discarding the verbose tool outputs and intermediate reasoning. The conversation history management guide covers these techniques, and the agent memory pillar addresses the broader problem of persisting knowledge across agent sessions.

When ReAct Works Best

ReAct is the right pattern when the task has a clear objective, the available tools can provide the information or take the actions needed, and the steps cannot be fully determined in advance because each step depends on what the previous step revealed. This describes the majority of practical agent tasks: research, customer service, code debugging, data analysis, and workflow automation. For these tasks, ReAct provides a good balance of autonomy (the agent decides what to do at each step) and controllability (you can see and constrain its reasoning).

ReAct is especially strong when the number of steps is moderate, say 3 to 15 iterations. Within this range, the reasoning traces remain manageable, the context window does not overflow, and the accumulated cost is reasonable. Tasks that naturally fall into this range include answering a complex question that requires multiple searches, resolving a customer issue that requires looking up account data and applying a policy, or fixing a bug that requires reading several files and running tests.

The pattern struggles with tasks that require deep planning, where the agent needs to consider many possible approaches and choose the best one before taking any action. ReAct is fundamentally greedy: it reasons about the immediate next step rather than the overall plan. For tasks where the first few actions can commit the agent to a suboptimal path, a plan-then-execute approach, where the model creates a complete plan before acting, may produce better results. Some systems combine both: plan first, then execute each step using ReAct, replanning when a step produces unexpected results.

ReAct vs Other Agentic Patterns

ReAct is one of several agentic patterns, and understanding the alternatives helps you choose the right one. Plan-then-execute separates planning from execution: the model creates a full plan (a list of steps), then a simpler executor runs each step. This is better for tasks with a known structure, like a deployment pipeline or a data processing workflow, where the steps are predictable even if the data is not. The trade-off is that the plan cannot easily adapt when an intermediate result changes what should happen next, unless you add replanning logic.

Reflexion adds an explicit self-evaluation step after the task is completed (or after each major step). The model critiques its own work, identifies weaknesses, and uses the critique to improve a second attempt. This is valuable for tasks where quality is hard to assess during execution, like writing code or producing a report, but it adds cost (an extra model call for each reflection) and latency. The self-evaluation patterns are covered in depth in the self-improving AI pillar.

Multi-agent systems distribute the task across multiple agents, each running its own ReAct loop with its own tools and context. A coordinator agent delegates sub-tasks and synthesizes results. This scales better for complex tasks that span multiple domains, but it adds coordination overhead and the risk that agents produce inconsistent results. The multi-agent systems page covers when this is worth the complexity.

In practice, these patterns are not mutually exclusive. A system might use plan-then-execute for the high-level task breakdown, ReAct for each individual step, and reflexion for a final quality check. The choice depends on the task structure, the acceptable cost, and how much autonomy the agent needs at each level.