# The ReAct Loop: How Every AI Agent Actually Works

## Metadata

| Field | Value |
|---|---|
| Institute | Molodetz Institute — Research & Retrieval Division |
| Subject | agentic-tool-loop-design |
| Document type | Source Dossier |
| Tier | 1 |
| Source title | The ReAct Loop: How Every AI Agent Actually Works |
| Source URL | https://dev.to/internals_decoded/the-react-loop-how-every-ai-agent-actually-works-3jgg |
| Source publisher / author | Internals Decoded |
| Source type | blog post |
| Source date (published) | 2026-10-05 |
| Date researched | 2026-10-11 |
| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
| Research method | both |
| Confidence | Medium |
| Status | Active |

## Summary

A conversational explainer of the ReAct (Thought/Action/Observation) loop as the universal agent pattern: the model reasons, emits a structured tool call the runtime executes, reads the observation back, and repeats until it can ground a final answer. It covers iteration budgets (2-3 for simple tasks, 10-15 for complex, hard cap required), tool failure as just another observation, loop/stuck detection via action hashing, and context-window defenses (sliding window, truncation, chunked sub-loops).

## Key findings

- The loop has four phases: Thought (internal reasoning), Action (structured tool call executed by the runtime, not the model), Observation (tool output fed back verbatim), Final Answer (produced once observations support it).
- Every production ReAct agent sets a hard `max_iterations` limit; hitting the cap must yield a partial answer or escalate to a human. Typical cap 20-30 depending on task.
- Stuck-loop handling beyond the cap: hash recent actions, break on N repeats, and insert a "stuck detector" observation telling the model it repeated itself and should try a different approach or output what it has.
- Tool failure becomes an observation: wrap every tool in an error handler that formats failures with enough context for the model to retry, fall back, or conclude gracefully; a generic "ERROR" string is useless.
- Context defenses: sliding window with summarization of older turns, observation truncation, and restructuring big tasks into chunked sub-loops with external intermediate storage.
- Each iteration costs a full LLM invocation plus tool time, so latency scales roughly linearly with iteration count.

## Pros / strengths

- Clear phase vocabulary (Thought/Action/Observation/Final Answer) that maps 1:1 onto harness code.
- The stuck-detector-as-observation pattern and failure-as-observation rule are directly implementable.

## Cons / limitations / caveats

- Popular explainer, not a primary source; cites the original ReAct paper (arXiv 2210.03629) without adding new evidence.
- Iteration-count guidance is folk wisdom ("typical values"), not measured.

## Relevance to tai

- Tai's `run_turn` plus its loop-nudge/stall/stop machinery is already this pattern almost verbatim (action hashing via `action_signature`, loop warning injection at 3 repeats, stop at 5, total step cap, compaction); the article validates keeping that shape.
- The failure-as-observation rule supports tai's error-as-tool-result convention and argues the narration fix must also live in the observation channel (a repair prompt), not in text scraping.

## Changelog

| Date | Change |
|---|---|
| 2026-10-11 | Initial dossier created. |