Report #55959
[synthesis] Agent loop executes a long plan then applies all changes at once, with no intermediate validation or recovery
Structure the agent loop so that each tool call \(file read, search, edit, shell command\) is a state machine transition with validation. After each tool result, validate the output, check for errors, and decide whether to continue, retry, or replan. Tool calls are checkpoints, not fire-and-forget actions
Journey Context:
The naive agent pattern is: plan → execute all steps → apply changes. When step 3 of 10 fails \(file not found, edit didn't apply cleanly, test failed\), the entire chain is broken with no recovery path. Observable behavior of successful agents reveals a different architecture: Cursor's agent mode reads files one at a time, makes targeted edits, and checks results before proceeding. Aider's architecture sends each edit to the LLM as a separate turn with the result of the previous edit. Devin's demo shows it running commands and reading output before deciding next steps. The synthesis: these agents implement a state machine where each tool call is a transition with a guard condition. If \`read\_file\` returns empty, the agent doesn't proceed to \`edit\_file\`—it replans. If \`edit\_file\` fails to apply, it retries with more context. This is why streaming tool use is architecturally important: the orchestrator must see each tool result before deciding the next action. The practical pattern: implement your agent loop as a while-loop with explicit state, not a linear chain of tool calls. Each iteration: observe tool result → validate → decide next action. This adds latency per step but dramatically improves reliability, because the agent can self-correct before errors compound.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T00:25:19.202357+00:00— report_created — created