What Is ReAct Prompting and How the Thought–Action–Observation Loop Gives LLMs the Ability to Act

Every language model you have ever used is fundamentally incapable of checking whether something is true right now. It can reason about what the current version of a framework probably is, based on patterns absorbed during training — but it cannot look it up. ReAct prompting is the mechanism that breaks this constraint, not by teaching the model new facts, but by giving it a structured protocol for reaching outside its own probability space and returning with evidence.

The counterintuitive thing is that this reaching-out doesn’t happen through any special capacity in the model itself. It happens because the prompt is structured to produce output that resembles a tool call — and the surrounding runtime intercepts that output and executes it. The model isn’t acting. It’s describing what action it would take, and the scaffolding does the rest.

The Loop That Taught Language Models to Take Action

Most prompting techniques keep the model entirely inside its own latent space: you send text, the model generates text, the exchange ends. ReAct breaks this pattern by treating the model’s output not as a terminal answer but as a turn in an ongoing loop. Think of it like a feedback loop in control theory — the result of each action becomes the input to the next reasoning step, and the loop runs until the gap between what the model knows and what the question requires narrows to zero.

Each turn can produce either a reasoning trace or an action request; the runtime executes the action and injects the result back as an observation, and the loop continues until the model reaches a final answer.

What is ReAct prompting?

ReAct prompting is a technique that interleaves reasoning steps with tool calls inside a single prompt sequence. The name derives from “Reasoning + Acting” — a framework introduced by Yao et al. in “ReAct: Synergizing Reasoning and Acting in Language Models,” published at ICLR 2023 (ArXiv 2210.03629). The model alternates between thinking through what it needs to know and requesting information from external sources — search engines, calculators, APIs, databases — before reasoning further and eventually producing a grounded answer.

When the paper appeared in October 2022, the insight felt almost too simple: if you let the model articulate its reasoning before issuing a tool call, it issues better tool calls. If you inject the tool’s result back into that reasoning trace, the model can reason about the result and decide whether another call is needed. The loop is ordinary few-shot conditioning applied to an agent’s action cycle.

What makes this architecturally distinct from simple tool use is the coupling. In ReAct, the reasoning traces and the action results live in the same Context Window, visible to the model throughout the entire interaction. Each observation actively shapes the next reasoning step — the model isn’t executing a fixed script; it is navigating an information gap, step by step.

How does the Thought-Action-Observation loop in ReAct prompting work step by step?

The loop has three phases that repeat until the model produces a final answer:

Thought: The model generates a reasoning trace — a natural-language description of what it currently knows, what information gap exists, and what action would resolve that gap. This trace is not hidden scaffolding; it appears in the model’s output and remains in the context for all subsequent steps, creating an auditable record of the model’s decision process.

Action: The model emits a structured directive — typically a function call format the runtime is watching for. The runtime intercepts this, executes the referenced tool with the supplied parameters, and holds the result without returning control to the model yet.

Observation: The tool’s result is injected back into the context as new information. The model now has grounded data to incorporate into the next thought step.

A single query might complete three or four full iterations before the model has enough information to converge on a final answer. At each iteration, the model has access to its entire prior reasoning trace plus all accumulated observations — a growing record of what was checked and what was found. The “Thought–Action–Observation” label is the widely adopted name for this pattern; the original paper describes the mechanism as interleaved reasoning traces and actions, without naming the three phases as a formal triple.

The Anatomy of a ReAct Prompt

A ReAct prompt is, at its core, a specific variant of few-shot prompting. It contains worked examples of the loop running correctly, which conditions the model to reproduce the same pattern on a new problem — the same way a lab notebook conditions a researcher on which observations to collect before drawing a conclusion. Understanding what those examples must contain reveals why the format is more structured than it looks from the outside.

What are the parts of a ReAct prompt?

Four components define a well-formed ReAct prompt:

Task instruction: Describes the overall task and establishes the expected loop behavior. The model is told to reason before acting, and informed that it will receive observations after each action request. Without this framing, instruction-following models tend to generate direct answers rather than initiating a tool call loop.

Available tools: A list — typically embedded in the system prompt or prepended as context — of the tools the model may call, their names, input signatures, and what they return. The model cannot distinguish valid actions from hallucinated ones without this registry. Tool description quality directly predicts the quality of tool selection during the loop.

Few-shot examples: Demonstrations of the full Thought → Action → Observation loop running correctly on similar problems. These examples are what actually condition the model to stay in the loop format rather than short-circuiting to a direct answer. The number of examples needed scales inversely with model capability; stronger instruction-following models require fewer demonstrations to maintain the format reliably across varied inputs.

