1Tool execution: the orchestrator runs the requested tool and captures its return value.
2Action: the model emits a tool call (function name + arguments) based on the thought.
3Thought: the model emits a reasoning step about what to do next given the current state.
4Observation: the result of the tool call is appended to the model's context.
**ReAct** stands for Reason + Act. Each iteration of the loop has four moves and they happen in a fixed order.
First, the model emits a **Thought**, a short reasoning step that says what it wants to do next. Then it emits an Action, which is a tool call (function name plus arguments).
Then the orchestrator (the code wrapping the model, not the model itself) runs the tool and captures the result. Finally, that result is appended to the model's context as an **Observation**, and the next iteration starts.
The model emits only the Thought and the Action. The orchestrator executes the tool and supplies the Observation. The cycle continues until the model decides it has enough information and emits a final answer instead of another Action.
**ReAct** (Yao et al. 2023) interleaves reasoning with tool use. One iteration goes in this order: Thought, Action, Tool execution, Observation.
The model writes a Thought line first, a short verbalized reasoning step about what it needs next. It then emits an Action, a structured tool call (function name plus arguments).
The orchestrator, which is the runtime around the model, parses the action, calls the actual tool, and captures the return value. That return value is then appended to the model's context as an **Observation**, and the next iteration begins.
The split matters because the model only ever emits text. It never executes a tool itself. The orchestrator is responsible for parsing the action, running it, and feeding back the result.
Modern hosted runtimes (LangGraph, OpenAI Assistants, Claude tool-use loops) implement exactly this pattern. The Thought sometimes collapses into native tool-call message types, but the four phases are still there in some form. The loop terminates when the model emits a final answer instead of another Action, which is why the Thought phase is where the agent decides to stop.
Quick reference
TL;DR
One ReAct iteration runs Thought, then Action, then Tool execution by the orchestrator, then Observation appended back to context for the next iteration.
Picture a detective at a desk. First they think out loud about what they need to know next. Then they hand a note across the desk asking for a specific file. An assistant walks off, fetches the file, and brings it back. The detective glances at what the assistant returned, then thinks again. That cycle (think, ask, fetch, look) is one round of detective work. A ReAct agent does the same four moves in the same order. The model is the detective, the orchestrator is the assistant, the tool call is the note, and the observation is the file coming back.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Single-shot Q&A with no tool dependency ReAct adds reasoning + tool-call latency for a task that does not need either; a plain prompt is faster and cheaper.
Workflows with fixed deterministic tool sequences If the steps are known in advance, a hard-coded pipeline beats letting the model decide which tool to call next.
Strict-latency real-time chat where every extra token costs visible delay Thought lines add tokens per turn; in latency-sensitive paths a direct tool-use loop without verbalized reasoning may be the right tradeoff.
Quick scan · 2–4 min
Everything important, quickly.
3 min: the four-phase order + who owns each phase + termination logic + how modern runtimes (LangGraph, OpenAI Assistants, Claude tool-use) implement it + common loop-failure modes.
Real-world examples
Real products, models, and research that use this idea.
1LangGraph implements the four-phase ReAct loop as graph nodes, with explicit edges for tool execution and observation appending; the framework is built around this exact ordering.
2OpenAI Assistants API runs tool-call loops where the model emits a function call (Thought + Action), the SDK executes it client-side, and the result is posted back as a tool message (Observation).
3Anthropic Claude tool-use loops follow the same shape: the model emits a tool_use content block, the client runs the tool, and the result is posted back as a tool_result block in the next turn.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow does the model decide to stop calling tools?
Sign in or go Pro to see the approach for this follow-up.
QWhat happens if a tool call fails or times out?
Sign in or go Pro to see the approach for this follow-up.
QHow is ReAct different from a pure tool-use loop without verbalized reasoning?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Putting Action before Thought, or believing the model itself runs the tool instead of just emitting a request the orchestrator interprets and executes.