ReAct, short for “reasoning and acting”, is a prompting pattern in which a model alternates between thinking about what to do and doing it with a tool. It was introduced by Yao and colleagues in 2022, and it is the basic loop inside most AI agents today.
The loop
A ReAct agent repeats three steps until it can answer.
- Thought. The model reasons about what it knows and what it needs next.
- Action. It chooses a tool and the arguments to call it with.
- Observation. The application runs the tool and returns the result to the model.
Then the cycle repeats, with the observation now part of the context.
Question: Is order 8841 eligible for a refund?
Thought: I need the order date and the refund window.
Action: get_order(order_id="8841")
Observation: {"date": "2026-09-02", "status": "delivered", "custom": false}
Thought: Delivered and not custom. I need the policy window.
Action: get_policy(topic="refunds")
Observation: "Refunds within 30 days of delivery, excluding custom items."
Thought: 36 days have passed, so it is outside the window.
Answer: No. The 30-day refund window ended on 2 October 2026.
Reasoning without acting cannot reach facts outside the model. Acting without reasoning calls tools blindly. Interleaving them lets each observation shape the next decision.
ReAct with modern tool calling
The original technique used a text format the application parsed. Current model APIs have tool calling built in: you describe each tool with a name, a description, and a JSON Schema for its parameters, and the model returns a structured request to call one. The loop is the same; the plumbing is handled by the API.
That moves the prompt engineering to three places.
1. The system prompt
Describe the goal, the limits, and when to stop.
You are an order support agent. Use the tools to answer questions
about a customer's orders.
- Look up facts with tools. Do not guess order details.
- Call a tool only when its result is needed for the answer.
- If a tool returns an error, try once more with corrected arguments,
then tell the customer what could not be checked.
- Never issue a refund above $200. Escalate instead.
- Stop and answer as soon as you have enough information.
2. The tool descriptions
A model picks tools from their descriptions alone. Treat each description as a prompt.
- Weak:
get_order: gets an order - Better:
get_order: Returns date, status, items, and total for one order. Use when the customer mentions an order number. Does not include payment details.
Say what the tool returns, when to use it, and what it does not do. Name parameters clearly and describe their formats.
3. The tool results
Observations go back into the context, so their shape matters. Return compact, labeled data, not a raw page of HTML. Include an explicit error message the model can act on: “No order with that ID” is useful, a stack trace is not.
Failure modes
Loops. The agent repeats the same call. Set a maximum number of steps and tell the model what to do when it reaches the limit.
Tool overuse. It calls tools for things it already knows. State when not to call.
Wrong arguments. It invents an ID or a format. Tighten the parameter schema and return errors that explain the expected format.
Context growth. Every observation is re-read on every step, so cost grows with the square of the number of steps. Trim or summarize old observations. See token optimization.
Injection through observations. A web page or document returned by a tool can contain instructions. The model may follow them. This is indirect prompt injection, and it is the main security risk of agents. Mark tool results as data, restrict what tools can do, and require approval for irreversible actions.
Premature answers. It answers before checking. Require that factual claims come from a tool result.
When to use ReAct
| Situation | Use |
|---|---|
| Steps are known in advance | A prompt chain: cheaper and predictable |
| The path depends on what is found | ReAct |
| The task needs live or private data | ReAct with retrieval tools |
| The task takes actions in other systems | ReAct, with approval for risky actions |
| A single lookup, then an answer | One retrieval step, not a loop |
An agent is the most flexible option and the hardest to make reliable. Use one when the flexibility is required.
Giving agents tools with MCP
The Model Context Protocol is a standard way to offer tools to an agent, so one tool server works with many AI applications. The PromptFlowEngine MCP server exposes prompt analysis, restructuring, and sanitizing as read-only tools. An agent can use them inside its own loop, for example to sanitize context before passing it on, or to turn a vague task into a specification before it starts.
For the broader design of agent instructions, continue to prompts for AI agents.