ReAct Agent Architecture

ReAct interleaves reasoning (free-text "thoughts") and acting (tool calls) in a single loop, so the model plans, takes an action, observes the result, and re-plans against ground truth instead of hallucinating the whole trajectory up front. It is the default control-flow shape for a single tool-using agent. (Not React.js.)

The architecture is a loop over four message roles the model and runtime exchange until a stop condition fires: Thought (the model's private reasoning), Action (a structured tool invocation), Observation (the tool's returned result), repeat, then Answer. Reasoning grounds each action in the latest observation; acting grounds each thought in external state. The pairing is what beats both chain-of-thought-only (reasons but cannot check facts) and act-only (calls tools but cannot plan). Source: Yao et al., ReAct, arXiv:2210.03629

Components

• Policy model — the LLM that emits the next Thought + Action given the running trace.
• Prompt scaffold — system instructions plus few-shot exemplars (or a tool schema) that teach the Thought/Action/Observation grammar.
• Tool registry — the set of callable actions with names, descriptions, and argument schemas. Quality here dominates agent quality; see Tool-Calling Design.
• Action parser — converts the model's output into a typed call. Native function-calling APIs make this a JSON decode; text-parsed ReAct uses a regex/grammar and is more brittle.
• Executor — runs the tool, captures success/error, and formats the Observation.
• Scratchpad / trace — the append-only transcript of all prior steps, fed back each turn. This is the agent's working memory.
• Stop controller — ends the loop on a final answer, a step/token budget, or a repeated-action guard.

Control flow

Each iteration appends Thought → Action → Observation to the scratchpad, so context grows linearly with step count. The loop is stateless between requests except for whatever the scratchpad carries; durability and cross-session memory are layered on top, not intrinsic.

Failure modes and mitigations

• Context growth — long traces blow the window and the latency/cost budget. Mitigate with observation truncation, summarization of old steps, or scratchpad compaction. See Latency Budgets for Agents.
• Action-parse errors — malformed tool calls. Native function calling and strict schemas remove most of this; otherwise re-prompt with the parse error as an Observation.
• Loops / thrashing — the agent repeats the same failing action. Add a step budget, a no-progress detector, and a "you already tried X" guard.
• Tool-result overload — a tool that dumps thousands of tokens poisons the window. Return the smallest meaningful Observation (the Tool-Calling Design rule).

Where it sits

ReAct is the atomic single-agent loop. Planner-Executor Agent Architecture adds an explicit plan phase ahead of the loop for long-horizon tasks; Reflection and Self-Critique Agent Architecture adds a critique pass after it. Multi-Agent Topologies compose many ReAct agents under an orchestrator. Kevin's The Brain-Agent Loop is ReAct in practice: qmd hybrid search is the tool, the Observation is the retrieved wiki page, and the agent decides how deep to follow cross-references before answering. Source: compiled from The Brain-Agent Loop

Architecture Position

---

Timeline

• 2026-07-01 | Architecture category refresh added this page to the Agent runtime and control plane family, linked it to Architecture System Map, and kept it standalone because it owns this boundary: Reasoning/action loop with tool calls and observations. Source: User request, 2026-07-01

• 2026-06-02 | Page created. Captured the Thought/Action/Observation loop, component breakdown, control-flow diagram, failure modes, and placement relative to planner-executor, reflection, and the brain loop. Source: Yao et al., ReAct, arXiv:2210.03629