ReAct

ReAct combines reasoning and acting in an iterative problem-solving loop. An agent evaluates a task and the evidence available so far, selects an action, receives an observation from the environment, and decides whether to continue or provide a final answer. Actions commonly include searching documents, querying a database, running a calculation, or calling an application API. Observations are the actual results of those actions, not results invented by the model.

The central benefit is adaptive decomposition. Instead of generating an entire plan and assuming every step will succeed, the agent can revise its approach after each observation. For example, an incident investigation assistant might retrieve a failed deployment's metadata, inspect relevant error metrics, and then query configuration history only if the first results suggest a configuration change. Each tool result influences what happens next.

In cloud applications, the model usually proposes tool calls while application code or a managed agent runtime executes them. The tool interface should define the operation, input schema, output structure, and expected error responses. The execution layer validates arguments, checks authorization, invokes the tool, and returns a structured observation. A model-generated request is a proposal, not permission to perform an operation.

AWS Step Functions can implement this loop as an explicit workflow. A Task state invokes a foundation model through Amazon Bedrock or application code. A Choice state routes a structured response to tool execution, completion, or error handling. Another Task executes the selected operation, and the workflow adds its result to the interaction context before invoking the model again. The workflow must explicitly track iteration limits, remaining budget, and stopping conditions; Step Functions does not supply ReAct reasoning automatically.

For example, a support agent investigating an incorrect invoice could retrieve the invoice, query the applicable pricing agreement, and calculate the expected amount. If the agreement is missing, the next action should request clarification or escalate rather than invent a discount. Issuing a refund should be a separate, authorized operation with approval requirements and an idempotency key, because retries must not create duplicate financial transactions.

ReAct is related to, but not synonymous with, chain-of-thought reasoning. Chain-of-thought approaches involve intermediate reasoning, whereas ReAct specifically couples decision-making with actions and feedback from the environment. Traditional ReAct demonstrations show thought, action, and observation traces, but production implementations do not need to expose or store private model reasoning. Structured tool requests, observations, concise decision summaries, and final answers provide useful operational records without requiring disclosure of internal reasoning.

The trade-offs include additional model calls, tool latency, token consumption, and more failure paths than a fixed workflow. Agents can repeat unsuccessful actions, choose irrelevant tools, or follow malicious instructions embedded in retrieved content. Enforce maximum iterations, timeouts, bounded retries, least-privilege tool permissions, and approval gates for consequential operations. Treat tool output as untrusted data, not instructions that can override application policy.

ReAct does not guarantee factual correctness, optimal planning, or successful execution. Retrieval-augmented generation alone is not necessarily ReAct, and a single tool call does not establish an iterative reasoning-and-action loop. Prefer deterministic workflows when the required sequence is already known. Evaluate ReAct systems using task success, evidence quality, tool-selection accuracy, unauthorized-action attempts, latency, and cost rather than the apparent sophistication of their explanations.