Twenty Tries at the Same Query

A developer building a data-lookup agent reported that it entered a loop: it called the same database tool repeatedly with slightly varied phrasing after each attempt failed with the same underlying formatting error, never adjusting its approach to address the actual error, until it hit the system's built-in limit on consecutive tool calls and stopped. The same code had worked correctly in an earlier version of the framework.

A framework regression unrelated to the agent's own behaviour, a real contributing factor, since the same logic worked in a prior version. But the regression explains why the first call failed, not why the agent kept retrying an unproductive variation twenty times instead of surfacing the error.

Apraxia (understanding the tool's purpose but failing at the mechanics of calling it), considered. Each individual call was reasonably well-formed; the persistent problem wasn't in how any single call was made; it was in not stopping.

Perseveration (repeating a response after it has stopped being useful, without adjusting based on the specific error received), most consistent with the report: the agent read the error each time but generated a new query variation rather than diagnosing the actual, unchanging cause, and repeated this until an external limit (not its own judgment) stopped it.

This is a small, cheap version of a pattern that gets expensive fast at scale, repeated API calls, repeated charges, rate-limit exhaustion. The fix isn't a bigger retry limit; it's requiring the agent's retry logic to actually incorporate what the last error said before trying again, and to stop and surface the problem once the same error recurs rather than treating every retry as a fresh chance.

Make retry logic incorporate the last error, and stop and surface the problem when the same error recurs.

Repeated-error detection; per-tool call budgets; escalation to a human after identical failures.