ReAct: Reasoning and Acting in an Interleaved Loop

ReAct is the default mental model for a tool-using agent: the model reasons about the current state, chooses an action, observes the result, and repeats. The name fuses Reasoning and Acting into one interleaved loop rather than a single plan followed by blind execution.

If you have built "chat with function calling," you have touched ReAct. This page makes the control structure explicit so you can bound it, observe it, and know when a different architecture is better.

Summary

• ReAct interleaves short reasoning traces with tool actions and observations until a stop condition says the goal is done or the run must fail closed.
• Insight: Interleaving lets the agent adapt after every tool result, which matches real environments where the next step depends on what the last API or search returned.
• Key Concepts: thought, action, observation, trajectory, max turns, tool allowlist.
• When to Use: Exploratory research, multi-hop lookups, debugging workflows, and any task where the tool path is not known up front.
• Limitations/Trade-offs: Context grows with every turn; unproductive loops are common; pure ReAct can waste tokens on tasks that wanted a fixed checklist.
• Related Topics: agent loops, plan-and-execute, stopping conditions, context discipline.

Foundations

ReAct comes from the idea that language models solve some tasks better when they verbalize intermediate reasoning and ground that reasoning in external actions, not only in latent next-token prediction. In agent systems, that insight becomes a runtime loop rather than a paper prompt format.

A single ReAct iteration has three conceptual slots:

1. Thought - a short decision about what is true now and what to do next.
2. Action - a structured tool call (name + arguments) or a final answer action.
3. Observation - the tool's return value, error, or empty result, written back into context.

The trajectory is the sequence of those triples across turns. The next thought is conditioned on the full trajectory (or a summarized form of it), which is why context management is inseparable from ReAct quality.

Analogy: a mechanic does not write a 40-step plan for every unknown noise. They listen, try one test, observe, then choose the next test. ReAct is that diagnostic style applied to LLM tool use.

goal
  -> Thought_1 -> Action_1 -> Observation_1
  -> Thought_2 -> Action_2 -> Observation_2
  -> ...
  -> Thought_n -> FinalAnswer

Mechanics & Interactions

At runtime, a ReAct host typically:

1. Builds a prompt from system instructions, tool schemas, user goal, and trajectory so far.
2. Calls the model with tool-calling enabled.
3. If the model returns tool calls, executes them and appends observations.
4. If the model returns a final message (or a done tool), exits.
5. Otherwise continues until max turns, timeout, or budget.

Modern providers often implement "Thought" as either explicit chain-of-thought text, hidden reasoning tokens, or simply the model's pre-tool decision inside a function-call response. The architecture is still ReAct if control is interleaved with observations, even when the paper-style Thought: string is not printed.

Why interleaving works: tools reduce hallucination on facts that live outside the model weights, and each observation updates the evidence the next decision uses. Without observation feedback, multi-hop work collapses into one-shot guessing.

Why interleaving fails: the model can re-call the same tool with near-identical args, chase a dead path, or fill the window with huge JSON blobs. Those are architecture and host problems as much as model problems.

Practical host rules that make ReAct production-grade:

• Cap max turns and wall-clock time.
• Deduplicate or rate-limit repeated tool signatures.
• Truncate or summarize large observations before the next model call.
• Define a clear final-answer path separate from tool calls.
• Log thought summaries, actions, observations, and stop reason per turn.

# Conceptual host loop (not a framework API)
for turn in range(max_turns):
    out = llm(messages, tools)
    if out.final:
        break
    for call in out.tool_calls:
        messages.append(run_tool(call))  # observation

Advanced Considerations & Applications

ReAct is the workhorse inside many higher-level systems. Plan-and-Execute often runs a small ReAct executor per step. Multi-agent specialists are frequently ReAct agents with different tool belts. Hybrids keep ReAct where the environment is noisy and add planning where structure is stable.

Model tier matters. Frontier models recover better from messy observations; small models need stricter tool schemas, fewer tools, and stronger stop heuristics. Routing cheap turns to small models and hard turns to large ones is a cost control, not a different architecture, as long as the loop shape stays interleaved.

Security is sharper under ReAct because every observation is attacker-controlled content if tools touch the open web, email, or untrusted documents. Treat observations as untrusted data: never let tool output redefine system policy, and keep privileged tools behind confirmations or separate agents.

Eval strategy for ReAct should score trajectories, not only final answers. Track turn count, repeated actions, tool error rate, and whether the stop was goal-complete versus max-turns. A correct final answer after 40 thrashing turns is still a failed architecture for production SLOs.

Common Misconceptions

• "ReAct requires printing chain-of-thought to the user." Users can see only final answers; the host may keep intermediate reasoning private or use native reasoning channels.
• "More tools always make ReAct better." Extra tools raise decision entropy and misuse risk; start narrow.
• "If the model is smart enough, max turns are optional." Smart models still loop; hosts must bound cost and time.
• "ReAct is outdated now that we have multi-agent frameworks." Those frameworks usually embed ReAct-like loops inside each agent.
• "Any function-calling chat is fully ReAct." A single tool call in one turn is tool use; ReAct is the multi-turn interleaved control loop with stop policy.

FAQs

Related

• The Three Core Agent Architecture Patterns, Compared - how ReAct sits next to planning and multi-agent
• Agent Architectures Basics - minimal ReAct sketches
• Plan-and-Execute: Separating Planning from Execution - the phased alternative
• When to Choose ReAct vs Plan-and-Execute vs Multi-Agent - selection cheatsheet
• Inside the Agent Loop: Perceive, Reason, Act, Observe - loop anatomy
• Planning vs Reacting: Two Philosophies for Agent Decision-Making - planning vs reacting philosophies

Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana @solana/web3.js + @solana/spl-token.