[EAAPL-WRK001] ReAct Agent Loop

Category: Agentic Workflows
Sub-category: Iterative Reasoning Architecture
Version: 1.1
Maturity: Proven
Tags: react, reason-act-observe, iterative-execution, tool-calling, execution-evidence
Regulatory Relevance: EU AI Act (transparency and logging), ISO 42001, NIST AI RMF

1. Executive Summary

The ReAct (Reason + Act + Observe) Agent Loop Pattern defines an iterative execution architecture in which an AI agent evaluates the current task state, selects an action, observes the result, and repeats until it can return an answer or a guardrail stops execution. The pattern is useful when the next tool call depends on information returned by an earlier tool call.

For enterprise use, ReAct should be governed through observable execution evidence: task inputs, model and prompt versions, selected tools, validated tool arguments, policy decisions, approvals, tool results, output metadata, exceptions, timestamps, costs, and termination state. Private or hidden model chain-of-thought is not an audit artefact and should not be required, exposed, or retained as compliance evidence.

The key operational risks are excessive agency, prompt injection through tool observations, unbounded iterations, cost growth, and weak reconstruction of what the system actually did.

2. Problem Statement

Business Problem

Complex enterprise tasks often require several information-gathering or action steps. A regulatory query, investigation, or operational workflow may need to retrieve one fact, use it to choose the next source, apply a policy gate, and only then produce an answer or action.

Technical Problem

A single inference call cannot reliably adapt its execution path to intermediate results. A governed ReAct implementation needs a loop that can choose an allowed action, validate it, execute it, record the observable outcome, and decide whether to continue.

Symptoms of Absence

• The agent commits to a fixed tool sequence even when intermediate results should change the path.
• Tool failures cannot be recovered from without restarting the task.
• Actions occur without consistent permission, approval, or cost gates.
• Operators cannot reconstruct which tools were invoked, what data was returned, or why execution stopped.

Cost of Inaction

• Accuracy risk: multi-step tasks can produce unsupported conclusions when intermediate facts are missing.
• Control risk: autonomous tool use can exceed the intended authority boundary.
• Operational risk: runaway loops can create cost, latency, and availability problems.
• Assurance risk: missing execution records make incidents and material decisions difficult to reconstruct.

3. Context

When to Apply

• Each step can change which tool or source should be used next.
• The complete execution path is not known at task start.
• Tool failures need an alternative or retry path.
• The organisation needs a reconstructable record of material actions and control decisions.

When NOT to Apply

• The task is single-step and fully answerable from current context.
• The workflow is deterministic and known in advance; use Sequential Chain (EAAPL-WRK002).
• Hard real-time latency requirements are incompatible with multiple model/tool round trips.
• The task grants side-effecting tools but no approval, permission, or rollback boundary exists.

Prerequisites

• EAAPL-AGT001 (Single Agent Pattern).
• EAAPL-AGT003 (Agent Tool Registry).
• Explicit allow-list of tools and permissions.
• Iteration and cost ceilings.
• Structured execution-event schema for observable evidence.
• Human approval gate for material or irreversible actions.

4. Architecture Overview

A production ReAct loop should separate internal model reasoning from external control evidence.

Decide

The model receives the task state and determines the next allowed action or that the task is complete. Implementations may use internal reasoning, but governance must not depend on capturing hidden chain-of-thought. Where an explanation is required, request a concise, user-visible decision rationale or structured reason code separately from private reasoning.

Validate

Before any action executes, validate the tool name, arguments, caller identity, agent identity, permission scope, policy constraints, data classification, and whether human approval is required.

Act

Invoke the authorised tool through the Tool Registry. Side-effecting operations should use idempotency keys, bounded credentials, and approval gates where applicable.

Observe

Return the tool result to the loop as untrusted data. Preserve the operational result needed for evidence, but minimise or redact sensitive payloads before durable storage.

Guard

Before the next iteration, enforce iteration count, token/cost budget, elapsed-time limit, repeated-action detection, and policy state. Stop on completion, guardrail breach, or explicit escalation.

Record

Persist an execution event for each material step. The record should capture what entered and left the governed boundary, not private chain-of-thought.

