Prompt to Stop an Agent From Looping

An agent tasked with fetching current stock prices encountered a rate-limited API. The API returned a 429 error. The agent tried again. Another 429. The agent tried again with a slightly different request. Another 429. Over the next four minutes, the agent made 312 API calls, each returning 429, each consumed roughly the same number of tokens in the thought-action cycle. The agent was eventually terminated from outside. It had never considered stopping.

Loop failures are one of the most expensive failure modes in agentic systems. They are expensive in API tokens, in wall-clock time, and in the downstream effects of repeated failed actions. A database query that fails due to a permission error and gets retried 50 times creates 50 log entries and may trigger rate limiting or alarm systems. An email agent that cannot find a recipient and keeps searching the contacts database may create session-state corruption.

The cause is structural: agents are optimized to complete tasks. Giving up feels like failure. Without an explicit instruction to stop under specific conditions, persistence is the default behavior.

Anatomy of a Loop

Loops in agentic systems take several forms. Understanding them helps in writing exit conditions that catch all of them.

The prompt below addresses hard retry loops and variation loops directly. Strategy oscillation and clarification loops require additional handling described in the variations section.

The Prompt

## RETRY AND LOOP CONTROL

Apply these rules to every tool call, action, or step in the current task:

### RETRY BUDGET
For any single action or tool call:
- Maximum retries: 3
- Count a retry as any repeated attempt to accomplish the same sub-goal by the same method, including attempts with minor parameter variations.
- After 3 failed attempts on the same sub-goal, do not attempt a 4th. Go to FAILURE PROTOCOL.

### DETECTING A LOOP
After each action, check:
1. Have I taken this exact action (or a variation with different parameters but the same goal) more than twice before?
2. Has my last action produced a meaningfully different result from the previous attempt?

If the answer to (1) is yes and the answer to (2) is no: you are in a loop. Stop immediately. Go to FAILURE PROTOCOL.

### FAILURE PROTOCOL
When you hit a retry limit or detect a loop:

1. Stop all action toward the failing sub-goal.
2. Report:
   - What you were trying to accomplish
   - What method(s) you tried
   - What error or unexpected result each attempt produced
   - What information, access, or capability would allow the task to be completed
3. Ask the user whether to:
   a) Provide the missing information or access
   b) Skip this step and continue with the rest of the task
   c) Abort the entire task
4. Do not proceed until you receive an answer.

### GLOBAL STEP LIMIT
If the total number of tool calls or actions in the current task exceeds [INSERT LIMIT — recommended: 20 for simple tasks, 50 for complex], stop and report progress to date before continuing. This prevents silent runaway tasks.

### TRANSIENT VERSUS PERSISTENT FAILURES
Transient failures (network timeouts, temporary rate limits with explicit Retry-After headers): retry once after the indicated wait time. If the failure persists after one retry, treat it as a persistent failure and apply the retry budget.

Persistent failures (permission errors, not-found errors, invalid parameter errors): do not retry. Apply the failure protocol immediately.

If you cannot determine whether a failure is transient or persistent, treat it as persistent.

Why Each Component Works

The retry budget

Three retries is the right number for most production agents. One retry catches transient failures. Three retries give enough attempts to rule out coincidence. Beyond three, you are no longer recovering from a fluke — you are grinding against a systematic problem. The exact number is adjustable but the principle is not: there must be a number.

The definition of "retry" is deliberately broad: any attempt at the same sub-goal by the same method, including parameter variations. This prevents the variation loop, where the agent tries the same approach with slightly different inputs each time, treating each variation as a fresh attempt.

The loop detection check

Asking the agent to check "has my last action produced a meaningfully different result" is more powerful than a simple step counter. It forces the model to evaluate whether it is making progress, not just whether it has stayed within a numerical limit.

This check runs after every action, not just after failures. An agent can loop even through nominally successful actions if it keeps reaching the same state. A search agent that keeps finding and discarding the same results is looping even if the searches technically return data.

The failure protocol

The failure protocol is designed to produce actionable output rather than a failure message. "I couldn't do it" is not useful. "I tried the following three approaches, each produced this error, and here is what I would need to complete the task" is useful.

The three-option escalation (provide info, skip step, abort task) prevents the agent from making autonomous decisions about how to handle a failure. The human decides whether to skip or abort, not the agent.

The global step limit

The per-action retry budget catches localized loops. The global step limit catches runaway tasks that do not loop on any single action but keep generating work indefinitely. Set this to a number appropriate for your task complexity. The limit forces a check-in, not an abort: the agent reports progress and asks whether to continue. This preserves long-running capability while preventing silent token burn.

Transient vs persistent failure distinction

This distinction matters because the right response to a network timeout (wait, retry once) is completely different from the right response to a 403 Forbidden (report, do not retry). Without this distinction, agents either retry permission errors indefinitely or give up immediately on retryable timeouts. The prompt establishes a clear rule: when in doubt, treat as persistent.

Variations for Specific Loop Types

The core prompt handles hard retries and variation loops. For strategy oscillation and clarification loops, add these supplements:

Strategy oscillation:

If you find yourself returning to an approach you already tried after trying alternatives, you are oscillating between strategies. Stop and apply the failure protocol. Do not continue alternating approaches without fresh information.

Clarification loops:

If you ask a clarifying question and the user's answer does not resolve the question, do not ask the same question again. Instead, restate the user's answer, explain why it did not resolve the ambiguity, and ask a more specific version of the question. If after two attempts the ambiguity is still not resolved, report it as a blocker and apply the failure protocol.

Common Mistakes

The most common mistake is not defining the retry limit explicitly enough. "Retry a reasonable number of times before giving up" is interpreted as an invitation to keep trying. "Retry no more than 3 times" is enforced as a rule.

The second mistake is only applying retry limits to failures. Agents can loop through successful but unproductive actions. The loop detection check applies to all actions, not just errored ones. An agent that successfully queries a database 40 times in a row and always gets empty results is looping, even though none of the queries failed.

A loop is not defined by errors. It is defined by the absence of meaningful progress. Teaching an agent to recognize "I am not making progress" is more powerful than teaching it to count failures.

The third mistake is a failure protocol that is too vague. "Report the failure and ask for help" can produce anything from a one-line error message to a 2000-word explanation. The specific format in the prompt — what you tried, what each attempt produced, what you need — ensures the output is usable.

For the complementary pattern on context tracking over long runs, see Prompt to Make an Agent Summarize Its Own Progress. For controlling hard limits on what an agent can do, see Prompt to Define What an Agent Must Never Do.