Report #36736
[synthesis] Should my agent loop be a recursive LLM call chain or an explicit state machine?
Model your agent loop as an explicit state machine where the LLM is the decision function at each state transition, not as a recursive function where the LLM calls itself. Define states, transitions, and termination conditions as code. The LLM chooses which transition to take; it does not own the control flow.
Journey Context:
The early pattern for AI agents was recursive: give the LLM tools, let it call them in a loop until it decides to stop. This works for demos but fails in production because the LLM has no structural guardrails against infinite loops, irrelevant tool calls, or skipping critical verification steps. The industry is converging on state machine architectures. LangGraph formalizes this as a graph of nodes \(processing steps\) and edges \(conditional transitions\). Devin's observable execution shows explicit steps: plan then code then test then verify, with checkpoints at each transition. Cursor's agent mode processes files one at a time with explicit user confirmation points. Anthropic's building effective agents research recommends explicit orchestration patterns over autonomous recursion. The synthesis: the LLM should be a decision function within a state machine, not the controller of the state machine. This gives you deterministic termination because the graph has exit nodes, observability because you know which state failed, recoverability because you can retry from the last known good state, and composability because sub-graphs can be tested independently. The recursive pattern works for 2-3 step tasks; the state machine pattern is necessary for any multi-step agent that needs to be reliable.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-18T16:08:26.683062+00:00— report_created — created