Think, Then Do: Why ReAct Turned LLMs into Real Agents

A chatbot answers. An agent checks.

That distinction sounds small until a workflow fails at 2:17 p.m. because the model confidently invented a policy clause, skipped the database lookup, and then explained itself with the serene authority of a consultant who has already left the building.

The 2022 paper ReAct: Synergizing Reasoning and Acting in Language Models matters because it made that failure mode harder to ignore.¹ It did not simply ask language models to “think step by step.” Chain-of-thought prompting already did that. It did not simply attach a search box to a model. Retrieval-augmented systems were already moving in that direction. The paper’s real contribution was more architectural: it showed that a language model could alternate between reasoning, acting, observing, and revising its next move.

That loop is the primitive form of the modern LLM agent:

Thought → Action → Observation → Updated Thought → Next Action

Elegant? Yes. Magical? No. Useful? Very much, provided nobody mistakes it for a fully autonomous employee with a browser and a corporate credit card. We are not there, and frankly, HR should be relieved.

ReAct is not “chain-of-thought plus search”

The easiest misunderstanding is to treat ReAct as a slightly upgraded chain-of-thought prompt. That misses the point.

Chain-of-thought makes the model write intermediate reasoning before answering. This can help because the model has more room to decompose the problem. But the reasoning remains trapped inside the model’s own parametric memory. If the model remembers a wrong fact, it may reason beautifully toward a wrong answer. A hallucination with better formatting is still a hallucination. It just wears a tie.

ReAct changes the unit of work. Instead of producing only a reasoning trace and then an answer, the model produces reasoning traces and task-specific actions in an interleaved trajectory. In the paper’s knowledge tasks, actions include operations such as Search[...], Lookup[...], and Finish[...]. In decision environments, actions are environment steps such as opening a drawer, navigating a web page, selecting an option, or buying a simulated product.

The mechanism is simple:

The paper’s conceptual move is to add language itself to the action space. A “thought” does not change the external environment, but it changes the context from which the next action is selected. In other words, reasoning becomes an internal action, while search, lookup, navigation, and selection become external actions. The agent can now reason to act and act to reason.

That is the mechanism businesses should care about. Not because every workflow needs visible model thoughts — many production systems should hide, summarize, or supervise them — but because the loop creates a design pattern: let the model expose a plan, call bounded tools, inspect returned evidence, and continue.

The paper tests two different problems, not one benchmark parade

The paper evaluates ReAct across four domains: HotpotQA, FEVER, ALFWorld, and WebShop. These are not interchangeable scoreboards. They test two different kinds of work.

HotpotQA and FEVER are knowledge-intensive reasoning tasks. The model must answer questions or verify claims, and the paper gives it access to a deliberately simple Wikipedia API. That API is weaker than modern retrieval systems: it can search an entity, look up a string, or finish with an answer. This constraint is important. The point is not that the retriever is powerful. The point is that the model has to use reasoning to decide what to retrieve.

ALFWorld and WebShop are interactive decision-making tasks. Here the model must act over multiple steps. In ALFWorld, it navigates a text-based household environment. In WebShop, it searches a simulated shopping website built from real product text and user instructions. These environments test whether reasoning helps the model plan, track subgoals, and recover from noisy observations.

A useful way to read the evidence is this:

This matters because ReAct is often remembered as “the agent paper.” That is fair, but incomplete. The paper’s deeper result is about when reasoning and tool use help each other, and when they interfere.

On knowledge tasks, ReAct improves grounding but not every score

The paper’s HotpotQA and FEVER results are more nuanced than the usual victory-lap summary.

On PaLM-540B prompting, the reported results are:

The first uncomfortable detail: ReAct alone does not beat CoT on HotpotQA. It scores 27.4 exact match versus CoT’s 29.4. This is not a scandal. It is the paper being more interesting than the slogan.

ReAct is better than Act-only on both HotpotQA and FEVER, which shows that reasoning helps tool use. It also beats CoT on FEVER, where claims often hinge on precise factual verification. But on HotpotQA, CoT keeps a slight edge over ReAct as a standalone method, likely because CoT has more flexibility to formulate multi-hop reasoning without being constrained by alternating search and observation steps.

The best results come from combining ReAct with CoT self-consistency. On HotpotQA, ReAct → CoT-SC reaches 35.1 EM; on FEVER, CoT-SC → ReAct reaches 64.6 accuracy. The interpretation is not “ReAct replaces chain-of-thought.” The interpretation is more useful: internal knowledge and external evidence should be routed differently depending on confidence and task structure.

The authors use simple heuristics. If ReAct fails to answer within a step budget, back off to CoT-SC. If CoT-SC samples do not produce a confident majority, back off to ReAct. This is a primitive router. Primitive routers are often where good systems begin, before everyone gives them a Greek letter and a dashboard.

For business workflows, this is the lesson: do not build one agent mode and force everything through it. A policy assistant, compliance checker, or market-research agent should know when to answer from internal reasoning, when to retrieve, and when to escalate because the evidence path is weak.

