Runaway Tool Loop Detection and Termination Prompt

This prompt is designed for platform operators and reliability engineers who need an automated, model-driven circuit breaker for agent tool execution. It is not a replacement for hard limits in your orchestration layer—those should always be your first line of defense. Instead, this prompt acts as an intelligent last resort that analyzes execution traces to decide whether an agent is stuck in a non-progressing loop, making repeated identical calls, or burning budget without advancing state. Use it when you need a termination decision with auditable reason codes and a clear escalation path before a runaway loop exhausts your API budget or hits rate limits.

The ideal deployment point is inside a middleware or guard layer that intercepts tool call sequences before they reach the model for the next planning step. You should feed this prompt a rolling window of recent tool calls, their arguments, their outputs, and any state-change indicators. The prompt returns a structured decision: continue, warn, or terminate. For terminate decisions, it must produce a reason code (such as repeated_identical_calls, no_state_progress, or budget_exhaustion_risk) and a recommended escalation path. This gives your operations team an auditable record of why the agent was stopped, rather than a silent timeout or a cryptic rate-limit error from your API provider.

Do not use this prompt as your primary rate limiter or budget enforcer. Hard numeric caps on call count, token usage, and wall-clock time belong in your orchestration code, not in a model's judgment. This prompt is for the ambiguous cases where a loop is technically within limits but semantically stuck—for example, an agent that retries a failing API call with slightly different parameters 40 times, each attempt consuming tokens but never succeeding. Your hard limits might allow 50 calls, but this prompt can detect the futility pattern at call 12 and terminate early, saving budget and reducing latency for other tasks in the queue.

Before deploying, test this prompt against a library of known loop patterns: rapid successive identical calls, calls with rotating but equivalent arguments, calls that produce outputs indistinguishable from prior outputs, and calls that toggle between two states without converging. You will also need to tune the trace window size—too small and you miss the pattern, too large and you add latency and token cost to every evaluation. Start with a window of 10-15 recent calls and adjust based on your agent's typical task depth. Wire the termination decision into your observability stack so you can track false positives (legitimate exploration terminated early) and false negatives (loops that slipped through) and refine the prompt's sensitivity over time.

The following prompt template is designed to be injected into an agent's system instructions or used as a guardrail evaluation step between tool calls. It analyzes a provided execution trace—a sequence of recent tool calls, their arguments, and their results—and determines whether the agent is stuck in a non-productive loop. The output is a strict JSON decision object that your application harness can use to halt execution, escalate to a human, or switch to a fallback strategy. Use square-bracket placeholders to inject the specific trace, policy thresholds, and output schema before sending the request to the model.

textCopy
You are a runtime safety monitor for an autonomous agent. Your sole task is to analyze the provided agent execution trace and determine if a runaway tool loop is occurring. A runaway loop is defined as a sequence of tool calls that exhibits one or more of the following patterns without making meaningful progress toward the stated goal:
- Repeating the same tool call with identical or trivially different arguments more than [MAX_REPEATED_CALLS] times.
- Cycling through a set of tool calls (A -> B -> C -> A) without a change in external state.
- Making tool calls whose results do not alter the agent's subsequent actions or understanding.
- Exceeding [MAX_CONSECUTIVE_CALLS] total tool calls without a terminal action or user-facing output.

You will be given:
- [AGENT_GOAL]: The high-level objective the agent is trying to accomplish.
- [EXECUTION_TRACE]: A JSON array of the last [TRACE_WINDOW_SIZE] tool calls, each containing `tool_name`, `arguments`, `result_summary`, and `timestamp`.

Analyze the trace and return a single JSON object conforming to the [OUTPUT_SCHEMA].

[OUTPUT_SCHEMA]
{
  "termination_decision": "terminate" | "continue" | "escalate",
  "confidence": 0.0-1.0,
  "reason_code": "repeated_call" | "cyclical_loop" | "no_progress" | "call_limit_exceeded" | "healthy",
  "loop_pattern_identified": "string describing the detected loop, or null",
  "recommended_action": "A concise instruction for the harness, e.g., 'Stop execution and return the last valid state to the user.'"
}

[CONSTRAINTS]
- If `termination_decision` is "escalate", the `recommended_action` must include a clear summary of the loop for a human operator.
- Do not hallucinate tool calls or results not present in the [EXECUTION_TRACE].
- If the trace shows clear, non-repeating progress, the decision must be "continue" with reason_code "healthy".

To adapt this template, adjust the [MAX_REPEATED_CALLS] and [MAX_CONSECUTIVE_CALLS] thresholds to match your application's tolerance for latency and cost. For high-stakes financial or healthcare agents, set these thresholds low and prefer an escalate decision. The [TRACE_WINDOW_SIZE] should be large enough to capture a full loop cycle but small enough to fit within your context budget; a window of 20-30 calls is a practical starting point. The harness that processes this output should treat any confidence score below 0.85 for a terminate decision as a signal to log the trace for human review rather than automatically halting, preventing premature termination from a false positive.

This prompt is not a standalone safety net. It must be embedded inside the agent's execution loop as a pre-invocation guard that runs before every tool call after a configurable threshold (e.g., after 5 consecutive tool calls or 30 seconds of tool-only activity without a user-visible response). The harness should maintain a rolling window of recent tool calls—including tool name, arguments, timestamp, and whether the call produced a state change—and pass that window into the prompt's [TOOL_CALL_HISTORY] placeholder. Do not rely on the model's internal context window alone; the harness must own the ground-truth counter and pass it explicitly.

Validation and circuit-breaking happen in the application layer, not inside the model. Parse the model's JSON output and enforce these rules: if termination_decision is terminate but reason_code is missing or not from the allowed enum, treat it as continue and log a malformed-output incident. If the termination threshold is breached (e.g., 3 termination decisions within a single session), the harness must hard-stop all tool execution and escalate to a human operator via the configured [ESCALATION_CHANNEL]. Implement a cooldown window after any termination: block all tool calls for that session for a minimum period (e.g., 60 seconds) and surface the reason to the user. Log every termination decision with the full tool-call history, model response, and session ID for post-incident analysis.

Model choice matters. Use a fast, cheap model for this guard prompt (e.g., a small fine-tuned classifier or a low-latency API model) because it runs on every tool call after the threshold. The guard model does not need the full reasoning capability of the primary agent model; it needs consistent JSON output and low false-positive rates on the terminate decision. Test extensively against rapid successive calls with identical arguments (the most common runaway pattern), oscillating calls where the agent flips between two tools without progress, and legitimate long chains (e.g., paginated API calls) to calibrate the threshold. Track false-positive and false-negative rates in a dedicated eval set before raising the guard to production. Wire the guard's output into your observability stack so you can correlate termination events with user-reported failures and adjust the prompt's [LOOP_PATTERN_DEFINITIONS] over time.