ReAct's contribution, going back to the original research, was simple but influential: instead of a model either reasoning silently or just calling tools blindly, make it explicitly interleave "thought" (reasoning about what to do) with "action" (calling a tool) and "observation" (the tool's result) — a pattern that turned out to produce more reliable, more debuggable agent behavior than either pure reasoning or pure reactive tool-calling alone.
The ReAct pattern (Reason + Act) structures an agent's loop as an explicit cycle: the model reasons about the current situation, decides on an action (typically a tool call), observes the result, and reasons again based on that observation — repeating until the task is complete. This differs from a bare tool-calling loop by making the model's reasoning explicit and visible at each step, not just its actions.
Why the ReAct Pattern Matters (and When It's More Structure Than You Need)
ReAct's explicit reasoning step matters for tasks where the right action genuinely depends on reasoning about accumulated observations — multi-step research, debugging, or any task where jumping straight to an action without reflection risks a locally plausible but ultimately wrong choice. The visible reasoning trace also makes debugging agent behavior substantially easier, since you can see why a specific action was chosen, not just what it was.
It's more structure than needed for simple, single-step tool use where reasoning about the situation adds little — a straightforward lookup task doesn't benefit from an explicit "thought" step before an obvious action, and forcing the pattern there just adds latency and token cost without improving reliability.
Getting Started with the ReAct Pattern
A basic ReAct loop, prompting the model to produce explicit thought/action/observation cycles:
const systemPrompt = `You solve tasks by reasoning step by step. For each step, output:
Thought: <your reasoning about the current situation>
Action: <the tool to call and its arguments>
(You'll then receive an Observation with the tool's result, and continue.)
When you have the final answer, output:
Thought: <final reasoning>
Final Answer: <the answer>`;
async function reactLoop(task: string) {
const messages = [{ role: "system", content: systemPrompt }, { role: "user", content: task }];
while (true) {
const response = await model.generate({ messages });
messages.push({ role: "assistant", content: response.text });
if (response.text.includes("Final Answer:")) {
return extractFinalAnswer(response.text);
}
const action = parseAction(response.text);
const observation = await executeTool(action);
messages.push({ role: "user", content: `Observation: ${JSON.stringify(observation)}` });
}
}
Most modern tool-calling APIs (native function calling) handle the action/observation exchange structurally rather than through parsed text, but the underlying reason-act-observe cycle is the same pattern.
Core ReAct Concepts Every Developer Should Know
The explicit reasoning step ("Thought") makes the model's decision process visible, which is valuable both for debugging (you can see why an action was chosen, not just infer it from the action alone) and, per the original research, for improving the quality of the actions themselves — reasoning explicitly before acting tends to produce better-chosen actions than acting without an explicit intermediate reasoning step.
Modern tool-calling APIs largely implement the ReAct cycle structurally rather than requiring the parsed-text format from the original pattern — a model's native function-calling capability, combined with the model naturally reasoning before selecting a tool call (especially with extended thinking or reasoning-focused models), achieves a similar effect without needing to hand-parse "Thought:"/"Action:" text.
Observations need to be fed back into context accurately and completely, since the next reasoning step depends entirely on the model correctly understanding what the previous action's result actually was — truncated or poorly formatted observations degrade the whole cycle's effectiveness, since subsequent reasoning is only as good as the information it's reasoning over.
The cycle needs a termination condition, the same requirement as any agentic loop — a "Final Answer" signal, an iteration limit, or a task-specific success check, since an open-ended reason-act-observe cycle needs an explicit way to stop.
Common Mistakes With the ReAct Pattern and How to Fix Them
Mistake 1: forcing explicit reasoning steps for simple, single-action tasks where reasoning adds latency and cost without improving reliability. Fix: reserve the full ReAct cycle for tasks that genuinely benefit from multi-step reasoning; skip it for straightforward lookups or single-tool tasks.
Mistake 2: truncating or poorly formatting observations fed back to the model, degrading the quality of subsequent reasoning steps. Fix: ensure tool results are fed back completely and in a format the model can reliably parse and reason over.
Mistake 3: no explicit termination condition, risking a reasoning loop that continues indefinitely without converging on a final answer. Fix: define a clear termination signal and a maximum iteration count as a safety bound.
When Should You Use the Explicit ReAct Cycle Instead of a Bare Tool-Calling Loop?
Use the explicit ReAct pattern for multi-step tasks where visible, step-by-step reasoning improves both action quality and debuggability — research tasks, debugging, or any task where jumping straight to tool calls risks poorly-reasoned actions. Use a bare tool-calling loop for simpler tasks where a model's native reasoning (implicit or via a reasoning-focused model) already produces good tool selection without needing an explicit, verbose thought/action/observation format.
The ReAct Pattern in Production
Reserve the full explicit-reasoning cycle for tasks that genuinely benefit from it, since forcing it universally adds latency and cost for simple cases. Feed tool observations back to the model completely and accurately, since reasoning quality is bounded by the accuracy of what it's reasoning over, and always define an explicit termination condition for any reason-act-observe loop.
If you're building an agent with tool use and finding its action choices are locally plausible but not well-reasoned, adding an explicit reasoning step before each action (whether via the classic ReAct text format or a native reasoning-capable model) is a concrete, well-tested way to improve both action quality and debuggability.