ReAct, short for Reason and Act, is a prompting pattern where a language model alternates between explicit reasoning steps and tool-calling actions, observing each tool's result before deciding the next step, rather than producing a final answer in one pass. In a ReAct loop, the model writes a thought explaining what it needs to do next, issues an action such as a search query or an API call, receives an observation with the result, and repeats this thought-action-observation cycle until it has enough information to answer or complete the task. This pattern improved early agent reliability significantly over single-shot prompting because it forces the model to ground its next action in real tool output rather than hallucinating a plan upfront, and it makes the agent's reasoning visible for debugging. Most modern agent frameworks, including LangGraph and the native tool-calling loops in the Claude Agent SDK, implement a refined version of ReAct under the hood, often with structured function calling replacing the original free-text action format for reliability. ReAct works best for tasks with a moderate number of steps; very long-horizon tasks usually need an added planning layer on top. Nanobase AI uses ReAct-style loops as the default execution pattern in the agents it builds, tuned per client workflow.
A trace makes the pattern concrete
ReAct, short for Reason and Act, is easiest to understand as a trace rather than a definition. Consider an agent asked to check whether a customer's shipment is delayed and draft an update if so. A ReAct-style trace looks like this: the model reasons that it first needs the order status, calls a lookup tool, observes that the order shows "in transit, no scan in 48 hours," reasons that this qualifies as a likely delay, calls a second tool to check the carrier's service alerts for that route, observes an active weather delay notice, and only then reasons that it has enough information to draft the customer update. Each action is grounded in the actual result of the previous one, rather than a plan the model committed to before seeing any real data.
Why grounding each step improved on single-shot prompting
Before this pattern became standard, agents were often prompted to produce an entire plan upfront and then execute it, which failed whenever an early assumption turned out to be wrong, since nothing in that structure let the model revise course mid-task. ReAct's step-by-step grounding means a surprising tool result, such as discovering the order was already delivered rather than delayed, changes what the model does next immediately, rather than the model blindly continuing a stale plan. This also makes the agent's reasoning visible for debugging, since each thought is written out alongside the action it led to, turning a black-box decision into an inspectable trace.
Where ReAct starts to strain
Plain ReAct is reliable within a moderate step count and starts losing coherence once a task's context grows large enough to dilute the model's focus on the original goal.
| Task shape | ReAct's behavior | Better fit |
|---|---|---|
| Moderate steps (2-10 tool calls) | Reliable, grounded, easy to debug | ReAct as-is |
| Long-horizon tasks (dozens of steps) | Loses coherence across a growing context, drifts from the original goal | Plan-and-execute with periodic re-planning |
| Tasks needing an upfront cost or step estimate | No visibility into total steps until the loop finishes | Explicit planning step before execution begins |
| Highly parallel sub-tasks | Executes steps sequentially by default | Orchestrator-worker pattern with parallel workers |
Plan-and-execute as the common extension
For longer-horizon tasks, most production systems layer an explicit planning step on top of the ReAct loop rather than abandoning it entirely. The model first produces a rough plan, a small number of high-level steps toward the goal, and then executes each step using a ReAct-style reason-act-observe loop internally, re-planning at defined checkpoints if the observations so far contradict the original plan. This combination, sometimes called plan-and-execute, keeps the grounding benefit of ReAct at the step level while adding the coherence that pure ReAct loses on tasks long enough for the model's original reasoning to drift out of effective context.
Where structured function calling replaced free-text ReAct
The original ReAct pattern used free-text "Thought / Action / Observation" formatting, which required the system to parse the model's action out of prose, an approach prone to formatting errors and ambiguity. Modern agent frameworks and SDKs implement the same underlying reason-act-observe cycle using structured function calling instead, where the model returns a schema-validated tool call rather than free text to parse, which meaningfully reduces the parsing failures that plagued early ReAct implementations. The reasoning behind ReAct survived; the free-text implementation mostly did not.
Frequently asked questions
Is ReAct a framework or a prompting technique?
It originated as a prompting technique, a specific way of structuring the model's output to alternate reasoning and action. Today it describes an execution pattern that most agent frameworks implement under the hood using structured tool calling rather than the original free-text format, so it is more accurate to call it a pattern than a specific tool.
How many steps is "too many" for plain ReAct?
There is no fixed number, but tasks that regularly exceed roughly ten to fifteen sequential tool calls tend to benefit from an added planning layer, since that is typically where context accumulation starts to dilute the model's focus on the original goal. The right threshold depends on the model's context handling and the task's complexity.
Does ReAct handle errors well on its own?
It handles errors better than a fixed upfront plan, since a failed tool call becomes an observation the model can reason about and route around. It does not guarantee good error recovery by itself; that still requires the tool to return a clear, structured error rather than a raw exception the model cannot interpret.
Can ReAct and parallel tool calls coexist?
Yes, many implementations let the model issue several independent tool calls at once within a single reasoning step when the calls do not depend on each other's results, then observe all their outcomes together before the next reasoning step, which reduces total latency without abandoning the grounded, step-by-step structure.
How Nanobase AI helps
Nanobase AI uses ReAct-style loops as the default execution pattern in the agents it builds, extending to a plan-and-execute structure specifically for the longer-horizon workflows where pure ReAct starts to drift. This choice of execution pattern is one part of the broader agent orchestration layer Nanobase AI designs around a client's actual task shape, alongside guidance on how many tools a single agent can reliably handle.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.