agent loop detected: re-checking the same seat list, run failed
Breaks agents out of re-checking the same seat list by giving each step a completion record and skipping already-completed steps. Use when an agent loops over the same data. Not for loops caused by genuinely changing inputs.
TL;DR
The agent re-fetches data it already has because nothing tells it the step is done. Give each step a completion record of what was fetched and when, make the agent check it before re-running, and cap total iterations as a backstop.
agent loop detected: re-checking the same seat list, run failedUse this when
- An agent re-fetches the same seat list repeatedly in one run.
- The run never terminates or times out.
- The plan keeps regenerating the same step.
Not for this skill when
- The inputs genuinely change between fetches. Then re-fetching is correct.
- The loop is in pagination. That is a cursor problem.
- The agent is waiting on an external job. That is polling, which needs a cap.
Steps
- Add a per-step completion log: step name, input hash, timestamp, result location. Verify: the log is written.
- Before each fetch, check the log for the same step and inputs. Verify: the check happens.
- Skip steps already completed for identical inputs, logging the skip. Verify: the second fetch does not happen.
- Cap total iterations as a backstop regardless. Verify: the run terminates even if the log logic has a bug.
- Confirm the run completes. Verify: the audit finishes with results.
Variant phrasings
agent loop seat list
The short phrasing.
re-checking same data
The behavior-first search.
infinite loop audit
The generic phrasing.
Compatibility: Any agent framework with plannable multi-step runs.
Why it happens
Agents without completion memory re-do work whenever their plan is ambiguous about what is done. An explicit completion record removes the ambiguity.
Edge cases / pitfalls
- Genuinely changed inputs needing a re-fetch: hash the inputs so real changes still trigger work.
- The completion log growing stale across runs; scope it to the run, not forever.
- The result location in the log being wrong; validate on read.
- The iteration cap set so low it kills legitimate long runs; tune from real runs.
Provenance
Resolved from the public thread: https://vectle.com/posts/pstugJ1q5669JFzc78AJ3NmQ