ReAct: Reasoning + Acting (Prompt Pattern)

Chain-of-thought and self-consistency made the model think better — but it's still thinking entirely in its own head, reasoning against its own (sometimes wrong, sometimes outdated) memory. ReAct adds the missing half: acting.

ReAct — Reasoning + Acting — lets the model think and do: reason about what it needs, take an action in the real world (search the web, run a calculation, call an API, query a database), observe the actual result, and then reason again with that real information in hand. It loops until it has what it needs to answer.

This is one of the most important patterns in all of AI engineering, because it's the blueprint behind virtually every AI agent. Understand ReAct and you understand how agents actually work under the hood.

You'll learn:

• Why pure reasoning hits a wall (and hallucinates)
• The Thought → Action → Observation loop
• A worked example of ReAct in action
• Why grounding in real observations beats reasoning alone
• How ReAct became function calling and the foundation of agents

Chain-of-thought is a closed loop: the model reasons step by step, but every step draws only on what's already in its weights. That's fine when it genuinely knows the answer — and a disaster when it doesn't.

Recall the hallucination lesson: a model will fluently and confidently reason its way into a wrong answer when it lacks the facts, because it has no way to check anything. Ask 'what's our Q3 revenue?' or 'what's the weather in Tokyo right now?' and pure reasoning can only make something up — it can't look it up. And recall that CoT's reasoning can even be unfaithful (a post-hoc story).

The fix isn't better reasoning — it's giving the model a way to go get real information mid-thought. That's acting.

ReAct structures the model's work as a loop of three repeating moves:

• Thought — free-text reasoning about what to do next (CoT-style planning).
• Action — a concrete step using a tool: search(...), calculate(...), get_weather(...), an API or database call.
• Observation — the real result the tool returns, fed back into the prompt.

The model then reasons again with that observation, takes the next action, observes, and so on — looping until it has enough to give a Final Answer. Crucially, the Observation is ground truth from the outside world, not something the model imagined. Here's the loop with a real trace:

Walk the example end to end — 'How many years after the Eiffel Tower opened was the first iPhone released?':

Thought:     I need two facts: the Eiffel Tower's opening year and
             the iPhone's release year.
Action:      search("Eiffel Tower opened")
Observation: 1889
Thought:     Got 1889. Now the iPhone's release year.
Action:      search("first iPhone released")
Observation: 2007
Thought:     Now compute 2007 − 1889.
Action:      calculate("2007 - 1889")
Observation: 118
Thought:     I have the answer.
Final Answer: 118 years.

Notice the rhythm: every claim is backed by an Observation the model actually fetched, not recalled. The model didn't guess 1889 or do mental math — it looked them up and used a calculator. That's the whole point.

Here's the core insight. Pure CoT is closed — the model reasons against itself, so errors compound invisibly. ReAct opens the loop by inserting a reality check (the Observation) between every reasoning step. Each fact is grounded by an external source before the next thought builds on it, so the model can't silently confabulate — to use a fact, it has to actually go get it.

And reasoning and acting are synergistic, not just stacked:

• Reasoning makes acting smart — the Thought decides which tool to call and why, instead of flailing.
• Acting makes reasoning true — the Observation injects real-world facts, so the reasoning is anchored to reality, not memory.

Reasoning-only hallucinates; acting-only (no planning) is blind. ReAct's power is the interplay — which is exactly why it dramatically reduces hallucination on knowledge-heavy tasks.

The original ReAct was literal text: the model wrote Action: search["..."], and your code parsed that string, ran the tool, and pasted back Observation: .... It worked, but parsing free text is brittle.

Modern APIs do the same thing natively via function calling / tool use: you declare your tools to the model; instead of writing 'Action:' text, the model returns a structured tool call (a clean JSON object naming the tool and arguments); your code runs it and returns the result; the loop continues. Same Thought → Action → Observation pattern, just with reliable structured calls instead of regex-parsed text.

So when you later build with function calling and agent frameworks, remember: underneath, it's ReAct. The mechanics got cleaner; the loop is unchanged. (Tool use and agents get their own deep treatment later — this is the conceptual seed.)

Why does this pattern matter so much? Because nearly every AI agent is a ReAct loop. An 'agent' is, at its core, a model that repeatedly thinks, acts (uses tools), and observes — adapting until the task is done. That's ReAct, run autonomously over many steps.

Two properties make it the foundation:

• Adaptivity. Because each step reacts to a real observation, the agent can course-correct — retry a failed search, change approach, dig deeper — instead of following a rigid script.
• Transparency. The Thought trace is an explicit, auditable log of why the agent did each thing — invaluable for debugging and trust (and a welcome contrast to a black-box answer).

When you reach the agents container later, you'll see planning, memory, and multi-tool orchestration layered on top — but the beating heart is always this Thought → Action → Observation loop.

Use ReAct when the task needs the outside world:

• Current / private info the model can't know (today's data, your database, live prices).
• Exact computation (use a calculator/code tool — don't trust mental math).
• Multi-step lookups that combine several fetched facts.
• Anything where grounding matters more than raw fluency.

Skip it for self-contained tasks (creative writing, summarizing text you already provided) — the tool round-trips add nothing.

Mind the costs: each loop is another model call (latency + tokens add up — Iron Triangle), agents can get stuck or loop, and ReAct is only as good as its tools (a flaky search yields flaky answers). It's powerful, but it's heavier than a single prompt — reach for it when grounding or actions are genuinely required.

ReAct is a loop — best understood by walking it. Step through the trace below one move at a time. Watch the rhythm: a Thought decides what to do, an Action calls a tool, and an Observation feeds a real result back before the next Thought. Notice every fact (1889, 2007, 118) is fetched, never guessed — that's the grounding that stops it hallucinating.

• "ReAct just makes the model reason more." No — it adds acting: real tool calls whose observations ground the reasoning in reality.
• "Reasoning alone can answer anything." No — on facts it lacks, pure CoT hallucinates; ReAct makes it fetch the fact instead.
• "ReAct is outdated; we have function calling now." Function calling is ReAct with structured tool calls — same loop, cleaner mechanics.
• "Agents are something totally different." An agent is essentially a ReAct loop run autonomously with tools, memory, and planning on top.
• "Use ReAct for everything." No — it's for tasks needing external info/actions; it's wasteful (extra calls) on self-contained ones.

• ReAct = Reasoning + Acting: a loop of Thought → Action → Observation, repeating until a Final Answer.
• It fixes pure CoT's closed-loop hallucination by inserting real observations between reasoning steps — every fact is grounded before the next thought uses it.
• Reasoning and acting are synergistic: thoughts choose the right action; actions anchor the thoughts in reality.
• The pattern lives on as function calling / tool use (structured calls instead of parsed text) — and it's the blueprint for nearly every AI agent (adaptive + auditable).
• Use it when the task needs the outside world (current data, exact math, lookups); skip it for self-contained tasks, and mind the extra latency/cost per loop.

Next: when a task is too big for one prompt — even with reasoning and tools — we break it into stages: prompt chaining and task decomposition.