The ReAct Agent Pattern

Why reasoning alone wasn't enough

Chain-of-thought prompting showed that having a model "think out loud" before answering improves accuracy on multi-step problems. But pure reasoning has a ceiling: the model can only reason about what it already knows. It cannot look anything up, check a calculation against a real calculator, or verify a fact against a live system.

Separately, tool-calling gave models the ability to act — call a search API, run code, query a database. But acting without reasoning is also limited: a model that blindly calls tools in sequence has no way to decide which tool to call next, or to notice when a result doesn't make sense.

ReAct (Reason + Act), introduced by Yao et al. in 2022, combined both into a single loop: the model reasons about what it needs, takes an action, observes the result, and reasons again. That loop is now the backbone of the overwhelming majority of production LLM agents.

The think-act-observe cycle

A ReAct agent runs a repeating loop with three phases:

Thought — the model generates a short reasoning trace about what it currently knows and what it needs to do next. This is plain text, not an action.

Action — the model emits a structured tool call (a function name plus arguments) based on that thought.

Observation — the orchestration layer executes the tool and feeds the result back into the model's context as the next input.

The model then produces a new Thought informed by the Observation, and the cycle repeats until the model decides it has enough information to produce a Final Answer. The key property is that reasoning and acting are interleaved, not separated into distinct phases — each action is informed by the freshest observation, and each thought is grounded in what actually happened, not just what the model assumed would happen.

Why this became the default agent loop

ReAct won out over earlier agent designs for a few concrete reasons:

It's self-correcting. Because the model sees the actual observation before deciding its next action, it can recover from a tool returning something unexpected — a 404, an empty search result, a malformed value — without the whole run failing.

It's simple to implement. The loop is just: call the model, parse out an action, execute it, append the result, repeat. No separate planning module, no special training required beyond what instruction-tuned models already have.

It generalizes across tasks. The same loop structure works for web research, code debugging, database queries, and multi-tool workflows — only the tool set changes.

Most frameworks you'll encounter — LangChain's agent executors, the OpenAI/Anthropic native tool-use loops, and most custom orchestration code — implement some variant of ReAct even when they don't use that name.

Where ReAct struggles

The reactive, one-step-at-a-time nature of ReAct is also its main weakness on long-horizon tasks. Because the model only plans one action ahead, it can:

- Lose the thread on tasks requiring 15+ steps, as earlier context gets pushed out of the window or diluted by many observations.
- Thrash — flip between strategies because each thought is generated somewhat independently, without a stable overall plan.
- Waste calls by re-deriving a plan at every step instead of committing to a sequence of steps upfront.

This is the gap that plan-and-execute architectures were designed to address — see the next lesson for how separating planning from execution trades some of ReAct's adaptability for more stability on long tasks.

ReAct vs. a pure planning loop

Practical implementation notes

When building a ReAct loop yourself:

- Use native tool-calling APIs (structured function calling) rather than parsing free-text "Action: ..." strings — it's far more reliable than regex-parsing model output.
- Keep the Thought step lightweight; you don't need the model to write paragraphs, a sentence or two of stated intent is enough to get the self-correction benefit.
- Cap the loop at a fixed number of steps (commonly 10-25 depending on task complexity) and have the agent return its best partial answer if it hits the limit, rather than failing silently.
- Log every Thought/Action/Observation triple — this trace is your main debugging and evaluation tool when the agent misbehaves.

What's next

ReAct is the default loop for agents that need to adapt step by step. For tasks with a long, mostly-known sequence of steps, a plan-first architecture is often more reliable — the next lesson covers plan-and-execute agents and when that tradeoff pays off.