Detecting Stuck Loops in AI Agents Before They Waste Budget

An AI agent is stuck in a loop when it repeats a step that has already failed, or a close variant of it, and nothing in the shared state changes between attempts. The earliest reliable signals are identical tool calls, the same error returning after each retry, and step counts that keep rising while completed work stays flat. Stopping the loop early takes a hard limit for each task, a progress check that compares state between attempts, and an escalation rule that hands the decision to a person instead of letting the agent try again.

Key takeaways

• A loop is repetition without progress, so detect it by comparing state between attempts, not by counting messages.
• Set step, time and retry limits before the first live run, not after the first incident.
• Any action that changes the outside world needs an idempotency key so a retry cannot send a second message or create a duplicate record.
• When the same failure repeats with unchanged state, pause the task and escalate with the evidence attached.
• Review loop events every week, since a loop that goes unexamined tends to return in a different form.

What a stuck loop looks like in practice

A stuck loop is rarely dramatic. The agent calls the same lookup with the same arguments, receives the same empty result, and rephrases its next message slightly before trying again. In other cases it alternates between two tools, such as editing a draft and then restoring the previous version, or it rereads the same document after every failed write. Each step looks reasonable on its own, and the failure only becomes visible when you compare step twenty with step five.

This is why the agent's own account is weak evidence. A model that is looping can describe each attempt as a fresh idea, and its confidence does not drop because it has failed three times. The check has to come from outside the model, in the logs and state that the tool layer records. The distinction matters for operations: a retry after a timeout is ordinary, while a fourth attempt at a validation error that has not changed points to a defect in the workflow. For a deeper treatment of stop rules, see AI agent stuck in a loop: stop conditions that actually work.

Which signals reveal a repeated failed step?

No single signal proves a loop. A slow tool or a long context can look similar to a stuck agent, so treat signals as a set and act when two or more point the same way. These are the ones worth watching first:

• The same tool is called with identical or near-identical arguments more than once in a row.
• An error code or message returns after each attempt and does not change.
• Shared state, such as a record status, a queue position or a draft version, stays the same across several steps.
• The step count rises while the number of completed sub-goals stays flat.
• The agent alternates between two actions that undo each other.
• Cost or tokens per attempt climb because each failed attempt is appended to the context.
• The output restates the previous attempt in different wording and adds no new fact.

The last signal is the hardest to see in a transcript. Two paragraphs can read differently and still describe the same failure. A simple similarity check on consecutive outputs catches much of this, but its result should prompt a review, not serve as a verdict.

Which limits stop the loop before it spends the budget?

Limits are the last line of defense, and they should exist even when detection works. Define them per task type rather than once for the whole agent. A useful set covers the maximum number of steps for one task, the maximum elapsed time, the maximum calls to any single tool, the maximum retries of any single action, and a spend ceiling expressed in the unit your team already tracks. Anthropic's guidance on building effective agents recommends stopping conditions such as a maximum number of iterations, which is a sound starting point. The FinOps Foundation's material on unit economics pushes the conversation toward cost per completed outcome rather than cost per message, and that framing makes the spend ceiling easier to set.

Limits work best when they fail closed. When one is hit, the task should stop in a known state, record the reason and wait for a person, rather than dropping the work silently or continuing on a fallback nobody approved. A loop that ends with a clear stop reason is an operational event you can review. A loop that ends because the budget ran out is a cost you have to explain afterward.

How do you build a progress check the agent cannot argue with?

The progress check is the most useful control because it does not depend on how the agent describes its work. Before a task starts, define the state fields that represent progress for that task type, such as a record status, a count of checked items or the last successfully written version. Then build the check in this order:

• List the state fields that prove progress for one task type, and mark which ones the agent can change.
• Capture a snapshot of those fields before the first step and after each step, stored outside the model's context.
• Fingerprint each tool call by tool name and normalized arguments, so repeats stay visible even when the wording varies.
• Define a stall rule, such as no state change across consecutive steps or the same fingerprint appearing twice, and record which rule fired.
• Route a fired rule to the stop path in the next section, so the agent does not decide for itself whether to continue.

Keep the rules simple enough that an operations lead can read them. A check that nobody can explain will be disabled the first time it fires on a legitimate task.

