ReAct & Reasoning Loops
Moving from answering questions about refunds to actually processing them — the Thinking-Acting-Observing loop that makes a model's tool use reliable.
From Answering to Doing
Every phase so far made the refund bot better at telling customers about the policy — grounded, well-retrieved, architecturally sound. Now the team wants something different: a customer types "please refund my order," and the bot actually processes it. That means looking up the order, checking whether it's within the return window, calculating the refund amount, calling the payment API to issue it, and confirming — and, critically, not calling the payment API at all if the order turns out to be ineligible. A single function call from Phase 2 isn't enough here; this is a sequence where each step's result changes what should happen next.
Thought, Action, Observation
ReAct: Synergizing Reasoning and Acting in Language Models (Yao et al., 2022) formalized the pattern that makes this reliable: interleave explicit reasoning ("Thought") with tool calls ("Action") and their results ("Observation"), looping until the model decides it has enough to give a final answer. Earlier approaches tended to pick one or the other — reason through a problem in text with no way to act on the world, or act via tool calls with no visible reasoning connecting one call to the next. ReAct's contribution was showing that interleaving both, explicitly, produces more reliable multi-step behavior than either alone — the reasoning step gives the model a place to decide what to do with an observation before committing to the next action.
Notice what the explicit Thought steps are doing in this trace: they're the difference between an agent that reflexively calls issue_refund because a customer asked for one, and an agent that reasons its way to not calling it, because the observation from the eligibility check ruled it out. That's not a capability Phase 2's function calling provides on its own — a single-shot tool call has no structural place for "here's what I learned, and here's why it changes my next step." The loop is what supplies that place.
Why the Loop Needs an Explicit Stop Condition
A ReAct loop doesn't run forever — the model itself decides, after each Observation, whether it has enough information to produce a final answer or needs another Thought-Action-Observation cycle. This is exactly the adaptive retrieval pattern from Agentic RAG in the last phase, generalized from "decide whether to retrieve again" to "decide whether to act again, with any tool." In practice this means every agent loop needs a hard iteration cap regardless of what the model decides — a bug in reasoning, a tool that returns confusing results, or a genuinely ambiguous task can otherwise keep the loop cycling well past the point of being useful, quietly burning tokens and latency the whole time.
An unbounded ReAct loop is a real production risk, not a theoretical one: a model stuck reasoning in circles about an edge case will keep calling tools and generating Thoughts until something external stops it. Always cap iterations explicitly, and treat "hit the cap without resolving" as a distinct failure mode to surface, not a silent timeout.
Check yourself
Why does the ReAct pattern's explicit 'Thought' step matter for the refund agent, beyond just having access to tools via function calling?
What's Next
A hand-rolled ReAct loop — a while-loop calling the model, parsing its requested action, executing it, feeding the result back — works fine for a task this size. It starts to strain once the workflow needs persisted state across steps, conditional branching, or a pause for human approval on a large refund. That's what dedicated agent frameworks exist to handle.
Frequently asked questions
Is ReAct a specific library or API feature I need to install?
No — it's a prompting and orchestration pattern, not a product. You can implement it with a plain loop around any model's function-calling API, which is exactly what makes it a useful mental model even before you reach for a framework. The next guide covers frameworks that implement this pattern (and more) for you.
Does every agent task need a full ReAct loop, or is a single tool call sometimes enough?
A single tool call is fine, and simpler, whenever the task genuinely resolves in one step — Phase 2's structured function calling already covers that case well. ReAct earns its complexity specifically for tasks where what to do next depends on what an earlier step returned, like the refund eligibility check here.
How is a reasoning model's built-in 'thinking' (from Phase 1) different from ReAct's explicit Thought steps?
They're related but not identical. A reasoning model's internal thinking happens within a single turn, before producing output — it doesn't inherently interleave with external tool calls and their results across multiple turns. ReAct is specifically about structuring reasoning around actions taken in the world and their observed outcomes, which is a multi-turn, tool-interleaved pattern regardless of whether the underlying model also does internal reasoning within each turn.