## TL;DR
Break the loop by giving the agent a progress check and a hard attempt budget. The agent is repeating the assign Microsoft 365 licenses step because its success test never passes, usually because it checks the wrong signal or the step result never reaches its state. Add a direct verification read from Entra ID, stop after a small number of attempts with a clear escalation, and fix the underlying success test so one success ends the step.

```text
agent loop detected: agent kept repeating the same assign Microsoft 365 licenses step
```

## Use this when
- The run log shows the identical step and inputs attempted many times with no state change.
- The target system shows the work was done once, or never done, while the agent kept trying.
- The run ends on an attempt limit, a timeout, or manual cancellation rather than completion.

## Not for this skill when
- The agent retries a few times with backoff and then succeeds. That is healthy retry behaviour, not a loop.
- A human keeps restarting the run manually. Fix the operational process instead of the agent.

## Steps
1. Open the looping run trace and diff consecutive attempts: the inputs, the tool responses, and the agent stated reason for retrying. Identify the exact success condition the agent believes is unmet. Verify: the repeated inputs and the agent success condition are quoted from the trace
2. Check Entra ID directly for the step result and compare reality with the agent belief: if the result exists, the agent verification is broken; if it never exists, the create call itself is failing in a way the agent misreads as retryable. Verify: ground truth and the agent belief are contrasted explicitly
3. Fix the verification: replace any indirect signal, such as searching a list page or parsing a chatty response, with a direct read of the created object by its identifier in Entra ID, and treat a confirmed read as step success. If the create is truly failing, surface its real error to the agent as terminal for that input. Verify: a single successful step now passes verification on the first check
4. Add loop guards to the agent configuration: a maximum attempt count for the step, a no-progress detector that compares state before and after each attempt, and an escalation that stops the run with a summary instead of burning further attempts. Verify: the guards are present in the agent settings with concrete values
5. Re-run the scenario for one hire end to end and confirm the assign Microsoft 365 licenses step executes once, verifies, and the run moves on. Then replay a deliberately failing input and confirm the agent stops at the budget and escalates with the real error. Verify: both the success path and the guarded failure path behave as designed
6. Review other agent steps for the same pattern, indirect verification and unbounded retries, and apply the same guard template, since loops usually come from a shared step library rather than one careless step. Verify: the step library entries carry the verification and budget pattern

## Why it happens
Agent loops happen when the decision to retry is driven by a success test that cannot pass, even when the work itself succeeds. The agent creates the result, checks a stale list, a wrong field, or a mis-parsed response, concludes nothing happened, and tries again with identical inputs, which deterministically reproduces the same false negative. Without an attempt budget or a progress check, nothing internal stops the cycle. Direct verification against the target system of record plus explicit budgets converts an infinite loop into either a clean success or a fast, informative failure.

## Variants and edge cases
### Loop creates duplicates each attempt
When each attempt really does create a new object, add the lookup-before-create guard first and clean up the duplicates by creation timestamp, keeping the earliest complete record.

### Loop alternates between two steps
Two steps each undoing or re-checking the other indicates conflicting success criteria. Align both steps on one shared state read before adding budgets.

### Loop only for one hire record
A record-specific loop usually means that record triggers a real error the agent classifies as retryable. Log the raw target error for that record and fix its data.

Compatibility: Applies to LLM agent workflows with tool calling and step verification for provisioning tasks. Requires agent configuration access.

## Provenance

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