ReAct Pattern: Reasoning and Acting Loop

ReAct means the agent does not answer in one jump. It reasons about the next useful step, performs an action such as a search or API call, observes the result, and repeats until it can stop. The important product idea is the loop boundary, not the spelling of the prompt template.

The running example is a support agent diagnosing invoice INV-8127. A plain LLM may guess. A ReAct-style agent checks the billing API, reads account status, decides whether to refund, and returns an answer with tool evidence.

A ReAct loop is only as reliable as its tools. Each action needs an input schema, permission boundary, timeout, retry policy, and output shape. Without those contracts, the model can call the right-sounding tool with the wrong arguments or continue looping after a recoverable error.

For INV-8127, getInvoice(id) should return explicit states such as paid, void, or chargeback_pending. The agent should not infer billing state from raw prose when a typed field exists.

Trigger: INV-8127 was merged into a new invoice id, but the lookup tool returns NOT_FOUND without a redirect hint. Symptom: the agent retries the same lookup until the token budget is gone. Root mechanism: the loop has action freedom but no progress detector.

Recovery is to add a repeated-action guard and a fallback lookup by customer id. Prevention is to store loop state: last action, last observation, unresolved question, and remaining budget. A useful agent knows when more action will not create new evidence.

Mock two tools: getInvoice(id) and getCustomer(id). Give the agent an invoice id that fails once, then requires a customer lookup. Log each thought summary, action name, arguments, observation code, and stop reason.

Pass when the trace shows no duplicate useless call, produces a final answer only after evidence arrives, and stops with needs-human when both tools fail. The exercise is small, but it exposes the control surface every production agent needs.