REA-PLN-01Tier IReasoning & World Model

ReAct (Reason–Act Interleaving)

Externalise the agent's reasoning by alternating visible thought steps with tool actions, so each decision leaves an inspectable trace.

Runtime: Reason / PlanAgentOps: Build & IntegrateSee on the matrix →
ReAct — THOUGHT · ACTION · OBSERVATION Thought"I shouldsearch for X" Actionsearch(query) Observationtool result Thought"Found Y, needZ" AnswerterminateYao et al. (ICLR 2023) — interleave reasoning with acting; trace becomes the audit.
In Plain English

This page is the complete instruction page for one pattern called "ReAct (Reason–Act Interleaving)." It explains the problem this pattern solves, the idea behind the solution, when you should (and should not) use it, and what happens afterward — both the good effects and the costs.

This matters because building AI agents is not just about making them clever. It is also about making them safe and predictable. Following a well-tested pattern like this one helps avoid common mistakes, and shows you exactly which safety rules and regulations it connects to, listed under "Standards Mesh" on this page.

Context

Jumping from a user request to a final answer or action is opaque. When the agent is wrong, there is nothing to debug. When it is right, there is no basis for trust.

Problem

Single-shot reasoning is unverifiable and prone to premature commitment.

Forces

  • Latency vs verifiability
  • Token cost vs debuggability

Solution

Structure every step as Thought → Action → Observation. The agent writes its reasoning, chooses a tool, observes the result, and continues. The trace becomes the audit trail and the debugging surface.

Applicability

  • Default starting pattern for most reasoning-heavy agents
  • Investigation, research, troubleshooting agents
  • Customer support agents handling non-standard requests

Anti-Patterns

  • Hiding reasoning for "cleanliness"
  • Using ReAct on trivial single-step tasks where it adds only cost

Consequences

  • +Transparent audit trail
  • +Easier debugging
  • +Reduced premature conclusions
  • Higher latency and token cost per query
  • Weak models produce weak chains