## TL;DR
Break the loop by measuring progress, not by letting the agent try harder. Log the inputs and the result hash of the step that tries to export the entitlement report, and if two consecutive attempts use identical inputs and produce identical results, stop the run and change something real: the scope, the tool, or the data the step depends on. Add a hard attempt cap and a human escalation so a future loop ends with a useful report instead of a burned run.

```text
agent loop detected: agent kept repeating the same export the entitlement report step and failed with error
```

## Use this when
- The agent repeats the export the entitlement report step with the same parameters and the same outcome.
- Run logs show many attempts and no state change in the target system.
- The run only ends when it hits a global limit or is killed manually.

## Not for this skill when
- The step fails once with a clear platform error. Fix the platform error and retry normally.
- The agent is working through a long list where each step differs. That is progress, not a loop.

## Steps
1. Extract the repeated step calls from the run log and compare their parameters and results side by side to prove whether they are truly identical or slowly changing. Verify: the loop is characterised as identical repeats or near repeats with evidence.
2. Check the target state in Okta after the attempts to see whether any attempt actually advanced the work to export the entitlement report, since a reporting bug can make real progress look like repetition. Verify: target state is known independently of the agent own reporting.
3. Identify what the step is waiting for or missing, such as a status that never flips, a file that never appears, or a precondition the agent cannot see, by testing that precondition directly. Verify: the unmet precondition or false assumption is named.
4. Fix the precondition, or change the strategy for this step to a different tool or a smaller scope, rather than replaying the same call with new hope. Verify: the revised step differs from the looped one in a recorded way.
5. Add loop guards to the workflow: a per step attempt cap, a check that compares the result of each attempt with the previous one, and an automatic stop with a summary when no progress is detected. Verify: the guards are configured and visible in the workflow settings.
6. Rerun the guarded workflow on the affected scope and watch it either complete the step to export the entitlement report or stop early with the no progress summary. Verify: the rerun ends in completion or in a clean early stop, not a long loop.
7. File the loop summary, the root precondition and the guard settings with the review evidence so the pattern is recognisable if it recurs on another step. Verify: the evidence contains the loop analysis and the final guard configuration.

## Why it happens
Agents loop when a step result does not match the condition the agent expects next, and retrying feels safer than escalating. Without an external progress measure, identical calls look like persistence from the inside. The missing ingredient is almost always a state the agent cannot observe, a status field it misreads, or a precondition owned by another system. Guards that compare consecutive results make the loop visible mechanically, and a strategy change addresses the cause instead of rationing the symptom.

## Variants and edge cases

### agent stuck repeating export the entitlement report step
The operations phrasing. Prove identical inputs and outputs from the log before changing the workflow; similar looking steps may be genuine list processing.

### how to add loop detection to an access review agent
The engineering phrasing. A result comparison plus an attempt cap per step catches most loops within two wasted calls.

### same Okta call repeated with no progress in agent run
The log phrasing. Check target state independently; sometimes the loop is in the agent reporting, not in the platform.

Edge cases to check before closing the review cycle:
- Never assume a timed out call did nothing. Always check the Okta campaign item list before retrying a change.
- Two retries at the same settings prove nothing. Change one variable, size, timing or timeout value, per attempt and record it.
- Keep the run identifier on every output so a resumed run can prove it belongs to the same review cycle.

Compatibility: Agent workflow tooling with checkpointed tool calls, the named platform APIs at current versions, and a human reviewer able to verify results in the source system.

## Provenance

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