Agent Plan Patching Prompt for Loop Detection

This prompt is a runtime recovery tool for agent orchestrators that have already identified a repetitive execution pattern. It is not a planning prompt; it is a surgical patching prompt. The target user is an agent runtime developer or platform engineer who has instrumented a loop-detection module—typically a state machine observer that tracks step history, tool-call signatures, and state transitions. When that module fires a loop-detected event, this prompt is the next step in the recovery pipeline. The prompt expects structured input describing the stuck agent's current plan, the detected cycle, and the execution trace leading up to the loop. Its job is to produce a minimal, verifiable plan patch that breaks the cycle through step reordering, constraint addition, or escalation.

Invoke this prompt when the agent has repeated the same tool call with identical or semantically equivalent arguments three or more times, cycled through a set of steps without advancing the completion state, or revisited a previously completed step as if it were still pending. The loop must be a planning or execution-logic failure, not an environmental one. Before calling this prompt, your detection module should classify the loop type: exact repetition (same tool, same arguments), semantic repetition (different arguments, same intent, no progress), or state oscillation (flipping between two or more steps). This classification must be included in the prompt's [LOOP_CLASSIFICATION] input. The prompt also requires the agent's current plan object, the last N execution steps, and any active constraints such as budget, time, or permission boundaries.

Do not use this prompt for initial plan generation, single-step error recovery, or cases where the loop is caused by an external system outage that requires an operational fix rather than a planning intervention. If the agent is stuck because an API is returning 503s, a database is down, or a credential has expired, use the Agent Plan Patching Prompt for Tool Failure or the Agent Plan Patching Prompt for Authentication Expiry instead. Similarly, if the loop is caused by a hallucinated tool schema or fabricated output from a prior step, route to the Agent Plan Patching Prompt for Model Hallucination Detection. Misrouting a systemic infrastructure failure into a planning patch will produce a patch that looks correct but fails identically on re-execution. Always verify that the root cause is a planning or reasoning defect before invoking this prompt.

This template is designed to be injected into your agent's control loop the moment a loop detector fires. Its job is to produce a minimal, actionable patch that breaks the cycle—not to re-plan the entire mission. The prompt forces the model to classify the loop's root cause before proposing a fix, which makes the output auditable and prevents superficial patches that just reorder the same failing steps. You should call this prompt with the frozen execution trace, the current plan, and the loop signature as inputs.

textCopy
SYSTEM: You are an agent plan patching specialist. Your only job is to analyze a detected execution loop and produce a minimal patch that breaks the cycle. You do not re-execute steps. You do not change the overall goal. You output a structured patch or a safe escalation.

USER:
# LOOP DETECTION REPORT
- Loop Signature: [LOOP_SIGNATURE]
- Repetition Count: [REPETITION_COUNT]
- Steps Involved: [LOOP_STEP_IDS]
- Time in Loop: [LOOP_DURATION]

# CURRENT PLAN STATE
[PLAN_STATE]

# EXECUTION TRACE (last [TRACE_WINDOW] steps)
[EXECUTION_TRACE]

# CONSTRAINTS
- Max Patch Steps: [MAX_PATCH_STEPS]
- Allowed Tools: [ALLOWED_TOOLS]
- Budget Remaining: [BUDGET_REMAINING]
- Deadline: [DEADLINE]
- Risk Level: [RISK_LEVEL]

# INSTRUCTIONS
1. Classify the loop root cause as exactly one of: [LOOP_CLASSIFICATION_OPTIONS]
2. If the loop is unrecoverable with available tools, output an escalation.
3. Otherwise, output a patch with these fields:
   - `patch_id`: string
   - `loop_root_cause`: string (from classification)
   - `patch_strategy`: string (one of: reorder_steps, add_constraint, substitute_step, insert_validation, reduce_scope, escalate)
   - `steps_to_remove`: [list of step IDs to drop from the current plan]
   - `steps_to_insert`: [list of new step objects with id, description, tool, and arguments]
   - `steps_to_modify`: [list of step ID and field-override pairs]
   - `termination_guarantee`: string (explain why this patch prevents the same loop from recurring)
   - `confidence`: number (0.0 to 1.0)
4. If confidence is below [CONFIDENCE_THRESHOLD], default to escalation.
5. Do not invent tools. Only use tools in the allowed list.
6. The patch must not exceed [MAX_PATCH_STEPS] total insertions and modifications.

# OUTPUT SCHEMA
[OUTPUT_SCHEMA]

To adapt this template, replace every square-bracket placeholder at runtime before the model call. [LOOP_SIGNATURE] should be a compact hash or description of the repeating pattern your detector identified—such as "steps 3-4-5 repeated 4 times with identical arguments." [PLAN_STATE] must include the full current plan with step statuses, not just the looping segment, so the model can assess downstream impact. [LOOP_CLASSIFICATION_OPTIONS] should be a domain-specific enum you define once per agent deployment; examples include identical_args_loop, oscillating_state_loop, tool_rejection_loop, empty_result_loop, and constraint_impossible_loop. The [OUTPUT_SCHEMA] placeholder should be replaced with your application's expected JSON schema, which your validator will check before the patch is applied. If your agent operates in a regulated domain, set [RISK_LEVEL] to high and ensure a human reviews any patch with confidence below 0.85 before execution resumes.

The loop-detection patching prompt is a recovery component, not a primary planner. It should be wired into the agent's execution loop as a monitor that fires when a repetitive pattern is detected. The harness must classify the loop type before calling the prompt, because the prompt's effectiveness depends on receiving accurate loop metadata—step sequence, repetition count, tool signatures, and state deltas. Do not invoke this prompt on every step; instead, trigger it from a loop detector that tracks step hashes, tool-call fingerprints, or state-action pairs over a sliding window. The detector should fire when it observes N consecutive cycles with no forward progress, where N is tuned to your latency tolerance and cost budget.

The implementation flow: (1) The loop detector identifies a candidate loop and captures the last K steps with their inputs, outputs, and tool signatures. (2) The harness populates the prompt template with [LOOP_PATTERN], [AGENT_STATE], [PLAN_CONTEXT], and [CONSTRAINTS]. (3) The model returns a structured patch—typically a JSON object with patch_type (reorder, insert_constraint, escalate, abort_branch), affected_steps, new_steps, and termination_guarantee (a boolean or confidence score). (4) Before applying the patch, the harness runs validation checks: verify that the patch references only existing step IDs, that any new steps use available tools from [TOOL_SCHEMA], that the patch does not reintroduce the detected loop pattern, and that termination_guarantee is asserted. If validation fails, the harness should retry once with the validation errors appended to [CONSTRAINTS]. If the retry also fails, escalate to a human operator or fall back to a safe abort.

For production deployments, log every loop-detection event with the loop fingerprint, the generated patch, validation results, and whether the patch resolved the loop. This data feeds eval regression tests: periodically replay historical loop traces against prompt updates to verify that patch quality does not degrade. Set a hard limit on patch attempts per execution session—if the agent applies more than M patches without reaching a termination state, force an abort and human review. Avoid the trap of letting the patching prompt itself become a loop source; the harness should track patch application as a distinct step type and include it in the loop detector's window to catch recursive patching failures.