What Is a ReAct Agent?

A ReAct agent is an AI system that alternates between deciding what to do and taking an action, then uses the result to decide what comes next. ReAct is short for “reasoning and acting.” Instead of replying from its existing context in one pass, the agent can call tools such as a search function, a database, or a business application, observe what happens, and continue.

That loop is the key difference from a basic chatbot. A chatbot usually answers from the information in its prompt or conversation. A ReAct agent can gather fresh information or perform a task before responding. For example, it could check an order system, find a delayed shipment, look up the relevant policy, and then draft a response for a support representative to review.

ReAct is a pattern for building agents, not a guarantee of accuracy or autonomy. It works best when the available tools are clear, the task needs information or actions beyond a single answer, and a person can review consequential decisions.

How a ReAct agent works

A ReAct agent follows a repeating loop:

1. Reason: Determine what information or action is needed next.
2. Act: Call an available tool, such as a search, calculator, or business system.
3. Observe: Read the tool’s result.
4. Repeat or respond: Use the result to choose another action, or provide an answer.

Consider a support request: “Where is order 8421, and can you tell the customer when it will arrive?”

A basic chatbot might explain how to check an order, or make a guess if it has been given order details in the conversation. A ReAct agent could instead:

• Search the order system for order 8421.
• Read the shipment status and estimated arrival date.
• Check whether the result is complete and relevant.
• Draft a customer response using the information it found.

The agent isn’t simply producing a longer answer. It’s using information returned by tools to guide what it does next. If the order system says the shipment number is missing, the agent might check another approved source or stop and ask for help.

In real systems, the model’s private reasoning may not be shown to users or recorded in full. That’s generally a good thing. A business should log useful details such as which tool was called, what result came back, and why the workflow continued or stopped. A short decision summary is often more useful for review than a raw stream of internal reasoning.

ReAct agent vs. basic chatbot

The difference comes down to whether the system can take a step and use the result.

Basic chatbot	ReAct agent
Responds using the conversation and supplied context	Can call tools to retrieve information or perform actions
Often completes a request in one response	May take several steps before responding
Doesn’t inherently know whether an answer is current	Can check a connected source, if one is available
Usually offers guidance rather than changing a system	Can make changes when given the right tool and permission

A ReAct agent doesn’t automatically have access to your company’s data. Someone has to connect the relevant tools and decide what the agent is allowed to do. Nor does using tools make its answers correct by default. It can misunderstand a result, select the wrong tool, or take an action the workflow shouldn’t permit.

If you want a short definition and overview of the pattern, see our ReAct agent directory page. This article focuses on a different question: how to decide whether the pattern belongs in a real business workflow and how to put guardrails around it.

A practical example: handling a delayed order

Suppose your team wants to reduce the manual work involved in responding to delayed shipments. The agent shouldn’t begin by sending messages to customers. Start with a narrower task: find relevant shipment data and prepare a draft for a person to review.

Here’s how a ReAct loop could handle one request:

Request: “Check the status of order 8421 and draft a customer update.”

Reason: The agent needs the current order and shipment details before it can draft a useful response.

Act: It calls the order lookup tool with order number 8421.

Observe: The tool returns the order record, including shipment number and current status.

Reason: The status alone doesn’t include an arrival estimate. The agent needs a second source.

Act: It calls the shipping lookup tool with the shipment number.

Observe: The shipping tool returns a revised delivery estimate and a note that the package is delayed.

Respond: The agent drafts a concise update and shows the source data to a support representative.

The human can verify the details and send the message. If the order lookup returns multiple matches, or the shipping service is unavailable, the agent should stop rather than choose a record or invent an arrival date.

That stop condition matters. A dependable workflow doesn’t just specify what the agent should do when everything goes well. It also defines what happens when the tools return incomplete, conflicting, or unexpected information.

How to build a ReAct workflow step by step

1. Choose a task that needs actions

Look for work where a person repeatedly gathers information from one or more systems before making a decision. Examples include preparing a case summary from support records, checking whether an invoice matches a purchase order, or researching a supplier before a review.

Avoid starting with a broad goal such as “run customer support.” Choose one workflow with a clear input and a clear definition of done.

2. Write down the decision process

List the steps an experienced employee follows. For each step, mark whether it involves a judgment, a tool lookup, or a change to a system.

