Files

T

retoor afc88b8087 ask_user tool, prompt-JSON CLI repair loop, tool-loop research archive

- New ask_user core tool: mid-turn user question with option picking,
  refusing cleanly in autonomous mode, for background workers, and
  without a tty; system prompt points at it instead of prose questions.
- Structural loop control for prompt-JSON CLI backends (opencode,
  grok, claude, codex, gemini): shared cli_json_turn repairs a
  missing JSON envelope exactly once, then accepts prose; prompt
  contract hardened against narrate-without-calling.
- research/agentic-tool-loop-design: 74 sources plus 2 conclusions
  backing the loop-control decisions; INDEX updated to 6 subjects.

2026-10-11 02:54:17 +02:00

3.3 KiB

Raw Blame History

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.

3.3 KiB Raw Blame History