Skip to content

Technique

Advanced

ReAct: Reason + Act

An agent pattern where the model alternates reasoning steps with tool actions and observations until it can answer.

What it is

ReAct (short for Reason + Act) is a pattern for building AI agents in which the model interleaves reasoning with actions. It thinks about what to do next, takes an action using a tool (search, a calculator, a database query, an API call), reads the result (the observation), and repeats until it has enough information to answer.

ReAct is an application pattern: the surrounding software actually executes the tools and feeds results back. The prompt defines the loop, the available tools, and the rules. Many modern AI assistants and agent frameworks use variations of this idea, often through built-in "tool use" or "function calling" features.

When to use it

  • Questions that need fresh or external information (search, databases, APIs)
  • Multi-step tasks where each step depends on what the previous one found
  • Tasks that need exact computation or lookups rather than the model's memory
  • Building agents or assistants that can take actions in other systems

How it works

The loop

A ReAct-style agent cycles through three parts:

  • Thought: the model reasons about what it knows and what to do next.
  • Action: it calls a tool with specific input.
  • Observation: the system runs the tool and returns the real result.

The loop repeats until the model produces a final answer. Grounding each step in real observations helps the model correct course and reduces made-up facts, compared with reasoning alone.

What a ReAct prompt looks like

In a hand-built agent, the system prompt describes the tools and the format:

Prompt
You can use these tools:
- search(query): searches the web and returns short snippets
- calculator(expression): evaluates arithmetic exactly

Work in this loop:
Thought: what you need to find out next
Action: tool_name(input)
Observation: (the tool result will be provided to you)
... repeat as needed ...
Final Answer: your answer, citing the observations you used

Never invent an Observation. If the tools can't find the answer, say so.

An illustrative trace for "How many years passed between the first Moon landing and the founding of the company that made the Falcon 9 rocket?":

Illustrative example response — written by Promptly, not generated live
Thought: I need the founding year of the Falcon 9 manufacturer. Action: search("Falcon 9 rocket manufacturer founded") Observation: SpaceX ... founded in 2002 ... Thought: The first crewed Moon landing was in 1969. Compute the difference. Action: calculator(2002 - 1969) Observation: 33 Final Answer: 33 years (Apollo 11 in 1969; SpaceX founded in 2002).

Note: In production, tool calls are usually handled through the platform's native tool-use or function-calling features rather than parsing text like "Action:". The visible "Thought" text is generated reasoning that helps guide the next step; it isn't a guaranteed faithful record of the model's internal process.

The spirit, without code

Even in a chat app, you can apply the idea by acting as the "tool runner": ask the AI to tell you what to look up, run the search or check yourself, paste back what you found, and let it continue. Many assistants with built-in web search or code execution do this loop for you.

Watch out: Agents that can take real actions (sending emails, editing files, spending money) need guardrails: limited permissions, confirmation steps, and step limits to prevent runaway loops.

Step by step

  1. 1

    Define the tools the model may use, with names, inputs, and what each returns.

  2. 2

    Write instructions for the loop: reason, choose an action, wait for the observation, repeat.

  3. 3

    Have your application (or you, by hand) execute each action and return the real result.

  4. 4

    Forbid invented observations and require a clear final answer that cites what was found.

  5. 5

    Set limits: maximum steps, allowed actions, and confirmation before risky actions.

  6. 6

    Review traces of failures to improve tool descriptions and instructions.

Weak vs strong

Weak prompt
What's the current exchange rate from USD to EUR, and how much is $2,450 in euros?
Why it falls short: Without a tool to fetch current data, the model can only use its possibly outdated training data, and may state a stale rate and a computed total with misleading confidence.
Strong prompt
You have two tools: get_exchange_rate(from, to) and calculator(expression). To answer, first get the current USD→EUR rate, then calculate the conversion of $2,450 using the calculator. Show each Action and Observation, then give a Final Answer with the rate, its source, and the converted amount. If a tool fails, report that instead of estimating.
Why it works: It defines the tools, the order of actions, the requirement to use real observations for both data and math, and a safe failure behavior.

Practical use cases

  • Research assistants

    Search, read results, refine the query, and compile an answer with sources for questions about recent events.

  • Data questions

    Translate a question into a database query, run it, inspect the result, and explain it in plain language.

  • Coding agents

    Read files, run tests, observe failures, edit code, and re-run until tests pass.

  • Manual tool loop in chat

    Ask the AI what to check next while troubleshooting your Wi-Fi, run each check yourself, and report the results back.

Practice exercise

Be the tool. Pick a question that needs real lookups, such as "Which of three nearby parks is best for a picnic this Saturday?"

  1. Ask the AI to work in Thought / Action / Observation steps, where each Action is something you look up (weather, park facilities, distances).
  2. Do each lookup and paste the real result back as the Observation.
  3. When it gives a Final Answer, check that every claim traces back to an Observation you supplied.