A_ made by arjun

2026.08.30 · WRITING

What ReAct Actually Does: How an Agent Acts, Observes, and Adjusts

Starting with a failed CI run, see how Thought, Action, Observation, and the Runtime let an Agent adjust its next move from environmental feedback.

ReAct is often reduced to three words: Thought, Action, and Observation. The sequence is easy to remember. The difficult part is understanding what the loop is supposed to solve.

It is not primarily about making a model think more completely in one attempt. It addresses a more practical problem: how can a model keep making progress when the next step depends on what just happened?

Start with a Failed CI Run

Suppose you give an Agent this task:

Find out why the repository’s latest CI run failed and propose the smallest reasonable fix.

The model cannot know the answer from that sentence alone. It has not seen the failed Job, the logs, or the recent changes. The investigation has to begin with an action.

In the first round, the Agent opens the failed job and reads its logs. An integration test has timed out.

In the second round, it opens the timeout location and the recent commit history. The new evidence suggests that the database container was not ready when the test started.

In the third round, it runs a targeted test and adds a readiness check to the startup step. The test passes.

If the first result had been a compilation error, the second action would not have investigated the database. The path is not a checklist written in advance. Each returned result changes what is worth doing next. That is the useful idea at the center of ReAct.

An Agent starts from a failed CI run and changes the investigation path after each Observation
The path is not a prewritten checklist: the timeout and database-readiness Observations change what happens next.

ReAct Is Not a Model. It Is a Way to Move a Task Forward

ReAct stands for Reasoning and Acting. The paper first appeared as a 2022 preprint and was later published at ICLR 2023. It placed language reasoning traces and task-specific actions in one interleaved trajectory so that each could inform the other.

The smallest version of the loop looks like this:

Thought → Action → Observation
   ↑                     ↓
   └──── continue with new evidence ────┘

What matters is the closed loop:

The trajectories in the original paper used explicit text labels. Modern tool-calling systems may look different. A model can emit a structured Tool Call, the Runtime can execute it, and the resulting Tool Result can be appended to the message history. The interface may not show a paragraph labeled “Thought,” but the loop of choosing, executing, observing, and choosing again can still be present.

Even in the original paper, a Thought did not have to appear before every Action. For decision-making tasks with many consecutive actions, the authors used sparse reasoning traces at selected points. Thought → Action → Observation is therefore a useful conceptual skeleton, not a mandatory line-by-line output format.

Thought, Action, Observation, and Context Update form a ReAct feedback loop
The core idea is the feedback loop. Thought is a conceptual role here, not a claim that complete reasoning text must be exposed at every step.

What Thought, Action, and Observation Actually Do

Thought: Decide What Is Worth Doing Now

In a classic ReAct prompt, Thought is a text reasoning trace generated by the model. It can state what the system knows, what it still needs, and why a certain action should come next.

Thought should not be treated as an always-visible, always-faithful window into the model’s “mind.” Modern models may not expose raw Chain of Thought, and a product may retain only a short decision summary. Even an explanation that is displayed does not necessarily reproduce the model’s internal computation in full.

For engineering purposes, inputs, selected tools, arguments, tool results, and state changes are more dependable observability targets. They answer “what did the system do?” without pretending that we can completely inspect how the model thought.

Action: Hand a Textual Decision to an External System

An Action may search the web, query a database, run a test, read a file, or call a business API. The model usually proposes the tool name and arguments. The host application or Agent Runtime performs the real operation.

{
  "tool": "read_ci_log",
  "arguments": {
    "run_id": 1842,
    "job": "integration-test"
  }
}

This structured output is not yet the result of an action. In a production system, the Runtime would typically also check arguments, permissions, and timeouts before invoking the tool. Those checks are engineering controls, not part of the paper’s definition of an Action.

Observation: Record What the Environment Returned

An Observation is the information returned to the model after a tool runs, such as a log excerpt, a search result, a database row, or test output.

It is closer to the task environment than a guess from model memory, but it is not automatically true. Search results can be stale, an API can fail, logs can be truncated, and tests can be flaky. ReAct lets a model reach external evidence. It does not guarantee the quality of that evidence.

