The ReAct Pattern: How AI Agents Reason and Act

ReAct (short for “Reason + Act”) is a prompting pattern where a language model alternates between generating a short reasoning step and taking an action — usually a tool call — then reads the result of that action before deciding what to do next. Instead of producing one long chain of reasoning up front and hoping it holds up, the model interleaves thinking and doing, so each new fact from the world can change its plan before it commits further.

This loop is the backbone of most practical AI agents today: a customer-support bot that looks up an order before answering, a coding agent that runs a test before claiming it fixed a bug, a research agent that searches before summarizing.

Why reasoning alone isn’t enough

Plain chain-of-thought prompting asks a model to think step by step before answering, which measurably improves accuracy on multi-step problems. But chain-of-thought reasons entirely from what the model already knows — its training data and whatever’s in the prompt. If a task requires current information, a database lookup, or the actual output of running some code, pure reasoning has nothing new to reason about. It can only guess, and a fluent, confident guess is exactly how LLM hallucinations happen.

ReAct closes that gap by giving the model a way to fetch ground truth mid-task, then reason again with that ground truth in hand.

The loop, step by step

A ReAct agent’s transcript typically looks like a repeating three-part cycle:

1. Thought — the model reasons briefly about what it currently knows and what it still needs.
2. Action — the model emits a structured call to a tool: a search query, a database read, a function invocation. This is exactly what function calling formalizes — a schema-constrained way for the model to request an external action instead of just describing one in prose.
3. Observation — the result of that action (search results, a query response, an API’s return value) is fed back into the context.

The cycle then repeats: the model produces a new Thought informed by the Observation, decides on another Action if needed, or produces a final answer once it has enough information. Crucially, the model isn’t just executing a fixed script of “call tool A, then tool B” — the content of each Observation genuinely influences the next Thought, so the same starting prompt can take a different path through the loop depending on what the tools actually return. A minimal transcript might look like:

Thought: I need the customer's order status before I can answer.
Action: lookup_order(order_id="A1029")
Observation: { status: "shipped", eta: "2 days" }
Thought: I now have what I need to answer directly.
Answer: Your order has shipped and should arrive in 2 days.

Why interleaving matters more than either half alone

The key property ReAct adds over “reason, then act once” is that each action’s result can change the plan. If a search returns nothing useful, the model can reformulate the query rather than pushing forward with a stale plan. If a tool call errors, the model sees the error as an observation and can try a different approach. This is the same intuition behind why iterative refinement generally beats a single unreviewed attempt — the model gets to update on evidence instead of committing to everything up front.

It’s also what separates a ReAct-style agent from a simple retrieval pipeline. Retrieval-augmented generation typically runs one retrieval step before generation and stops there. A ReAct agent can retrieve, evaluate what it got back, and retrieve again with a refined query, or switch to an entirely different tool — the reasoning step between actions is what makes the loop adaptive rather than a fixed pipeline.

Where this shows up in multi-step agents

Most production agent frameworks implement some variant of this loop under the hood, even when the public API doesn’t use the words “Thought” and “Action” explicitly. The pattern generalizes naturally into multi-agent systems, where one agent’s Observation might be another agent’s completed subtask rather than a raw tool result — the loop structure is the same, just with a richer notion of what counts as an “action.”

If you’re building one from scratch, the loop is genuinely simple to implement: a prompt that instructs the model to alternate Thought and Action, a parser that extracts the requested action, code that executes it and formats the result as an Observation, and a stopping condition — usually a maximum number of iterations, since an ungrounded loop can otherwise run indefinitely without ever converging on an answer. See building your own AI agent for a fuller walkthrough of that scaffolding.

Failure modes worth knowing

ReAct doesn’t guarantee correctness — it grounds the model in real observations, but the model can still misinterpret an observation, loop on the same failing action repeatedly, or stop before it actually has enough information. Effective ReAct systems typically cap the number of iterations, validate tool outputs before feeding them back as observations, and give the model an explicit way to say “I don’t have enough information” rather than forcing a final answer on every turn.

The takeaway

ReAct interleaves a model’s reasoning with real tool calls and their results, so the model updates its plan on actual evidence instead of reasoning in a vacuum. That loop — think, act, observe, repeat — is the structural core of most agentic systems in production today, whether or not they label their steps “Thought” and “Action” explicitly. The pattern’s value is adaptability: each observation is a chance to revise course before the agent commits to a final answer.