The failure analysis is where the paper earns its keep

The most useful part of the paper is not the benchmark table. It is the failure-mode analysis.

The authors manually label HotpotQA trajectories from ReAct and CoT. Among successful examples, ReAct has fewer false positives from hallucinated reasoning or facts: 6% versus 14% for CoT. Among failures, hallucination accounts for 56% of CoT failures but 0% of ReAct failures in their labeled sample.

That sounds like a clean win until the next line. ReAct has its own problems. Its failures include reasoning errors at 47%, search result errors at 23%, and label ambiguity at 29%. The model sometimes repeats previous thoughts and actions, gets stuck in loops, or fails to recover when search results are unhelpful.

So the real trade-off is not “hallucination versus no hallucination.” It is:

CoT risk: fluent internal reasoning over false or stale facts.
ReAct risk: grounded but brittle interaction with imperfect retrieval and rigid trajectories.

This is precisely the trade-off that shows up in enterprise automation. A purely internal model may write a plausible answer that nobody can verify. A tool-using agent may retrieve the wrong document, query the wrong field, or enter a loop because one observation was empty. The second failure is not automatically better, but it is often more diagnosable. You can inspect which query failed. You can improve the retriever. You can add a fallback route. You can limit tool permissions.

A hallucinated narrative gives you less to repair. It smiles and walks away.

Why sparse reasoning beats action-only behavior

The interactive tasks make the mechanism easier to see.

In ALFWorld, an agent might need to find an object, clean it, heat it, cool it, examine it, or place it somewhere. The environment can have more than 50 locations, and successful behavior requires planning over many steps. Act-only prompting can issue commands, but it often loses track of the task. It may find the object, then fail to remember the next subgoal. Or it may try the same invalid action repeatedly, because apparently machines can also have bad afternoons.

ReAct adds sparse thoughts: decompose the goal, decide likely locations, track completion, and move to the next subgoal. That is enough to change behavior substantially. In ALFWorld, the best ReAct trial reaches 71% overall success, compared with 45% for the best Act-only trial and 37% for the BUTLER baseline. The paper also reports that the advantage over Act is consistent across six controlled trials.

WebShop gives a different version of the same story. The agent must satisfy user instructions across product titles, descriptions, options, and prices. Act-only prompting already performs competitively, with a 30.1% success rate. ReAct improves success to 40.0% and average score from 62.3 to 66.6. Human expert performance remains higher at 59.6% success and 82.1 score, so let us not order champagne for the robot intern.

What changed? ReAct helps the model bridge the gap between noisy observations and action selection. It can reason that a product option matches the instruction, that a missing attribute requires more exploration, or that a search query should be reformulated. In business terms, this is not “the agent understands shopping.” It is “reasoning gives the agent a scratchpad for state, constraints, and next-step selection.”

That pattern generalizes beyond shopping. Procurement search, vendor comparison, internal knowledge-base navigation, CRM updates, invoice triage, and compliance evidence gathering all involve messy observations and sequential decisions. ReAct does not solve those systems by itself, but it names the loop those systems need.

The Inner Monologue comparison explains what “thinking” is for

The paper’s comparison with Inner Monologue-style prompting is easy to skip, but it clarifies the mechanism.

ReAct-IM uses dense external-feedback thoughts. It tells the agent about the current goal and subgoal, but it lacks the broader reasoning types ReAct allows: deciding when a subgoal is complete, choosing the next subgoal, and using commonsense knowledge to infer likely object locations.

In ALFWorld, ReAct’s best overall success rate is 71%, while ReAct-IM’s best is 53%. This ablation is not merely a variant test. It asks what kind of language matters inside the loop.

The answer is: not all “thinking” is equal.

A useful reasoning trace is not a decorative monologue. It must do operational work. It should compress state, identify missing information, choose a next action, repair a failed search, or update the plan. Otherwise, it is just ambient narration — pleasant, maybe, but so is elevator music, and nobody builds a workflow around that.

For agent design, this suggests a practical rule: constrain reasoning traces by function, not by verbosity. A good agent does not need to narrate every token of its existence. It needs to record the reasoning that affects action.

Fine-tuning turns ReAct from a prompt format into a behavior pattern

The paper also explores fine-tuning smaller PaLM models on generated trajectories. This section should be read as an exploratory extension, not the main claim.

The authors bootstrap 3,000 correct trajectories and use them to fine-tune PaLM-8B and PaLM-62B models. In prompting mode, smaller models struggle with ReAct because they must learn both reasoning and acting from a few examples. But after fine-tuning, ReAct becomes the best method among Standard, CoT, Act, and ReAct for HotpotQA. The paper reports that PaLM-8B fine-tuned with ReAct outperforms all PaLM-62B prompting methods, and PaLM-62B fine-tuned with ReAct outperforms all PaLM-540B prompting methods.

The operational meaning is important. ReAct is not only a clever prompt template; it can become a trainable interaction style. The model can learn to produce trajectories that include thoughts, actions, and observations as a structured skill.