For the delayed-order example, that might be:

• Confirm the order number.
• Retrieve the correct order.
• Check shipment status.
• Compare the result against the delivery policy.
• Draft an update.
• Ask a person to approve and send it.

This gives you a starting point for deciding which parts belong to the agent and which should stay with a person.

3. Connect only the tools the task needs

Give the agent access to specific functions rather than broad system permissions. An order lookup tool may only need to read order and shipment information. It doesn’t need permission to edit customer records or issue refunds just to draft a status update.

Clear tool descriptions matter too. Define what information a tool requires, what it returns, and what to do if it fails. If a tool can make a consequential change, treat that as a separate permission and workflow decision.

4. Define the loop and its stopping rules

Set boundaries before letting the agent run. Decide how many actions it may take, which tools it may call, and what conditions require it to stop. For example, stop if the order number is ambiguous, a required service fails, or two sources disagree.

The agent also needs a clear success condition. “Find the current delivery estimate and prepare a draft with its source” is easier to test than “handle the customer.”

5. Add human review where the cost of an error is high

Keep a person in the loop for actions that affect money, legal commitments, customer communications, or access to sensitive data. The right review point depends on the risk. A routine status summary may need a spot check, while a refund or contract change may require explicit approval every time.

6. Test normal cases and failure cases

Try realistic examples, including missing data, duplicate records, tool timeouts, and conflicting results. Check whether the agent calls the right tools, stops when it should, and presents enough evidence for a person to review its output.

A working demo proves that the happy path is possible. It doesn’t prove the workflow is safe to run on live cases. For broader implementation guidance, explore our guides and learning resources.

What does it cost to run?

There isn’t one standard price for a ReAct agent. The cost depends on the model and hosting arrangement, the number and length of model calls, tool or data service charges, and the engineering and monitoring needed to run the workflow.

A one-step lookup may need only a small number of model interactions. A task that repeatedly searches, checks results, and retries may use more. Each loop can add another model call, and a long tool response can make later calls more expensive. Poor stopping rules are therefore a cost problem as well as a reliability problem.

Estimate cost by measuring a sample of real tasks. Record the number of model calls, the data passed into those calls, tool usage, retries, and how often a person has to correct or finish the work. Then compare that total with the current process, including staff time spent checking results. Don’t count a task as automated if a person still has to repeat most of it to trust the outcome.

The build also takes effort beyond connecting a model to a tool. Plan for permissions, test cases, error handling, logs, and a way to review changes when the workflow or source data shifts. Our operations page covers the operational side of putting these systems into practice.

Where ReAct agents go wrong

Common failures often come from workflow design, not from the loop itself.

• The agent keeps calling tools without making progress. Set a maximum number of steps and a clear stop condition.
• It uses the wrong record. Require confirmation when an identifier returns multiple matches. Don’t let the agent guess.
• It treats a tool result as complete when it isn’t. Specify required fields and what to do when a source omits them.
• It acts on an outdated or conflicting result. Show the source and time of retrieval, and stop when the evidence doesn’t support a safe answer.
• It has too much permission. Limit access to the tools and operations needed for the task. Separate read access from actions that change records or spend money.
• It appears to work, but nobody can explain what happened. Keep logs of tool calls, outcomes, errors, and approvals. Make it possible to trace a result back to its sources.

The central risk is misplaced confidence. An agent can produce a fluent response after a bad lookup. Build the process so that evidence, permissions, and escalation rules matter more than the polish of the final answer.

When should you use one?

Use a ReAct agent when a task needs the system to gather information or take a sequence of bounded actions, and the results can be checked. It’s a reasonable fit for preparing case notes, retrieving facts from approved sources, or drafting a response from current order data.

A basic chatbot may be the better choice when a request can be answered from a stable set of information, or when connecting tools would add more risk and maintenance than value. A fixed automation may be better when every step is predictable and doesn’t require the system to choose what to do next.

If you’re weighing an agent against a scripted workflow, start by mapping the decisions and exceptions. Our blog has more practical guidance for teams planning AI and automation work. If you’d like to discuss a specific workflow, you can book a call with Sam.

A ReAct agent is useful when it can take a few well-defined steps to reach an answer that a person can verify. Keep the task narrow, give it only the tools it needs, and make stopping safely part of the design.