ReAct prompting, short for reasoning and acting, is a prompting pattern in which a language model alternates between written reasoning steps, tool actions and their observations, repeating the cycle until it can give a final answer. In AI agents it is the foundational control loop: the model thinks about what it needs, calls a search engine, calculator or API, reads the result and decides what to do next.
The pattern was introduced in 2022 by researchers from Princeton University and Google as a way to combine chain-of-thought reasoning with grounded actions. Reasoning alone tends to hallucinate facts, and acting alone lacks a plan; interleaving the two lets each correct the other, and that idea now underlies most agent frameworks.
How the ReAct loop works
A ReAct agent runs a thought, action, observation cycle. The prompt defines the available tools, the expected format and usually a few worked examples, and the surrounding program executes each action and appends its result to the conversation.
| Element | Produced by | Purpose |
|---|---|---|
| Thought | The model | States the current goal, plan or interpretation |
| Action | The model | Names a tool and its arguments |
| Observation | The tool, via the runtime | Returns real data such as search results |
| Final answer | The model | Ends the loop when enough evidence exists |
The runtime is essential. The model only writes the action as text or a structured tool call; the controlling program parses it, executes it, inserts the observation and calls the model again. The loop ends when the model emits a final answer or when the program reaches a maximum number of steps, commonly set between 5 and 20.
In the original text-based form, the model wrote lines such as “Thought:”, “Action: Search[query]” and “Observation:”, and the runtime stopped generation at each action. Modern implementations use native tool calling, where actions are structured JSON objects, but the cycle of reasoning, acting and observing is the same.
ReAct compared with other agent strategies
ReAct is one of several ways to organize an agent’s reasoning, and its defining choice is deciding one step at a time based on fresh observations. The table compares it with neighboring approaches.
| Strategy | How it proceeds | Strength | Weakness |
|---|---|---|---|
| Chain-of-thought | Reasons in text, no tools | Simple, good for closed problems | Cannot verify or fetch facts |
| Act-only prompting | Calls tools without explicit reasoning | Fewer tokens | Poor recovery from surprises |
| ReAct | Interleaves reasoning, tool calls and observations | Adaptive and grounded | Many model calls, can loop |
| Plan-and-execute | Writes a full plan first, then executes steps | Efficient for predictable tasks | Brittle when early steps fail |
| Reflexion-style self-critique | Adds reflection after failed attempts | Learns within a session | Higher cost and latency |
In practice these strategies are combined. Many systems use agent planning to produce a rough outline and then run ReAct loops for each step. In a multi-agent system, each specialist agent often runs its own ReAct loop under an orchestrator.
Designing an effective ReAct prompt
The quality of a ReAct agent depends heavily on tool descriptions and stopping rules rather than on clever wording. Clear tools reduce wrong actions, and explicit limits prevent runaway loops.
| Design choice | Recommended practice | Reason |
|---|---|---|
| Tool descriptions | One clear purpose, typed arguments, example usage | The model selects tools from these texts |
| Number of tools | Keep the set small and distinct | Overlapping tools cause wrong choices |
| Observation size | Truncate or summarize long tool output | Protects the context window |
| Step limit | Hard cap, for example 10 steps | Prevents endless loops and cost spikes |
| Error handling | Return readable error messages as observations | Lets the model correct its action |
| Few-shot examples | One or two complete traces | Teaches format and good tool use |
With current reasoning models, the explicit “Thought” text is often replaced by internal reasoning that is not shown to the runtime. The pattern still applies: the model reasons, chooses a tool, receives an observation and continues. Protocols such as MCP standardize how tools are exposed to such loops.
Strengths and costs
The main strength of ReAct prompting is grounding: claims can be checked against real data during the task, which reduces hallucination on fact-heavy questions. The visible trace also improves interpretability, since a human can see why each action was taken.
The main costs are latency, token usage and unpredictability. Each step requires a full model call, and the context grows with every observation, so a ten-step task can consume many times the tokens of a single answer. Reasoning traces are also not guaranteed to reflect the model’s actual decision process, so they support but do not replace evaluation and monitoring.
Failure modes and safeguards
ReAct agents fail in recognizable ways, and each failure has a standard safeguard. Production systems should plan for all of them from the start.
| Failure | Symptom | Safeguard |
|---|---|---|
| Looping | The same action repeats with no progress | Step limit and repeated-action detection |
| Hallucinated tools or arguments | Calls to nonexistent functions | Schema validation and strict tool calling |
| Premature answer | Stops before gathering evidence | Instructions requiring verification |
| Context overflow | Early facts are lost or truncated | Summarize observations, use agent memory |
| Injected instructions in observations | Agent follows text found in web pages | Treat tool output as data, restrict permissions |
For actions with real consequences, such as payments, deletions or sending messages, a human-in-the-loop approval step should sit between the model’s chosen action and its execution. Prompt injection through observations is the most serious risk, because any text a tool returns becomes part of the model’s input.
The short version
Imagine a detective solving a case. They think about what they need to know, go and check a clue, look at what they found, then think again about the next step. They do not guess the whole answer at the start.
ReAct prompting makes a language model work the same way. It thinks, uses a tool, looks at the result and repeats, so its final answer is based on information it actually checked rather than on memory alone.
Where it makes a difference
An IT support team deploys an agent that answers employee questions about laptop problems. The agent has three tools: a search over the internal knowledge base, a lookup of the employee’s device record and a ticket creation function that requires human approval before execution.
When an employee reports that a laptop cannot connect to the office VPN, the agent first reasons that it needs the device details, looks up the record and observes an outdated VPN client version. It then searches the knowledge base, finds the upgrade procedure for that version and returns step-by-step instructions. Only when the employee reports that the upgrade failed does the agent draft a ticket. The ReAct loop resolves most routine requests without staff involvement, and every action is visible in the trace for later review.