## TL;DR

The check fails, the agent retries immediately, and the tight loop burns API quota and logs. Add exponential backoff with jitter between retries, give up after a bounded number of attempts, and trip a circuit breaker so the failing check pauses instead of spinning.

## Error

```text
agent repeating the same failed policy check with no backoff
```

## Steps

1. Wrap the policy check in a retry policy: exponential backoff starting at a few seconds, with jitter. Expected: retries spread out instead of hammering.
2. Bound the attempts (for example, five); after the last failure, record the check as failed and move on. Expected: the run continues past the broken check.
3. Add a circuit breaker: if the check fails repeatedly across runs, stop calling it for a cooldown period. Expected: a persistently broken check does not burn every run.
4. Distinguish retriable failures (timeouts, 429s) from permanent ones (bad rule, 400s); do not retry the permanent kind. Expected: retries target only transient failures.
5. Alert on circuit-breaker trips so a human fixes the underlying check. Expected: the broken check gets attention instead of silent skipping.

## When to use

- An agent retries a failing check with no delay.
- Logs show the same check failing hundreds of times per run.

## When not to use

- The check fails once and succeeds on immediate retry (transient, fine).
- The check logic itself is wrong (fix the logic, not the retry).

## Tool compatibility

- Custom audit agents; standard retry and circuit-breaker patterns.

## Variant phrasings

### Policy check retry storm

Same failure, impact-worded.

### Agent hammering a failing check

The behavior phrasing of the same loop.

## Why it happens

Naive retry logic treats every failure as transient and immediate. Without backoff, a persistently failing check becomes a denial-of-service against the agent's own dependencies.

## Provenance

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