ReAct agent pattern

What is the ReAct agent pattern?

The ReAct agent pattern is a control loop in which a language model writes a short reasoning trace, chooses one action, observes the result, and then reasons again with that result in context. Reasoning and acting alternate inside a single sequence.

The name comes from the 2022 paper that introduced the loop for language models, and the pattern now underpins most tool-using support agents. A typical customer-service run finishes in three to six iterations: look up the order, check the refund policy, then act.

How the ReAct agent pattern works

One iteration has three parts: a thought, an action, and an observation. The thought is free-text reasoning about what is still unknown. The action is a structured call, usually a tool name plus arguments. The observation is whatever the tool returned, appended verbatim so the model reads its own consequences.

The loop repeats until the model emits a final answer or hits a stop condition: a step ceiling, a timeout, or a guardrail. Around that core sit four supporting layers. Tool definitions describe what the agent may call and with what schema, and an AI agent framework usually supplies the parsing, retries, and step budget so teams do not rebuild them. Working context holds the growing thought-action-observation transcript; anything that must survive past the run gets written to AI agent memory.

Above a single loop, AI agent orchestration decides which agent owns which task when one loop is not enough. Below it, each procedure the agent follows usually traces back to an agent SOP that a human already wrote for the same request type.

Variants of the ReAct agent pattern

• Plain ReAct: The unmodified loop, with one thought and one action per turn and no lookahead. Best for short, well-bounded tasks with reliable tools.

• ReAct with reflection: After a failure the agent writes a critique of its own trace and retries, which raises recovery but also raises latency and token cost.

• Plan-then-ReAct: The model drafts a step list first, then executes each step through the standard loop, useful when tool order genuinely matters.

• Constrained ReAct: Available actions narrow as the run proceeds, so an agent that already issued a refund cannot issue a second one.

• Human-gated ReAct: The loop pauses before any write action and waits for approval, the common shape in regulated support queues.

ReAct agent pattern vs chain of thought vs function calling vs plan-and-execute

These four get conflated because all of them involve a model producing intermediate text before an answer, and the distinction decides what your system has to handle at runtime. Chain of thought produces reasoning only, with no access to anything outside the model's weights. Function calling produces a structured action only, with no reasoning trace and no built-in notion of a second turn. Plan-and-execute produces a full plan before any tool runs, then executes it without revisiting the plan. The ReAct agent pattern combines a reasoning trace with a live action and repeats, which is what lets it correct course mid-task.

If your agent needs external facts before it can decide anything, the ReAct loop is the default. Fixed sequences belong in a workflow engine, and a single deterministic lookup only needs function calling.

Why the ReAct agent pattern matters for customer experience

Without an interleaved loop, an agent commits to a plan built from a customer's first message alone. It then executes that plan against reality: the order was already refunded, the account is on a legacy plan, the address failed validation. The customer sees a confident answer built on stale assumptions, and the correction arrives from a second contact.

The loop changes the failure shape. Because every observation returns to the model, a tool that reports "no matching order" becomes information rather than a crash, and the agent can ask one clarifying question instead of guessing. That is also what makes a clean handoff possible: the trace shows a human exactly which step stalled, which is the difference between a warm transfer and starting over.

The tradeoff is real. Each extra iteration adds seconds and tokens, so a loop tuned for thoroughness feels slow on voice, where silence past a couple of seconds reads as a dropped call.

How is the ReAct agent pattern measured?

HotpotQA, FEVER, ALFWorld, and WebShop are the benchmarks the pattern is usually scored against, and none of them is a bar a support team is graded on. Their task definitions and success criteria were built for research settings, so their scores do not transfer to a refund queue or a billing line, and nothing outside your own case set will tell you whether the loop is working.

Measure the loop on your own cases. The four numbers that matter operationally are task success rate on a labeled case set, mean steps to resolution, tool-call error rate, and the share of runs that hit the step ceiling without answering. Tracking steps and success together stops you from optimizing one at the other's expense. The method itself is defined in the original loop description by Yao et al., which reports interleaved reasoning and acting against task completion. Building the labeled case set is ordinary AI agent testing work, and it has to be rebuilt whenever tools change.

How AI agents change the ReAct agent pattern

The original loop assumed a model that reads text and calls a handful of research tools. Production support agents changed three things about it. Tool surfaces got wider and less forgiving, since a CRM write has consequences a search query does not, so most implementations now split read actions from write actions and gate the second group.

Second, the transcript became an audit artifact. Every thought and observation is stored, replayed, and diffed when an answer is wrong, which turns debugging from guesswork into reading. Third, guardrails moved inside the loop: policy checks run between the action and its execution, one of the operational gaps that separates AI agents from traditional chatbots.

The consequence is that loop design is now an operations decision as much as a modeling one. Step ceilings, retry policy, and escalation triggers get tuned per queue, and the same base model behaves very differently under two different loop configurations.

Implementing the ReAct agent pattern

Start with coverage: list the request types the loop must close end to end, and confirm each has a tool that can actually complete it. An agent that can look up but never act produces polite dead ends.

Integration surface comes next. Every tool needs a typed schema, a timeout, and a documented failure response, because the model reads error text as an observation and will improvise around a vague one. Governance decides who may add or change a tool, and whether a change requires a regression run against saved cases.

Security constraints are non-negotiable for regulated queues. SOC 2 Type II and ISO 27001 cover the platform, ISO 42001 covers AI management specifically, and HIPAA or GDPR obligations dictate what may enter the transcript at all, since observations persist. The operational constraint most teams underestimate is latency budget: a five-step loop with a slow CRM call will miss a voice response window no matter how good the reasoning is.

The ReAct agent pattern and human support workflows

The loop rarely runs alone. When an agent exhausts its step budget or hits a policy gate, the transcript feeds an intelligent virtual agent handoff or lands in a human queue with the thought-action-observation history attached, which is what turns an escalation into a briefing.

That same trace is what makes agent assist useful during live conversations, because the suggestions a rep sees are the observations the loop already gathered. Teams designing this boundary deliberately usually work from a pattern like human agent escalation design before tuning step ceilings.

What does the ReAct agent pattern mean in plain terms?

Think of it as a mechanic who checks one thing, looks at what she found, and only then decides what to check next. She does not write the full repair plan in the parking lot; she opens the hood, reads the gauge, and lets each reading pick the next move.

Picture the alternative. An agent handling a delivery complaint decides upfront to issue a credit, then discovers the parcel was delivered to a neighbor and the customer wanted it retrieved, not refunded. Having already committed, it issues the credit anyway and closes the case wrong.

Every look under the hood costs a few seconds and a little money, so a loop allowed to check everything will be right more often and slower every single time, which is a cost customers feel on a phone line.

Common ReAct agent pattern mistakes

Uncapped loops are the first pattern. Without a hard step ceiling an agent that gets an ambiguous observation will retry the same tool with slightly different arguments until it burns the budget, and the customer waits through all of it.

Silent tool failures are the second. When a tool returns an empty result for both "no records" and "service down", the model reads the same observation for two different situations and confidently reports that nothing exists.

Unbounded context growth is the third. Every observation appends to the transcript, so a long run pushes the original customer question toward the edge of the window, and the agent starts answering a question it no longer fully remembers.

The fourth is treating the trace as decoration. Teams that log traces but never review them lose the one artifact that explains why an answer was wrong, and they end up tuning prompts by intuition when the observation history already held the answer.