How do you stop duplicates from retries and side effects?

A loop becomes expensive when it touches the outside world. An agent that retries a lookup wastes compute. An agent that retries a confirmation email may send the customer three copies, and one that retries a credit may issue it three times. The fix is not a better prompt. It is to make side-effecting actions idempotent, so that the same intended action carries the same key and the receiving system treats repeats as a single operation. Stripe's documentation on idempotent requests shows the pattern: the client supplies a key, and the provider returns the original result for a repeated request instead of performing the action again.

Your own tool layer should follow the same principle even when the downstream system does not. Derive the key from the task identifier and the intended action, store it with the outcome, and reject any second execution with the same key. The retry policy then becomes easier to reason about. Read-only actions can be retried within a small limit, and keyed write actions can be retried safely because the duplicate is recognized. The full pattern is covered in idempotent AI agent actions and how to prevent double refunds.

When should the agent stop and hand off?

Detection without a clear next step only produces alerts that nobody reads. The following decision guide turns a fired rule into an action:

• If the same failure repeats with unchanged state, pause the task and open an escalation with the evidence.
• If the next step requires a permission the agent does not hold, stop and hand the decision to the named owner.
• If the loop involved money, customers or regulated records, freeze that action class for the agent until someone has reviewed it.
• If the cause is an external limit or outage, move the task to a queue or fallback path instead of retrying harder.
• If the loop reached a customer or left a partial change behind, run the incident steps before anything else.

The escalation should be short and useful. Send the decision that is needed, the state snapshot, the fingerprints of the repeated calls and what was already tried, not a transcript of dozens of attempts. Guidance on this is in human escalation for AI agents.

Illustrative scenario: an agent updates delivery addresses in an order system. The system rejects a postal code because of a space the agent added, so the agent retries with the same value, then with the space removed, then with the original value again. The progress check sees the order status unchanged across all attempts and finds the same fingerprint repeated. The stall rule pauses the task and opens an escalation containing the order identifier, the error text and the values tried. A staff member corrects the format in the source record, and the agent resumes from its last checkpoint rather than starting over. Without the rule, the same loop would have continued until a step or spend limit was reached, with every attempt logged as ordinary activity.

Be Human's managed approach handles this during the first role definition: the operations owner and Be Human agree on the state fields that prove progress, the stop conditions and the actions that require a person. These rules are implemented in the agent's tool layer rather than left to instructions in a prompt. In managed operations, loop events are reviewed in recurring evaluations and permission reviews, and any loop that reaches a customer follows a written incident response with stop and rollback steps defined in advance.

What should a loop record contain?

Every loop event should leave a record that a person can read without reconstructing the full transcript. The fields that matter most are the task identifier, the step, the tool name, the argument fingerprint, the error returned, the state snapshot, the budget used so far and the stop reason. This is the minimum needed to investigate a loop afterward, and it overlaps with what a good audit trail requires. The OpenTelemetry observability primer explains why traces, metrics and logs should share an identifier so that one task can be followed across all of them. Review loop events in the same weekly rhythm as the rest of the agent's operations, so repeated patterns show up as trends rather than surprises. Teams that already work from a weekly maintenance checklist for managed AI agents can add loop events as one standing item.

If you are not sure which of your workflows would benefit most from these controls, take the free Be Human AI diagnostic to find the first task worth handing to an agent.

Frequently asked questions

How many retries should an AI agent get before it stops? There is no universal number. Set the limit per action class, based on whether the action is read-only, whether it is idempotent and how costly a wrong repeat would be. Two identical failures with unchanged state is usually the point where the agent should stop and escalate.

Is a long task the same as a stuck loop? No. A long task makes progress, which shows up as changed state fields and completed sub-goals. A loop repeats work without changing anything that matters, so the progress check is what separates the two.

Can the model detect its own loop? Not reliably. A model can describe repeated attempts as new reasoning and show no drop in confidence. Detection should rely on logged tool calls, errors and state snapshots that the model cannot edit.

What should I log to investigate a loop afterward? Record the task identifier, step, tool name, argument fingerprint, error, state snapshot, budget used and stop reason. With those fields, a reviewer can see what was tried and why the task stopped without rereading the whole conversation.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.