The ReAct Loop: Reason Plus Act Explained

Picture this: you're a backend engineer at a logistics startup, and you've been handed a "smart" shipment-status agent that keeps confidently reporting the wrong delivery dates. It has tools. It calls them. It still lies. When you open the transcript you find the problem — the agent acts before it reasons, so every tool call is a guess dressed as a decision. That's the exact gap the ReAct agent loop was built to close, and fixing this agent is a clean way to see why.

ReAct means Reason + Act. Instead of jumping straight to a tool call, the model writes a short reasoning line first — a Thought — then the Action, then reads the Observation, and only then decides the next Thought. The reasoning is not decoration. It's the model committing to why before what, and that single reorder fixes a startling number of bad agents.

Before: The Weak Prompt

Here's the shipment agent's original instruction, near enough to reproduce the bug:

You are a shipment assistant. You have tools: track(id), eta(id).
When the user asks about an order, call the right tool and answer.

What this does: tells the model to call a tool and answer — with no requirement to reason first, so the model pattern-matches "order question" straight to a tool call and often the wrong one.

Run it on "Where's order 4471 and will it arrive before Friday?" and the agent calls

track(4471)

eta

Why It Fails

The weak prompt collapses two decisions into one. "Which tool?" and "why that tool?" happen in the same instant, invisibly, so when the model guesses wrong there's no reasoning trace to catch it — and, more importantly, no reasoning step to prevent it.

Models are markedly better at choosing tools when they narrate the choice first. It's the same reason chain-of-thought lifts math accuracy: writing the reason changes the token distribution the next decision samples from. Skip the Thought and you're asking the model to pick correctly on reflex. Sometimes it does. On any question with two plausible tools, it often doesn't.

There's a subtler failure too. Without a visible Thought, you can't debug it. A wrong answer gives you nothing to inspect — just output. A wrong Thought hands you the exact false belief that caused it.

How much does the reasoning line actually help? In my own before/after tests on tool-selection tasks with two plausible tools, adding a mandatory Thought moved correct-tool-choice from roughly two-in-three to nearly always. I'm not 100% sure why the effect is that large for such a small change, but the pattern held across every agent I tried it on: the model that says why picks better than the model that just picks.

⚡ Pro tip: If your agent picks the wrong tool more than occasionally, don't reach for a bigger model first. Add a mandatory reasoning line. It's cheaper, faster to test, and fixes the specific failure — wrong tool selection — better than raw capability does.

After: The Improved Prompt

You are a shipment assistant. Tools: track(id), eta(id).
Work in this loop, one block at a time:

Thought: reason about what the user needs and which tool answers it.
Action: the single tool call to make now.
Observation: (the system fills this in)
... repeat Thought/Action/Observation until you can answer ...
Answer: the final response, grounded only in observations.

Rules: never answer a date question without an eta observation.
Never answer from a Thought alone — only from Observations.

What this does: forces a reasoning line before every action, names the loop explicitly, and adds two grounding rules so the model can't answer a date question from location data or invent facts it never observed.

Now the same question produces: Thought: they asked location and arrival date — that's two facts, needing track and eta. Action:

track(4471)

eta(4471)

Notice what changed and what didn't. Same model, same tools, same question. The only difference is that the agent now names the shape of the problem — two facts, two tools — before it touches anything. That naming step is cheap, a sentence of tokens, and it's the entire fix. The logistics team shipped it the same afternoon and the wrong-date complaints stopped.

Breaking Down Each Element

Four parts, each pulling weight.

Thought is where the model plans and where you debug. Action is deliberately singular — one call per turn keeps observations aligned to decisions. Observation is injected by your loop, never written by the model; the instant the model starts writing its own observations, it's hallucinating tool output. And Answer is a distinct token that ends the loop cleanly, so you're not guessing whether a prose reply meant "done" or "thinking out loud."

The grounding rule — answer only from observations — is the piece most ReAct tutorials omit. Without it, a model will happily write a confident Thought, skip the tool, and treat its own guess as fact. The rule turns the reasoning trace from a suggestion into a constraint.

One more thing the four-part shape buys you: replayability. Because a ReAct agent loop records Thought, Action, and Observation as discrete, ordered blocks, you can replay any run turn by turn and read the model's belief at each step. Compare that to a bare tool-calling agent, where a wrong answer is a black box. The structure that makes ReAct slightly more verbose is the same structure that makes it debuggable — and on a real project, debuggability is worth more than the tokens the Thought lines cost.

⚠️ Common mistake: Letting the model generate the Observation line itself. If your parser doesn't stop generation right after the Action and hand control to your code, the model will cheerfully write

Observation: package delivered

⚡ Pro tip: Use a stop sequence on the token

Observation:

Variations for Different Contexts

The Thought/Action/Observation shape flexes across roles.

A compliance analyst running document checks keeps Thought verbose — the reasoning trace is the audit artifact, so longer is better. A mobile developer wiring an on-device assistant trims Thought to one terse line to save tokens and latency, since users feel every millisecond. A growth marketer building a campaign-analysis agent adds a

Reflection

After every 3rd Observation, insert:
Reflection: Am I still answering the original question? If not,
what did I drift toward, and what Thought gets me back on track?

What this does: injects a periodic self-check into the ReAct agent loop so long chains catch their own drift, instead of confidently wandering for ten more turns before anyone notices.

A customer-success manager using an agent to draft renewal emails keeps the full Thought visible in an internal preview, so a human can sanity-check the reasoning before the email sends — the Thought becomes a review surface, not just a model aid.

Same loop, four tunings. Verbose for audit, terse for speed, reflective for long chains, reviewable for anything a human signs off on.

⚡ Pro tip: Number your Thought/Action/Observation triples in the transcript. When you're comparing two runs of the same ReAct agent loop to find why one worked and one didn't, aligned step numbers turn a painful diff into a glance.

⚡ Pro tip: For latency-sensitive agents, cap the Thought at roughly one sentence in the prompt ("Thought: one line, no more"). You keep the accuracy win from reasoning-before-acting while shedding the token cost of a paragraph the user never sees.

Save and Reuse This

The improved prompt above is a template, not a one-off. The Thought/Action/Observation/Answer scaffold plus the two grounding rules works for nearly any tool-using agent — swap the tools and the domain rules and you're done. Concretely: I've dropped this same scaffold into a refund agent, a code-review agent, and a calendar agent with only the tool list and the two grounding rules changed. The bones didn't move. That reuse is the actual win. The teardown took real effort; you shouldn't have to redo it every project.

I keep the ReAct scaffold as a saved, versioned prompt in PromptABCD, with the grounding rules and the stop-sequence note attached, so every new agent starts from the version that already survived a production bug instead of a blank editor and a hopeful guess.