9 — ReAct Framework (Reasoning + Acting)

Concept overview

ReAct combines reasoning about a task with actions that obtain observations from external tools. Architecturally, the useful property is feedback: the next action can respond to actual evidence instead of assuming every required fact in advance. The runtime should expose structured action proposals and observations, not depend on storing or revealing private chain-of-thought.

The model selects among permitted actions, while application code validates arguments, enforces permissions, and decides whether another iteration is allowed. Observations remain untrusted data. A web page or tool response cannot grant new authority merely because it appears inside the model's context.

Why it matters in production

Proof of concept

A prototype can alternate one model call and one read-only tool until a final response appears. Use a strict iteration ceiling from the beginning.

Production

Production adds action schemas, observation size limits, duplicate-action detection, deadline propagation, and evidence-based completion checks. Tool failures must be represented explicitly rather than disguised as empty successful results.

Enterprise scale

At scale, monitor tool-selection accuracy, repeated observations, per-task token growth, and endpoint saturation. A flexible loop can hide inefficient search behavior unless evaluation examines the whole trajectory.

Architecture components

Action proposer

Selects a permitted next operation or proposes task completion from available observations.

Tool gateway

Validates action identity, argument schema, authorization, and execution limits.

Observation store

Records normalized results, errors, freshness, and evidence references.

Loop controller

Tracks iterations, elapsed time, repeated actions, and remaining budget.

Final validator

Checks that the answer addresses the request and is supported by retrieved evidence.

The architecture, mapped

flowchart TD
 T["Bounded diagnostic task"] --> A["Action proposal"]
 A --> G["Tool policy gateway"]
 G --> M["Metrics or inventory tool"]
 M --> O["Normalized observation"]
 O --> B["Progress and budget check"]
 B --> A
 B --> V["Evidence validation"]
 V --> R["Supported diagnosis"]
 B --> H["Partial result or escalation"]

Runtime flow

1. 1

   Initialize bounds

   Load task scope, permitted tools, deadline, and maximum observation and iteration budgets.

2. 2

   Propose action

   Request a structured action selection based on the current evidence and unresolved requirements.

3. 3

   Authorize execution

   Validate the chosen tool and arguments using application policy before invoking it.

4. 4

   Normalize observation

   Record the actual result or classified error with provenance and bounded content size.

5. 5

   Evaluate progress

   Detect repeated actions, missing information, and diminishing evidence gains before another iteration.

6. 6

   Finish safely

   Validate the proposed final answer or return an explicit partial result when limits are reached.

Investigating intermittent packet loss

Telecommunications · Illustrative enterprise scenario, not a reported customer outcome.

Business situation

A network operations team receives a complaint affecting several customer sites without a known common cause.

The problem

A fixed checklist retrieves excessive telemetry, while a single prompt lacks the evidence needed to distinguish access and backbone problems.

Agent requirement

The assistant must choose targeted diagnostic reads and assemble a supported hypothesis without changing network configuration.

Architecture

A ReAct controller exposes topology, interface counters, incident history, and recent-change tools through a read-only gateway.

Runtime

• The first topology observation identifies a shared aggregation node; the next action retrieves counters only for relevant interfaces.
• A recent-change record explains the timing, and the final response links the hypothesis to counters and the change identifier.

Failure scenario

If telemetry is unavailable, the agent records the missing evidence and stops with a qualified assessment instead of inventing interface values.

Operational impact

Track diagnostic evidence coverage, repeated calls, time to useful hypothesis, and unsupported conclusions against analyst-reviewed cases.

Architecture tradeoffs

Failure scenarios & recovery

Common architecture mistakes

Logging private reasoning as an audit trail

Record actions, evidence, decisions, and policy results instead.

Allowing unrestricted tool names

Resolve calls against an explicit capability registry.

Assuming final-answer text proves completion

Validate required evidence and unresolved conditions.

When to choose this pattern

Choose it when

• The next useful read depends on previous observations.
• Tasks involve uncertain but bounded investigation paths.
• Tool results provide independently checkable evidence.

Avoid it when

• A deterministic workflow already covers all valid paths.
• External actions cannot be safely bounded or validated.
• The latency budget permits only one inference step.

Architecture checklist

• Set iteration, deadline, and token ceilings.
• Validate every action against allowed tools.
• Normalize tool errors as explicit observations.
• Detect repeated action fingerprints.
• Limit observation size and preserve provenance.
• Evaluate complete trajectories on representative cases.

Related concepts

• 8 — Plan-and-Execute Pattern
• 11 — Tool Invocation & Function Calling
• 24 — Prompt Injection Mitigation
• 43 — Self-Correction Loops
• 46 — Max Iterations Fallback

Primary references

• ReAct: Synergizing Reasoning and Acting in Language Models
• OWASP: LLM prompt injection prevention