The React Prompting Framework: How Reasoning and Acting Work Together in LLMs

ReAct is a prompting pattern that interleaves two distinct modes of model output: reasoning traces and task-specific actions. The reasoning trace is the model’s internal chain-of-thought — a plain-language sequence of observations and deductions. The action is a structured call to an external tool, like a search query, a calculator expression, or a database lookup. The model alternates between thinking and doing, and each action’s result feeds back into the next reasoning step.

The framework gets its name from this pairing: Reasoning + Acting. It was introduced in a 2022 paper by Yao et al., and its core insight is that neither mode works well alone. Pure chain-of-thought can hallucinate facts because the model has no way to verify them. Pure tool-calling without reasoning produces disconnected actions — the model queries a search engine, gets an answer, and has no internal structure for deciding what to query next. ReAct forces the two together, and the result is a loop that resembles how a human engineer debugs a system: form a hypothesis, check the evidence, revise.

This post walks through one complete ReAct session end-to-end. The general principles are embedded in the walkthrough rather than listed separately.

The Anatomy of a ReAct Prompt

A ReAct prompt has three required components: a task statement, a set of available actions, and an instruction to interleave “Thought:” and “Action:” lines in a specific format.

The task statement works the same as any prompt — it should specify the goal, the constraints, and the format of the final answer. The available actions section is a small spec sheet that lists each tool the model may call, its exact syntax, and what it returns. The format instruction tells the model to output a structured loop like this:

Thought: <reasoning step>
Action: <tool name>(<input>)
Observation: <result of action>

The model produces the Thought and Action lines. The Observation line comes from the external system — the search API, the calculator, whatever the tool returns. The model reads the Observation, generates another Thought, issues another Action, and repeats until it has enough information to produce a final answer.

The key constraint is that the model cannot skip from Thought directly to Answer. Every claim in the final answer must be traceable back to an Observation from an actual tool call. If the model tries to assert something it hasn’t verified, the format forces a stop.

Case Study: Verifying a Financial Claim

Here is a complete ReAct session built for a task that requires both reasoning and external verification. The task: determine whether the statement “The company that acquired Activision Blizzard also produces the Unity game engine” is true or false.

The initial prompt looks like this:

Task: Determine whether the following statement is true or false:
"The company that acquired Activision Blizzard also produces the Unity game engine."

You have access to a single tool: search(query), which returns a list of search result snippets.

Follow this format exactly:
Thought: your reasoning about what to check
Action: search(query)
Observation: the result of your search

Continue the Thought/Action/Observation loop until you can state the final answer.
When ready, output: Answer: <true or false>, followed by a one-sentence justification.

This prompt does not tell the model the answer. It provides a mechanism for finding it.

Round 1: First Query

The model’s first output is a Thought that decomposes the task into two separate facts that need verification:

Thought: I need to identify two distinct facts. First, which company acquired Activision Blizzard. Second, which company produces the Unity game engine. I will start by querying the acquisition.
Action: search("company that acquired Activision Blizzard")
Observation: "Microsoft completed its $68.7 billion acquisition of Activision Blizzard in October 2023, making it the company's largest acquisition in its history."

This is the key first step — notice the model did not assume it knew the answer. It decomposed the full statement into independently checkable components and issued a query for the first one.

Round 2: Verifying the Second Fact

The observation confirms the acquirer is Microsoft. The model now needs the second fact — who makes Unity.

Thought: The acquisition target was Activision Blizzard, and the acquiring company is Microsoft. Now I need to confirm who produces the Unity game engine. I recall that Unity Technologies is a separate company from Microsoft, but I will verify this with a search.
Action: search("company that produces the Unity game engine")
Observation: "Unity is developed by Unity Technologies, a San Francisco-based company. Unity Technologies was publicly listed on the NYSE until its acquisition in 2022 by an investment consortium led by Silver Lake."

The observation confirms the model’s prior: Unity Technologies, not Microsoft, produces the engine.

Round 3: Cross-Validating the Key Claim

The model has two separate observations that appear to answer the question. But the statement under test is a conjunction — it requires both parts to hold. The model’s reasoning below shows it checking for a subtle failure mode: whether either fact has changed or whether the two companies have any ownership overlap.

Thought: Microsoft acquired Activision Blizzard. Unity Technologies produces Unity. These are different entities. However, I should verify that there is no recently announced merger or acquisition between Microsoft and Unity Technologies that would change this. I will do one more search to confirm these two companies remain independent.
Action: search("Microsoft Unity Technologies acquisition merger")
Observation: "No acquisition or merger between Microsoft and Unity Technologies has been announced. In 2022, Unity Technologies was acquired by an investment consortium, not by Microsoft. Microsoft's gaming division uses Unity for some internal tools, but no ownership relationship exists."

