ReAct Pattern

The ReAct pattern, short for reason and act, is a way of running an AI agent in which a language model repeatedly decides on a step, the application carries it out, and the result is fed back before the next decision. Google’s architecture guidance for agent systems describes it as an agent operating “in an iterative loop of thought, action, and observation until an exit condition is met.”

One turn of the loop

In the thought step, the model reviews the task and everything gathered so far and decides whether it is done. If not, the action step is a tool call: the model names a tool and its arguments, and the application validates and executes it. In the observation step, the tool’s result is added to the context for the next thought. If the task is done, the model writes the final answer instead of calling a tool.

Consider a hypothetical agent asked why an order is late. It looks up the order and observes that it shipped on Monday. It looks up the shipment and observes that the carrier reports a failed delivery attempt. It checks the address and observes a missing apartment number. It then identifies the missing apartment number as a possible cause and asks for confirmation before recommending an address correction. The agent can start with a plan and then revise it as observations arrive; the pattern does not require every next step to be unplanned. That adaptability is the pattern’s value.

Where it fails

The loop runs until something stops it, and the model is not a reliable judge of when that should be. Common failures are repeating the same action after an unclear error, misreading an observation and building later steps on the mistake, and treating a planned action as if it had been carried out. Google’s guidance notes, of looped agent designs generally, that a badly defined termination condition can let the loop run indefinitely, with the cost and resource use that follow. Robust implementations therefore enforce limits in the application rather than relying on the model: a maximum number of steps, a time and cost budget, a policy that permits safe bounded retries while suppressing uncontrolled repeated proposals, and explicit exits for completion, missing information, an unrecoverable error, and a need for a person to decide. Stopping the loop does not cancel an external effect already in flight. Retain its pending status and owner, and include retries and polling in shared service budgets as well as task limits.

When the steps are known in advance, the same guidance points to deterministic workflows, in which the application fixes the sequence and the model fills in individual steps. A fixed sequence can reduce orchestration cost and make testing more predictable when the task fits that structure. Actual cost depends on the work performed and recovery behavior; compare the simpler workflow before granting open-ended control. How to keep either design safe when its steps change real systems is covered in The Refund Went Out Twice.

References

• Google Cloud Architecture Center, Choose a design pattern for your agentic AI system (Creative Commons Attribution 4.0).