The current query: The actual problem, appended after the examples. The model continues the loop pattern it observed in the demonstrations.

The Prompt Chaining principle underlies the loop’s dynamics — each step’s output becomes the next step’s input — but in ReAct the chain is dynamic: neither its length nor the specific tool calls are predetermined. The chain terminates when the model emits a final answer, not when a fixed number of steps completes.

How is ReAct prompting different from chain-of-thought prompting?

Chain-of-Thought prompting and ReAct prompting appear structurally similar: both involve the model generating intermediate steps before producing a final answer. The difference lies in where those intermediate steps can reach.

Chain-of-thought keeps the model inside its own latent space. Every step in the chain is a token the model generates from its prior distribution. The chain cannot incorporate new external facts; it organizes what the model already knows into a more structured path toward an answer. For questions the model can answer from training — mathematical reasoning, code tracing, logical deduction over a known problem — chain-of-thought is often sufficient and simpler to implement.

Not self-contained reasoning. Grounded retrieval.

Where chain-of-thought asks “what do I already know that leads to this answer?”, ReAct asks “what do I need to verify before I can answer reliably?”. The distinction becomes critical when correctness depends on information outside the training distribution: the current state of a database, a live API response, the output of a calculation the model might estimate incorrectly, or the contents of a document the model has never seen.

On knowledge-intensive tasks, ReAct combined with chain-of-thought and self-consistency outperforms other prompting methods (Prompt Engineering Guide). On the HotpotQA and FEVER benchmarks, grounding via Wikipedia API interaction significantly reduced hallucination and error propagation compared to reasoning chains operating without external access (ArXiv 2210.03629).

What the Loop Predicts — and Where It Stops Working

Understanding the mechanism makes certain engineering consequences follow predictably.

If a task requires facts outside the model’s training data, ReAct reduces hallucination — not because the model becomes more careful, but because it replaces probabilistic guessing with a retrieval step. The observation displaces the guess.

If a task decomposes into a sequence of independently verifiable sub-problems, ReAct typically outperforms either pure chain-of-thought or fire-and-forget tool calls. The reasoning traces keep the model oriented between actions; without them, models tend to issue poorly targeted tool calls that retrieve the wrong information or fail to recognize when retrieved information is already sufficient to answer.

If the tools themselves are poorly described — ambiguous input signatures, inconsistent return formats, no indication of failure modes — the loop degrades rapidly. The model reasons from its observations, and if observations are noisy or ambiguous, each subsequent reasoning step compounds the error. Tool specification quality is a direct predictor of ReAct output quality; the loop amplifies what the tools give it.

On the ALFWorld embodied agent benchmark, ReAct achieved a +34% absolute success rate improvement over prior baselines; on the WebShop product-search benchmark, it achieved +10% over imitation and reinforcement learning approaches (ArXiv 2210.03629). These figures are from 2022, measured against the baselines available at that time — current agentic systems may differ substantially.

Rule of thumb: Use ReAct when correctness requires grounding in external information; use chain-of-thought alone when correctness requires organizing information the model already has.

When it breaks: ReAct loops stall when the model misidentifies what information it needs, calls the wrong tool repeatedly, or fails to converge from noisy observations — each failed iteration consuming context window space until the loop exceeds its budget or the model emits a hallucinated final answer that superficially resembles convergence.

Framework implementation status

The two most cited framework implementations are currently in migration:

Framework compatibility notes:

• LangChain create_react_agent: Deprecated in LangGraph V1.0. The recommended replacement is create_agent from langchain.agents, which has community-reported missing features including message history rewriting. Verify current migration status before adopting. (LangChain Docs, LangGraph GitHub)
• LlamaIndex Python ReActAgent: The current implementation — ReActAgent from llama_index.core.agent.workflow — is not deprecated, but the import path has moved from the older llama_index.core.agent. (LlamaIndex Docs)
• LlamaIndex TypeScript ReActAgent: Deprecated in favor of AgentWorkflow. (LlamaIndex Docs)

ReAct itself is model-agnostic — it works with any instruction-following LLM, without requiring native function-calling API support. Frameworks like Pydantic AI implement ReAct-style loops where the model participates through prompt format conditioning alone, making the pattern accessible across model APIs that expose no special tool primitives.

The Data Says

ReAct’s contribution wasn’t new reasoning capacity — language models could already reason, and the infrastructure for tool calls already existed. Its contribution was the interleaving: the decision to let reasoning traces and tool results share a context window, each one informing the next. That structural choice is what separates a model that generates a plausible-sounding answer from a model that checks before committing. The loop is simple. What it makes possible is not.