For companies building agents, this points to a gradual roadmap:

1. Start with prompted tool use in narrow workflows.
2. Collect successful trajectories.
3. Review and clean those trajectories.
4. Train or tune smaller specialized models to reproduce the useful behavior.
5. Keep routing, permissions, and monitoring outside the model.

That last point is where many agent demos quietly lose their dignity. The model should not be the whole control system. It should be one component inside a workflow architecture.

Inspectability is a business feature, not an academic ornament

ReAct’s visible traces are not just for interpretability theater. They make debugging easier.

The paper’s human-in-the-loop example shows that editing a small number of thoughts can change the subsequent behavior of an ALFWorld trajectory. This is exploratory, but it hints at a useful operational principle: if the model’s intermediate reasoning is inspectable, then a human can sometimes correct the plan without rewriting the entire action sequence or changing model parameters.

In production settings, this does not mean every user should see raw chain-of-thought. That would be both messy and, in many cases, unsafe or unnecessary. But systems can expose structured summaries: current goal, evidence used, tool calls made, unresolved uncertainty, and proposed next action.

For enterprise adoption, that matters more than poetic claims about autonomy. Managers do not only ask, “Can the agent complete the task?” They also ask:

This is the business value: cheaper diagnosis. Not just better answers. Not just shinier demos. Diagnosis is what turns a fragile agent into a maintainable system.

What Cognaptus would infer for business automation

The paper directly shows that interleaving reasoning and acting improves performance in several constrained benchmark settings, especially when external evidence or long-horizon decision making matters.

Cognaptus can infer a broader design pattern for business automation, but with boundaries.

First, use ReAct-style loops for tasks where the answer depends on external state. Examples include checking policy documents, searching vendor catalogs, reading CRM history, querying databases, comparing product requirements, and walking through procedural workflows. In these cases, the model’s memory is not enough. The agent must look.

Second, keep the tool space bounded. The paper’s tools are deliberately limited: Wikipedia search and lookup, ALFWorld actions, WebShop navigation. This is not a weakness; it is the reason the experiments are meaningful. In real businesses, agents should have narrow APIs, explicit permissions, and reversible actions wherever possible. “Here is full browser access and our ERP credentials” is not innovation. It is a compliance incident in larval form.

Third, separate the planner from the executor when stakes rise. A ReAct-style model can propose actions, but execution should often pass through validation rules, human approval, or deterministic checks. This is especially true for finance, procurement, legal, HR, and customer communication.

Fourth, log observations and action outcomes as first-class data. If an agent reads a document, queries a table, or calls an API, the system should store what happened. Otherwise, you have built a machine that can make mistakes at scale and then shrug.

Fifth, treat failure modes as design inputs. ReAct reduces some hallucination behavior, but it introduces or exposes other risks: search failure, tool misuse, loops, stale observations, and overcommitment to incomplete evidence. These are not reasons to abandon agents. They are reasons to engineer them.

The boundary: ReAct is a loop, not a license for autonomy

The paper is careful about risk. Its experiments avoid dangerous action spaces. The WebShop environment does not actually buy products. The Wikipedia interaction cannot edit pages. The action spaces are narrow and controlled.

That boundary is not a footnote. It is the condition under which ReAct is useful.

ReAct-style agents become more dangerous as the action space expands. A model that searches Wikipedia and answers a question is one thing. A model that emails customers, approves refunds, changes inventory, submits filings, or trades assets is another. The mechanism is similar; the governance burden is not.

There are also technical boundaries. ReAct may struggle when action spaces are large, when good demonstrations exceed context limits, when retrieval returns weak evidence, or when the model loops. The paper itself notes that complex tasks with large action spaces may require more demonstrations or fine-tuning. It also shows that ReAct remains far behind supervised state-of-the-art systems on HotpotQA and FEVER.

So the correct business reading is not “ReAct solved agents.” It is:

ReAct defined a practical control loop for language-model agents.
That loop improves grounding, planning, and diagnosability.
It still needs bounded tools, routing, monitoring, and escalation.

Less thrilling than “autonomous AI worker.” Much more likely to survive contact with operations.

The real legacy of ReAct

ReAct’s importance is not that it produced the highest number in every table. It did not. Its importance is that it made the agent loop legible.

Before ReAct, it was natural to think of LLMs as answer generators. After ReAct, it became easier to think of them as policy components inside interactive systems: observe, reason, act, observe again. That mental shift is why the paper still matters.

For Cognaptus readers, the practical takeaway is straightforward. When building AI automation, do not ask only whether the model can answer. Ask whether it can check, act, observe, and revise under constraints. Ask whether its failures are visible enough to repair. Ask whether the workflow separates model reasoning from tool execution. Ask whether the system knows when not to act.

The future of agents will not be built by giving chatbots more motivational slogans. It will be built by giving them narrower tools, better feedback loops, clearer state, and fewer opportunities to improvise in places where improvisation is just negligence with a GPU.

Cognaptus: Automate the Present, Incubate the Future.