The Tool Call That Was Never Read

A customer-support agent built to answer queries like flight status by calling backend tools got stuck calling the same tool over and over, never processing what the tool actually returned and never producing an answer for the customer waiting on the other end.

The tool itself was failing or timing out (considered and ruled out; the report describes the tool as returning output normally) the agent's own handling of that output was the point of failure, not the tool's response.

A single retry after an unclear result, considered and ruled out; the loop was repeated and sustained, not a one-time retry that then resolved or gave up.

Perseveration, most consistent with the evidence: the agent's control flow had no check for "did I already get and use this result," so it kept re-invoking the same tool indefinitely rather than moving to the next step or surfacing an error.

For a customer-support agent, this failure mode is invisible to the person waiting for an answer until the silence becomes obvious, no error, just nothing happening. Any agent loop that calls tools needs an explicit, low iteration cap and a fallback path (hand off to a human, return a partial answer) rather than trusting the loop to naturally terminate.

Add a low iteration cap and a fallback path, such as handing off to a human or returning a partial answer.

Iteration limits; timeout fallbacks; monitoring of unanswered requests.