55 lines
3.3 KiB
Markdown
55 lines
3.3 KiB
Markdown
|
# 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. |
|