5. Architecture Diagram

6. Components

7. Observable Evidence Model

A governed implementation should record the minimum evidence needed to reconstruct the execution path.

Do not use hidden chain-of-thought, private scratchpads, or model-internal reasoning tokens as the audit trail. If a reviewer needs an explanation, generate a bounded explanation from the observable state and evidence available to the system.

8. Data Flow

1. Caller submits a task with context, allowed capabilities, and execution limits.
2. The model selects a structured next action or completion state.
3. The action is validated against the Tool Registry and policy boundary.
4. Any required human approval is obtained before execution.
5. The tool executes and returns an observation.
6. The evidence recorder stores the material request, policy outcome, action and result metadata.
7. The iteration guard checks limits, repeated actions, elapsed time and cost.
8. The loop continues, stops, or escalates.
9. The final output is validated and the execution is closed with a terminal evidence record.

Error Flow

9. Security Considerations

Prompt Injection Through Observations

Tool results are untrusted input. Retrieved documents, web pages, tickets, code, and API responses can contain instructions intended to redirect the agent.

Mitigations:

• Mark tool observations as untrusted data and keep system/policy instructions in a separate trust boundary.
• Apply input classification and prompt-injection controls before observations reach the model.
• Re-validate every tool request after the model sees an observation.
• Enforce least privilege and side-effect approvals independently of model output.

Excessive Agency

• Use per-agent tool allow-lists.
• Default tools to read-only where practical.
• Gate irreversible or material actions with human approval.
• Use bounded credentials and short-lived tokens.

Denial of Service / Cost Exhaustion

• Hard iteration limit.
• Per-task cost/token ceiling.
• Wall-clock deadline.
• Repeated-action detection.
• Circuit breaker for failing tools.

Sensitive Data

• Do not persist raw tool payloads when evidence references or hashes are sufficient.
• Redact secrets and regulated data from logs.
• Apply retention by evidence class rather than retaining all working context.

10. Governance Considerations

Execution Evidence, Not Hidden Reasoning

The governance objective is to make material system behaviour reconstructable. Evidence should show the inputs, authorities, controls, actions, approvals, results and final output that crossed the system boundary. It should not depend on access to private model reasoning.

Governance Artefacts

Retention periods must be derived from the organisation's actual legal, regulatory and records-management obligations. Do not assume a universal seven-year requirement.

11. Operational Considerations

Suggested SLOs

Monitoring

• Iteration distribution by task class.
• Tool error and timeout rates.
• Approval wait time and denial rate.
• Cost and token usage per completed task.
• Repeated action signatures.
• Evidence-record completeness.

12. Cost Considerations

The loop adds at least one model interaction per iteration plus any external tool cost. Control cost by:

• setting task-class-specific iteration ceilings;
• caching safe idempotent tool results within a task;
• routing simple decisions to smaller models where quality permits;
• stopping early when the evidence needed for a valid answer is already available;
• alerting on abnormal iteration or tool-cost growth.

13. Trade-Off Analysis

Key tension: more autonomy increases adaptability but also increases the amount of policy enforcement and evidence required at each action boundary.

14. Failure Modes

15. Regulatory and Assurance Position

ReAct can support transparency, logging, human oversight, operational resilience, and risk-management obligations when those obligations apply and the implementation provides the required controls and evidence. The pattern itself does not create compliance.

• EU AI Act: use execution logs, instructions for use, human-oversight controls, and other required technical/organisational measures as applicable to the system's classification. Do not treat chain-of-thought as a statutory transparency requirement.
• ISO/IEC 42001: use the loop's policy, monitoring and evidence controls as part of the organisation's AI management system where relevant.
• NIST AI RMF: map tool authority, monitoring, risk limits and incident evidence to the organisation's Govern/Map/Measure/Manage practices.
• Australian regulated environments: map evidence and operational controls to the specific obligations that apply to the entity and use case; do not infer compliance from the existence of a ReAct trace.

16. Reference Implementations

AWS

Azure

Portable / On-Premises

17. Related Patterns

18. Maturity Assessment

Overall Maturity: Proven

19. Revision History