What is the ReAct pattern?

The ReAct pattern is a way of building AI agents in which the model alternates between reasoning and acting: it thinks about what to do, takes one action with a tool, observes the result, then reasons again. The name joins "reason" and "act". It is the basic loop behind many agents, and its strength is that each step uses what the last one revealed.

How does the ReAct loop work?

Three moves, repeated. Thought: the model writes a short note on what it knows and what it needs next. Action: it calls a tool, such as a search over the policy library or a lookup in the billing system. Observation: the tool's result comes back into the context. The model then writes its next thought, and the cycle continues until it can answer or decides it cannot.

Compared with answering in one go, this lets the agent fetch facts as it discovers it needs them, recover from a failed lookup, and change direction when a result surprises it.

Why does the pattern matter once agents act?

Because every "action" in the loop is a real call to a real system. In early examples, actions were mostly searches. In business agents, an action can be "update the address" or "issue the credit". The loop does not distinguish between a harmless lookup and a consequential change. Both are just the next action.

Observations are a second risk. Whatever a tool returns goes straight into the model's context. If the agent searched the web or opened an inbound email, the observation may contain instructions written to steer it. ReAct gives that text a direct route into the next thought.

How is it used safely in practice?

Put a check between each proposed action and its execution. Lookups against approved sources can be allowed freely. Anything that changes a record is checked against the agent's bounds before it runs. Observations are stamped with their source and class before they re-enter the context, so an external result is never read as an instruction. And each thought-action-observation step is logged, so the path to any outcome can be reconstructed.

ReAct often uses retrieval-augmented generation as one of its actions, fetching passages mid-task. Each step should be grounded in what was actually retrieved, not in what the model assumes.

What does that look like in an example?

A building insurer's agent handles "my claim was paid short". Thought: check the claim and the payment. Action: look up the claim. Observation: settlement of 3,000, excess of 250. Thought: check the policy excess. Action: look up the policy schedule. Observation: excess is 100. Thought: the excess was applied wrongly; propose a top-up of 150. Action: issue payment. That last action does not run directly. It goes to the control layer, which holds it for a claims handler because payments are above the agent's certified depth.

How is ReAct different from plan-and-execute?

In plan-and-execute, the agent writes the full plan first and then carries out the steps. In ReAct, it decides one step at a time. Plan-and-execute is easier to review in advance, because the whole plan can be checked before anything happens. ReAct adapts better to surprises. Many agents combine them: a short plan up front, with ReAct inside each step.

Where Pryme fits

Pryme sits between each ReAct action and its execution, checking it against the minimum chain and filing the verdict. That makes the loop safe to use in regulated work, which is much of why businesses need an agentic operating system. See the governed agentic operating system, explained.