This distinction matters. Tool use can reduce unsupported generation, but data sources, parameters, parsing, and verification still separate “a tool was used” from “the answer is reliable.”

The Runtime Is What Keeps the Loop Moving

A ReAct prompt does not create a working Agent by itself. A Runtime is needed to connect the model to tools.

state = goal + known information + previous tool results

while not finished:
    decision = model(state)

    if decision is a final answer:
        return decision

    result = runtime.execute(decision.tool_call)
    state = state + result

The pseudocode omits many production details, but it clarifies the boundaries:

ReAct is therefore closer to an interaction protocol than a feature owned by one framework. Agent frameworks can implement a similar feedback process with graphs, state machines, or message loops.

Responsibilities and data flow among the model, Runtime, tools, state, and external environment
The model proposes a Decision and the Runtime executes the Tool Call; the model does not bypass the Runtime to access an API or database directly.

Why ReAct Fits Some Tasks Better Than a One-Shot Answer

It Can Retrieve Missing Information First

The model does not have to pretend it already knows everything. When a task needs live data, precise calculation, private documents, or access to a codebase, the system can call the appropriate tool first.

It Can Change Direction After Seeing a Result

A failed attempt does not have to end the task. If the result contains useful information, the Agent can revise its hypothesis, choose another tool, or narrow the scope of the problem.

It Leaves a Behavioral Trace That Can Be Inspected

Tool calls, arguments, and Observations can be recorded. Developers can then locate the step where the system selected the wrong tool, misread a result, or failed to stop. That is easier to debug than a system that exposes only its final sentence.

The inspectability comes primarily from the external behavioral trace. It should not be overstated as complete transparency into every part of the model’s reasoning.

Where the Loop Breaks

1. Errors Propagate Through Context

If a search returns incorrect information, the model may use it as a premise for later steps. The remaining work can look coherent while still being built on a false premise.

Important facts need source constraints, cross-checking, or deterministic validation. The first Observation should not automatically become the conclusion.

2. Every Round Adds Latency and Cost

Model calls, network requests, and tool execution all take time. Forcing a problem that a normal function can solve through five ReAct rounds only makes it slower.

A Workflow is often the better fit when the steps are fixed and the branches are limited. An Agent loop earns its complexity when the system must see a new result before it can select the next step.

3. Unclear Tool Descriptions Lead to Bad Choices

Two overlapping search tools, vague argument names, or write operations without clear boundaries make Actions less reliable. A larger toolset does not automatically create a more capable Agent.

4. Without a Stopping Condition, the Loop Can Spin

An Agent may repeat the same query or continue calling tools after the evidence is sufficient. The Runtime needs completion criteria, turn limits, time and cost budgets, and a way to pause for approval before risky operations.

Four common ReAct loop failures and their corresponding controls
ReAct does not solve these failure modes automatically. Reliability comes from source checks, clear tools, budgets, and stopping conditions.

How ReAct Relates to Modern Tool Calling

Classic ReAct prompts often instruct the model to emit Thought, Action, and Observation in a text format. Modern models can return a structured Tool Call directly, so the application no longer has to parse tool names and arguments from free-form text.

These concepts overlap, but they are not identical:

An Agent can use a ReAct-style feedback loop without printing the classic format. A system can also use Tool Calling once and stop, without forming a multi-round ReAct loop.

That is why the name of a framework function is not the important part. In current LangChain releases, for example, the recommended entry point has moved to create_agent from the older create_react_agent. What matters is whether the system keeps updating state between the model and its tools, not whether ReAct appears in the API name.

When ReAct Is Worth Using

Ask three questions:

  1. Does the task require information that must come from outside the model?
  2. Will the result of one tool call change what the system should do next?
  3. Does the system have an observable, verifiable completion condition?

If the answer to the second question is no, ReAct is probably unnecessary. A fixed Workflow is typically faster, easier to control, and easier to audit.

If the answer is yes, as in incident investigation, multi-source research, or changes to an unfamiliar codebase, the cycle of acting, observing, and adjusting becomes useful.

ReAct does not give a model a mysterious hidden reasoning faculty. It turns one practical rule into system structure: when information is missing, do not guess. Take a bounded action, inspect the result, and then choose the next step.

References