The ReAct Pattern: How an Agent Reasons and Acts in a Loop

The ReAct pattern is a way of running an AI agent in which the model alternates between three steps: it writes a short thought about what to do next, it calls one tool, and it reads the tool's result. It repeats that cycle until it has enough information to answer, or until a limit stops it. The name joins the two halves of the cycle, Reasoning and Acting.

The pattern matters because a language model on its own can only use what it learned in training. ReAct lets the model fetch facts it does not have, check its own assumptions against real data, and change its plan when a result surprises it. Most production agents that call tools run some version of this loop today.

This article explains where the pattern came from, traces one task step by step, compares ReAct with the approaches it replaced, and covers the limits and controls that make it safe to run.

What is the ReAct pattern?

ReAct was introduced in the paper "ReAct: Synergizing Reasoning and Acting in Language Models" by Shunyu Yao and colleagues at Princeton University and Google. The paper asked the model to produce reasoning and actions interleaved in one sequence, so that each one could inform the other. The reasoning helps the model create, track, and update a plan, while the actions bring in outside information from a search engine, an API, or a simulated environment.

The loop has three named parts:

• Thought. A short piece of text in which the model states what it knows, what it still needs, and what it will do next. The thought changes nothing in the outside world.
• Action. One call to a tool, with arguments. A tool is any function the agent is allowed to run, such as a database query, a search, or an API request.
• Observation. The result the tool returned, fed back to the model as new input.

The results in the paper were strong for their time. On two interactive benchmarks, ALFWorld (a text-based household task game) and WebShop (a simulated online store), ReAct beat imitation learning and reinforcement learning methods by 34 and 10 percentage points of absolute success rate. It did so with only one or two worked examples in its instructions. On question answering with a simple Wikipedia API, the paper reported that access to real search results reduced the invented facts that pure reasoning produced.

A worked example, step by step

Consider a customer support agent with three tools: get_order(order_id), get_shipment(tracking_id), and get_refund_policy(region). A customer writes: "My order 4417 never arrived. When will I get my money back?"

The agent cannot answer from memory, because it has never seen this order. Here is a ReAct trace of how it works through the question:

Thought 1: I need the order record to find its status and tracking number.
Action 1: get_order(order_id="4417")
Observation 1: {"status": "shipped", "tracking_id": "TRK-88120",
                "region": "EU", "total": 64.00}

Thought 2: The order shipped. I should check whether the carrier delivered it.
Action 2: get_shipment(tracking_id="TRK-88120")
Observation 2: {"state": "lost_in_transit", "carrier_case": "open",
                "days_since_last_scan": 9}

Thought 3: The parcel is marked lost. I need the refund rule for EU orders.
Action 3: get_refund_policy(region="EU")
Observation 3: {"lost_parcel": "full refund", "processing_days": "5 to 7",
                "requires_carrier_case": true}

Thought 4: A carrier case is already open, so the rule is met.
           I can answer the customer now.
Final answer: Your parcel was marked lost by the carrier. You qualify for a
full refund of 64.00, which usually arrives within 5 to 7 business days.

Three details in this trace explain why the pattern works. First, the second action depended on a value, TRK-88120, that the agent only learned from the first observation, so no fixed script written in advance could have made that call. Second, the observation in step 2 changed the plan: the agent had expected a delivery date and found a lost parcel instead, so it went to the refund policy. Third, the thought in step 4 checked a condition from the policy before answering, which is the kind of check that prevents a wrong promise to a customer.

How is ReAct different from chain-of-thought and tool calling alone?

ReAct combines two older ideas, and each one fails in a specific way on its own.

Chain-of-thought asks the model to reason step by step before answering, without any tools. It improves accuracy on problems where every fact is already in the question, such as arithmetic word problems. On the support question above, chain-of-thought has no access to order 4417, so the model can only guess, and a guess written as confident reasoning is harder to detect than a short wrong answer.

Act-only tool calling lets the model call tools without writing any reasoning between calls. It can fetch the order, but it has no place to record why it is making the next call or what it learned from the last one. On longer tasks this approach loses track of its goal, repeats calls, or stops early, because nothing in the sequence carries the plan forward.

ReAct keeps the tools from the second approach and the written reasoning from the first. The thoughts carry the plan between steps, and the observations keep the reasoning tied to real data.

How is ReAct implemented with native tool calling?

The original paper ran ReAct as plain text. The model wrote lines starting with "Thought:" and "Action:", and the surrounding code parsed the action line, ran the tool, and appended an "Observation:" line. That approach worked, but parsing free text was fragile, because a model that misspelled a tool name or wrote broken arguments stopped the loop.

Current model APIs support native tool calling, in which the developer declares each tool with a name, a description, and a JSON schema for its arguments. The model returns a structured tool call instead of a text line, so the code no longer has to parse anything. The loop itself stays the same:

1. Send the conversation, including the tool definitions, to the model.
2. If the response contains a tool call, validate the arguments, run the tool, and append the result as a tool message.
3. If the response contains a final answer, return it and stop.
4. Otherwise, go back to step 1.

