agent loop detected: failed patch deployment retried forever

TL;DR

An unbounded retry loop means the agent treats every failure as retryable and keeps no attempt budget. Add three things: classify failures as retryable (network, lock busy) versus terminal (access denied, package not found, disk full), cap attempts per host and patch (3 is a sane default) with exponential backoff and jitter, and write a dead-letter entry when the cap is hit so a human sees it in the wave report.

agent loop detected: failed patch deployment retried forever

Use this when

• Run logs show the same patch attempted on the same host far beyond any sane count.
• The target host shows load or lock contention from the agent retries.
• The wave never finishes because one host never succeeds.

Not for this skill when

• The agent retries a few times with backoff on a flaky link. That is correct behavior.
• The loop is in a human-driven script, not the agent wave. The fix pattern is similar but this skill is written for agent orchestration.

Steps

1. Freeze the wave for that host and inspect the last failure output to classify it. Verify: the failure is labeled retryable or terminal with evidence
2. Implement per-target attempt counting persisted in wave state (host plus patch as the key), not in agent memory. Verify: the counter survives an agent restart in a test
3. Add exponential backoff with jitter between attempts and a hard cap; on cap, mark the target dead-lettered with the last error. Verify: a test run against a failing target stops at the cap and logs the dead-letter entry
4. Exclude dead-lettered targets from further waves until a human clears them. Verify: the next wave plan skips the dead-lettered host and patch
5. Resume the wave for healthy targets. Verify: the wave completes and the report shows attempts, caps hit, and dead-letters explicitly

Variant phrasings

agent infinite retry loop patch deployment cap backoff

The fix-pattern phrasing.

dead letter queue failed patch targets agent

The reporting phrasing.

retryable vs terminal failure classification patching

The classification phrasing that prevents most loops.

Compatibility: Compatibility: Any agent framework driving patch tooling over SSH, WinRM, or a patch API; state store can be a file, database, or the wave tracker itself.

Why it happens

Agents loop forever when the retry decision is made from the last error text alone, with no memory of how many times this exact target already failed. Humans stop because they recognize repetition; an agent needs that recognition built in as persisted attempt state plus a failure taxonomy, because some errors (access denied, no such package) will never heal by retrying.

Edge cases / pitfalls

• Backoff without jitter synchronizes retries across a fleet and can thundering-herd a recovering service; always jitter.
• A cap that is too low (1) turns transient faults into manual work; 3 attempts over at least 15 minutes is a balanced default for patching.
• Log the classification reason, not just the count, or the dead-letter list becomes another opaque queue.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-wRfDJTxgSvC-WqLu53JDw