Stop Repeated AI Agent Tool Calls

An agent can repeat tool calls when it never receives a clear success signal, keeps retrying a permanent error, or cycles between steps without changing state. Raising its step limit can make that failure more expensive. Inspect the repeated state before increasing the budget.

Find the repeating pattern

Capture a sanitized sequence of step number, tool name, normalized arguments, result category and next decision. Full private tool responses are usually unnecessary for identifying a loop.

LangGraph's recursion-limit documentation distinguishes accidental cycles from legitimate long workflows. A limit error tells you the graph did not reach its stopping condition within the allowed steps; it does not identify the cause automatically.

Compare the first repeated pair of calls. Did the inputs change? Did the result contain new evidence? Did the application update the state the model sees?

Classify the loop

Pattern	Likely repair
Same read, same result	Cache within the task or require new evidence
Same permanent permission error	Stop and explain missing access
Search alternates between two phrases	Limit reformulation and report uncertainty
Tool succeeded but agent retries	Return an explicit completion state
Write times out	Reconcile outcome before retrying

Treat retries of writes separately from repeated reads. A timeout may occur after the external action completed.

Define progress outside prose

For a support lookup, progress might mean a new relevant source. For a code task, it might mean a test result changed or a specific file was updated. “The agent says it is getting closer” is not an observable completion criterion.

Suggested policy, with illustrative limits: allow two reformulations of the same unresolved query, then stop with the evidence collected. Those numbers are design choices, not universal defaults. Tune them using actual successful and failed tasks.

Enforce a maximum number of steps, elapsed time and estimated spend in application code. Model instructions can explain those limits, but should not be their sole enforcement.

Make stopping useful

Return what was completed, what remains uncertain and what input would unblock the task. A bounded partial result is more useful than an unexplained limit exception.

Preserve the action ledger so a resumed task does not repeat completed side effects. For external writes, use the provider's idempotency or reconciliation mechanism where available.

Verify the repair

Replay the failure fixture and a legitimate multi-step task. Confirm that the loop stops while the legitimate task still completes. Record cost and steps from actual logs rather than forecasting a percentage saving.

The AI agent explainer describes orchestration. Add the failure fixture to prompt regression testing before changing models or tool descriptions again.

Related troubleshooting

• API Timeout: Is It Safe to Retry?
• Scheduled Job Ran Twice: Prevent Duplicate Work

This guide draws on the linked documentation. Examples are illustrative unless explicitly identified as measured results.