This third round is where ReAct distinguishes itself from a single question-answering call. A plain “is this statement true?” prompt would likely produce a confident yes-or-no answer without any verification, and a wrong guess would sail through unchecked. The ReAct loop forces the model to double-check the one assumption on which the whole answer rests.

Round 4: Final Answer

The model now has three observations that form a consistent picture. It produces the final output:

Thought: I have verified two facts. Fact 1: Microsoft acquired Activision Blizzard in 2023. Fact 2: Unity is produced by Unity Technologies, not Microsoft. I also confirmed that Microsoft and Unity Technologies have no ownership relationship. The statement claims the same company also produces Unity, which is false.
Answer: False. Microsoft acquired Activision Blizzard, but the Unity engine is produced by Unity Technologies, a separate company.

The final answer is grounded in observed evidence. The model could have produced the same answer from its training data — but it could not have guaranteed the answer was current, and a different phrasing of the question might have triggered a confident but outdated response. The ReAct loop converts a guess into a checked fact.

Why the Reasoning Trace Matters More Than the Actions

The visible loop is the tool calls, but the reasoning trace does more work than the actions themselves. In the case study, the third search was pure defensive reasoning — the model had already found the answer, but the trace forced it to consider a counterfactual before committing. That kind of self-check is the entire point of ReAct.

The trace also creates an audit trail. If the final answer is wrong, you can read the Thought lines and see exactly where the reasoning went astray — a bad assumption, a faulty query, a misread observation. This is directly analogous to reading a stack trace in a failed test run. You are not debugging a black box; you are reading the model’s step-by-step logic.

In practice, the reasoning trace serves a second purpose: it keeps the model honest about what it does not know. A chain-of-thought prompt that never calls a tool will happily generate a coherent narrative that drifts into fabrication. The ReAct format treats every claim as provisional until it is pinned to an Observation.

Formatting Discipline: The Highest-Failure-Risk Area

The most common way a ReAct implementation breaks is the model quitting the loop too early. The model will occasionally emit a Thought, skip the Action, and jump straight to an Answer. This happens when the prompt fails to specify the loop termination condition clearly enough.

Two fixes matter. First, state explicitly in the prompt that an Answer is only valid after at least one Observation. Second, specify the maximum number of Thought/Action/Observation cycles — typically three to five — before the model must produce its final answer. This prevents infinite loops on tasks where the search results keep returning noise.

A second common failure is the model issuing a malformed action — misspelling the tool name, passing arguments in the wrong order, or using JSON when the tool expects plain text. Treat the tool spec section like an API contract: give one canonical example of each tool invocation and one correct observation format. The model will pattern-match to that example with high reliability.

A third failure is context accumulation. Each Observation consumes tokens in the context window, and after several rounds the earlier Thoughts and Observations occupy more space than the original task statement. This dilutes the model’s attention to the actual goal. The mitigation is to instruct the model to restate the task in its own words after every third Observation — an inexpensive way to re-anchor it on the objective.

When ReAct Is the Wrong Tool

ReAct is not a default pattern. It adds latency — each tool call is a round trip that takes one to three seconds, and a full session often involves three or more calls. For a task that a single direct prompt can answer reliably, the extra loop is wasted time and tokens.

The pattern earns its cost when the task has at least one of these characteristics: multiple independent facts that must be checked, a probability of outdated information, or a need for the model to justify its answer via evidence it can cite. A question about a library’s API signature from last month, a claim about a recent acquisition, a requirement to compare two different product specifications — these are ReAct-shaped problems. A request for a summary of what you already know is not.

There is also a scale consideration. ReAct works well when the tool surface is small — one or two functions. If your system has ten tools, the model spends as much time deciding which tool to call as it does reasoning, and error rates climb. In that case, a more structured router pattern is a better fit.

A Quick Checklist for Building Your Own ReAct Prompt

The case study above contains the full pattern. When you build your own, this is the minimal checklist to run through before you send the prompt:

Each element maps to a specific failure mode. Missing the tool spec leads to malformed calls. Missing the termination condition leads to early answers or infinite loops. The fallback line matters because tool APIs fail in production, and a model without instructions for that case will stall.

The Net Effect: A Model That Verifies Instead of Guessing

The shift ReAct produces is visible in the difference between the first and third search above. The first search was necessary — the model had no way to know Microsoft acquired Activision Blizzard without asking. The third search was epistemic hygiene — the model checked its own assumption. That is not something a single-prompt system does, and it is the reason ReAct is worth the added latency for high-stakes questions.

The pattern generalizes beyond search. You can pair a reasoning trace with any external function: a calculator for arithmetic, a SQL query for structured data, a code interpreter for executing snippets. The reasoning loop stays the same — the model thinks, calls, reads, and revises until it can commit to an answer with evidence in hand.