The thought is now often the short text the model writes before its tool call, or a separate reasoning output that some models produce. Either way, it is worth keeping, because it is the only record of why the agent took each action. Logging the thoughts alongside the tool calls is what makes a failed run possible to debug later.

This loop is the orchestrator in a full agent architecture. In the seven-layer design of an AI agent, the ReAct loop sits in layer 2, between the interface that receives the task and the LLM layer, tools, and memory that each step uses.

Want to see how ReAct fits with the other agent patterns? Grokking Agentic Design Patterns covers reasoning loops, planning, tool use, memory, and guardrails, with a worked design for each pattern.

When should a ReAct loop stop?

A ReAct loop has no natural end, so the code around it must define one. A well-designed agent uses several stopping conditions at the same time, and the first one reached ends the run.

• A final answer. The normal case: the model decides it has enough information and returns an answer instead of a tool call.
• A step budget. A hard maximum on the number of loop iterations, often between 10 and 25 for interactive tasks. The support example needed four.
• A token or cost budget. A cap on total tokens for the run, since each step resends the growing conversation.
• A wall clock limit. A maximum time, such as two minutes, for tasks where a user is waiting.
• A repeated action. The same tool called with the same arguments two or three times in a row usually means the agent is stuck.

When a budget stops the loop, the agent should not simply fail. It should return what it found so far, state what it could not finish, and hand the task to a person if the task matters.

What are the failure modes of ReAct, and how do you control them?

Each failure below appears in real agent systems, and each has a direct control.

Repeated loops. The agent calls the same tool again and again because it misreads the result or expects a different answer. The control is the repeated-action check above, plus an observation that tells the model plainly when a call returned nothing new.

Invented observations. In text-based ReAct, the model can write its own "Observation:" line instead of waiting for the tool, and then reason from data that does not exist. Native tool calling removes most of this risk, because only the code can add a tool result to the conversation. Text-based loops should stop generation at the action line so the model never writes the observation itself.

Context growth. Every thought, call, and observation is appended to the conversation, so step 15 sends far more tokens than step 1. Large observations make this worse: a search that returns 40 kilobytes of text fills the context quickly. The controls are to trim tool outputs to the fields the agent needs, to summarize older steps, and to store large results outside the conversation and pass a reference instead.

Cost and latency per step. Each iteration is a full model call, so a 12-step run costs roughly 12 calls and takes 12 round trips. The controls are the budgets above, a cheaper model for simple steps, and running independent tool calls in parallel when the model requests several at once.

Unsafe actions. An agent that can call a tool that sends money or deletes records can do so because of one bad thought. The control is outside the loop: limit each tool's permissions, validate arguments before running them, and require human approval for actions that cannot be reversed.

When should you use ReAct instead of plan-and-execute?

The main alternative is plan-and-execute, a pattern in which the model writes a complete plan first and then runs each step, often with a smaller model or plain code. It replans only when a step fails. The two patterns suit different tasks.

ReAct suits tasks where the next step depends on what the last step returned, as in the support example. It adapts well to surprises, and it needs no separate planning stage. Its costs are a model call per step and a run that is harder to predict in advance.

Plan-and-execute suits tasks whose steps are known early and do not change much, such as producing a report from five fixed data sources. The plan can be reviewed before anything runs, the steps can run in parallel, and the total cost is easier to estimate. Its weakness is that a plan written before seeing any data can be wrong, and replanning adds its own cost.

Many production systems combine the two. A planner writes the high-level steps, and each step runs as a small ReAct loop with its own step budget. This keeps the overall run predictable while each step can still react to the data it finds.

Frequently asked questions

What does ReAct stand for? ReAct stands for Reasoning and Acting. The name describes the loop, in which a language model alternates between writing a thought, calling a tool, and reading the tool's result until it can answer.

Is ReAct the same as React, the JavaScript library? No. The ReAct agent pattern and the React user interface library are unrelated and share only a similar name. The agent pattern is usually written with a capital A to tell them apart.

Do I still need ReAct if my model supports tool calling? Yes, because tool calling is only the mechanism for one step. ReAct is the loop that decides to call a tool, reads the result, and decides again. Native tool calling makes that loop more reliable, but your code still runs it and still needs its stopping rules.

How many steps should a ReAct agent be allowed? Most interactive agents use a step budget between 10 and 25, combined with token and time limits. Start with the number of steps a typical task needs, add a margin, and measure how often real runs reach the limit.

What is the difference between ReAct and chain-of-thought? Chain-of-thought reasons step by step without tools, so it can only use facts already in the question or in its training data. ReAct adds tool calls between the reasoning steps, so the model can look up facts and correct its plan based on real results.

Is ReAct good for multi-agent systems? Each agent in a multi-agent system usually runs its own ReAct loop. The multi-agent design decides how agents divide the work, while ReAct decides how each agent completes its part.

Related reading

• Design an AI Agent: The 7-Layer Blueprint
• Agentic Design Patterns: The Patterns Behind Production AI Agents
• Single-Agent vs Multi-Agent Systems
• How Do You Design a Multi-Agent System?

Ready to build agents that stop, recover, and stay within budget? Grokking Agentic Design Patterns teaches the reasoning, planning, and reliability patterns behind production agents, one pattern at a time.