## TL;DR
The check's result never changes because the underlying state never changes, or the check reads stale state. Record the check outcome per user, stop checking that user after a few identical results, and investigate why the state is stuck.

```text
agent loop detected: re-running deprovision check on the same user, job failed
```

## Use this when
- An agent re-checks the same user's deprovision status endlessly.
- The job only ends on timeout.
- The check result is identical every time.

## Not for this skill when
- The state genuinely changes between checks. Then the loop is working.
- The check errors instead of returning. Fix the check.
- The loop spans users, not one user. That is a different loop shape.

## Steps
1. Store the last check result per user. Verify: the record exists.
2. If the result is identical three times, stop checking that user this run. Verify: the loop breaks.
3. Investigate why the state is not changing: stale cache versus really stuck. Verify: you know which.
4. Fix the root cause: refresh the cache or unstick the deprovision. Verify: the state moves.
5. Confirm the job completes. Verify: no user spins forever.

## Variant phrasings
### deprovision check loop
The short phrasing.
### same user re-checked
The behavior-first search.
### job failed loop
The generic phrasing.

Compatibility: Any agent running repeated status checks.

## Why it happens
The agent treats checking again as progress. Without a change detector, a stable state looks like a task still in flight, so it checks forever.

## Edge cases / pitfalls
- State that changes slowly; use longer intervals between checks, not infinite checks.
- The cache TTL being the real problem; the check is fine, the data is stale.
- Three identical results being too few for slow systems; tune the count.
- The investigation step skipped: the loop guard without the root-cause fix just hides the problem.

## Provenance

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