ReAct Pattern: Interleaving Reasoning and Action for LLM Agents › The ReAct Formulation
Language AI HandbookAll chapters ReAct Pattern: Interleaving Reasoning and Action for LLM Agents › The ReAct FormulationOne section · Sections in this chapter2 / 14 ↓
Reading tools Definitions & inline links
Choose your expertise level to adjust how many terms are explained. Beginners see more tooltips, experts see fewer to maintain reading flow. Hover over underlined terms for instant definitions.
Article links
Make inline references clickable
ReAct, introduced by Yao et al. (2022), formalizes the interaction between an LLM and an environment as a structured sequence of thought-action-observation triples. This mathematical framework characterizes how the agent maintains state and progresses toward goals through iterative refinement.
The core insight behind the formulation is that an agent solving a task should not be treated as a single forward pass through a model, but as a dynamic process unfolding over time. Each moment in that process consists of three things: what the agent currently thinks (thought), what it chooses to do (action), and what it learns from doing it (observation). Concatenate enough of these moments and you have a complete trace of how the agent reasoned its way to an answer.
The model maintains a trajectory composed of these sequential triples, represented mathematically as:
where:
- : the complete trajectory of the ReAct session, representing the full history of the agent's reasoning and actions
- : the thought generated at step , containing the model's internal reasoning about its current state
- : the action taken at step , representing a specific tool invocation from the available action space
- : the observation received after executing action , giving environmental feedback from the external system
Each step in this sequence consists of three distinct components working in concert:
- Thought (): The model's internal reasoning about the current state, including what it currently knows, what information it still needs to acquire, and what specific action to take next to progress toward the goal. Thoughts are free-form natural language, though they should be focused and task-relevant.
- Action (): A specific tool invocation with parameters, drawn from a predefined action space available to the agent. Actions must be parseable by the environment, so their format is more constrained than thoughts.
- Observation (): The factual result returned by the environment after executing the action. This provides ground truth for subsequent reasoning. Observations are not generated by the model; they come from external systems.
This formulation differs from Chain-of-Thought prompting, where reasoning occurs entirely within the model's internal monologue without environmental interaction. In ReAct, thoughts drive actions that change the external state or retrieve new information, and observations feed back to inform subsequent reasoning steps. The environment becomes an integral part of the computational graph rather than a passive recipient of outputs.
The formal trajectory also is the agent's working memory. Because the entire history is included in the context window at each step, the model at step can reason over everything it has learned in steps through . This is not memory in the neural sense, but memory through explicit context: a written record the model can attend to. The limitation is that this memory is bounded by the context window, and we will examine that constraint closely in the limitations section.
The Action Space
The action space defines what operations the agent can perform. Different tasks call for different action spaces, and defining the right set of tools is one of the most consequential design decisions in building a ReAct agent. Too few tools and the agent cannot gather the information it needs. Too many tools and the model struggles to select the right one or generates actions that match no tool in the registry.
Action spaces typically fall into four categories:
- Information retrieval: Search queries, database lookups, document retrieval, API calls to external knowledge sources, or Wikipedia lookups. These expand what the agent knows beyond its training data.
- Computation: Calculator operations, code execution environments, mathematical solvers, symbolic reasoning engines, or spreadsheet functions. These offload precise numerical or logical work to deterministic systems.
- Interaction: Sending messages, filling forms, controlling external systems, or manipulating digital interfaces. These apply to agents that must affect the world, not just query it.
- Termination: A
finishoransweraction that signals task completion and carries the final answer. Without this, the agent has no way to declare it is done.
For a question-answering agent, the minimal action space is often just search[query] and finish[answer]. For a coding agent, it might include write_file[path, content], run_code[code], read_file[path], and search_docs[query]. The key principle is that the action space should be complete enough to solve the intended class of problems, but minimal enough that the model can reliably select and format the correct action.
Connecting to the Policy Formulation
If you think of the agent as a policy in the reinforcement learning sense, each thought and action can be understood as the policy making a decision conditioned on the full trajectory seen so far:
where is the language model with parameters . The thought is generated first, conditioning on all prior context, and then the action is generated conditioned on all prior context including the new thought. This two-stage generation is important: the thought gives the model space to reason before committing to an action, which empirically reduces the rate of nonsensical or irrelevant tool calls.
The Reasoning-Action Interleaving
We might naturally ask: why interleave reasoning with action rather than separating these phases into distinct stages? Consider the alternative approaches and their inherent limitations.
The first alternative, Reason-then-Act, generates a complete, complete plan before executing any actions, then follows that plan rigidly. This strategy fails when intermediate steps reveal unexpected information that invalidates subsequent parts of the plan. Imagine planning a multi-day road trip in detail, then discovering the first highway is closed. Your entire plan, including every turn and overnight stop, may need to be rewritten from scratch. For knowledge-intensive tasks, the plan made before any retrieval is essentially a plan made in ignorance, and the more complex the task, the more likely some intermediate discovery will invalidate the original plan.
The second alternative, Act-without-Reason, calls tools reactively based on pattern matching or simple heuristics without strategic planning. This approach often leads the agent into fruitless search loops, redundant queries, or missed connections between disparate pieces of information. Without explicit reasoning to guide tool selection, the agent lacks the strategic overview necessary for efficient problem-solving. It may retrieve the right facts in the wrong order, fail to recognize when a retrieved fact answers a key question, or repeat the same failed search query hoping for a different result.
The third approach, ReAct itself, tightly couples each action to explicit reasoning, and allows each observation to immediately inform the next reasoning step. The agent maintains flexibility while preserving strategic coherence. When the first search returns an unexpected result, the thought phase immediately processes that result, updates the agent's understanding of the problem, and formulates a better next step. The tight coupling creates a self-correcting system that approximates the scientific method by generating a hypothesis, testing it, observing the result, and revising the hypothesis.
This iterative refinement allows the model to recover from errors dynamically. If a search returns irrelevant results, the thought process acknowledges this mismatch and reformulates the query with better keywords. If a calculation yields an unexpected value, the model can verify its assumptions or check for unit conversion errors. If an API returns an error, the model can try an alternative tool or reformulate the request. None of these recoveries are possible in a purely plan-first or purely reactive system.
