## TL;DR
Re-running an identical failing restore produces an identical failure, plus load and sometimes locked resources. Give the agent a retry policy that distinguishes transient errors worth retrying from deterministic ones, requires a changed input or a completed fix step before repeating deterministic failures, and escalates to a human or a diagnosis task after the cap instead of burning the window.

```text
agent loop detected: re-running a failed restore without changing inputs
```

## Use this when
- Agent logs show the same restore attempted repeatedly with the same error.
- Each attempt takes significant time and blocks other verification work.
- No diagnostic step happens between attempts.

## Not for this skill when
- Retries with backoff succeed on transient network errors. That is healthy retry behaviour.
- A restore is repeated deliberately after an operator fixes storage. Changed input, intended.

## Steps
1. Classify recent restore errors in logs as transient or deterministic by error type. Verify: each repeated failure is classified
2. Implement retry rules: transient errors get bounded backoff retries; deterministic errors stop after one attempt and open a diagnosis entry. Verify: a simulated deterministic failure stops after one run
3. Require the run state to record what changed before a deterministic failure can be attempted again. Verify: an unchanged retry request is refused by the agent
4. Route capped failures to the alerting path with full context. Verify: an escalation is created in a test
5. Run the verification suite with a seeded bad snapshot. Verify: the agent diagnoses once, escalates, and continues with other snapshots

## Variant phrasings
### agent retry deterministic failure no change loop
The policy phrasing.
### failed restore repeated identical attempts stop
The symptom variant.
### retry policy transient vs deterministic errors agent
The classification wording.

Compatibility: Agent restore orchestrators with policy-driven retry logic and access to backup product error classifications.

## Why it happens
Naive retry logic treats every failure as weather: wait and try again. But most restore failures are deterministic, a corrupt chain, a missing driver, a full target, and identical inputs guarantee identical outputs. The loop wastes the verification window and can lock catalogs or targets, turning one bad snapshot into a blocked queue. Classification and change-gating are the fix.

## Edge cases / pitfalls
- Some errors are transient only sometimes, such as timeouts under load. Cap their retries too and record load context.
- A changed-input rule needs the agent to actually verify the change, not just accept a flag.
- Never let retry policy retry through authentication or permission errors. Those need humans.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_s5GZFrUxNerjDVRbRjMSKA