license agent loop detected: re-checking license assignment that Entra rejects

Not specified by the original author.

TL;DR

Record the permanent failure and stop retrying it; alert instead. A rejection that never varies is a data problem, not a timing problem.

Error

(agent re-checked the same rejected assignment 30 runs in a row; identical Entra error each time; no progress)

Steps

1. Confirm the rejection is deterministic: the same assignment, same error, every run. Expected: permanence established.
2. Read the Entra error detail to find the underlying cause (conflict, missing prerequisite, bad data). Expected: the real problem identified.
3. Fix the data or mark the assignment as permanently failed with the reason recorded. Expected: the loop broken by a decision.
4. Alert the owner; do not let the agent retry it again. Expected: human attention on the actual problem.

When to use

• The agent re-checks an assignment that always fails the same way
• The error is deterministic across runs
• No run ever makes progress on it

When not to use

• The failure varies (a transient problem; retry logic is fine)
• The assignment eventually succeeds (then it was transient)
• The check is cheap and idempotent (still better to record the outcome)

Tool compatibility

Entra ID license assignment checks.

Variant phrasings

loop across scheduled runs

Persist the failure record between runs so the next run skips it.

agent has no failure memory

Add one; without it every run repeats every failure.

Why it happens

Agents retry because most failures are transient. Deterministic rejections need a different response (fix or escalate), but the agent cannot distinguish them without failure memory.

Provenance

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

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

Thread query: license agent loop detected: re-checking license assignment that Entra rejects every run

TL;DR: Record the permanent failure and stop retrying it; alert instead. A rejection that never varies is a data problem, not a timing problem.

Not specified by the original author.

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.

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

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

Thread query: agent loop detected: agent kept repeating the same assign Microsoft 365 licenses step and failed with error

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.

Not specified by the original author.

TL;DR

Graph throttles aggressively with 429s carrying a Retry-After header. Honor that header, reduce the page size to slow the request rate, checkpoint each page, and resume from the checkpoint.

agent hit Entra Graph API rate limit mid-run, license enumeration failed

Use this when

• An agent enumerating Graph users or licenses hits 429 and aborts.
• The Retry-After header is present in the failure.
• The enumeration works on small tenants but not large ones.

Not for this skill when

• The failure is a 401. That is auth.
• The query returns empty. That is a filter or permission problem.
• The throttle never clears. Check whether the app is banned or misconfigured.

Steps

1. On 429, sleep for the full Retry-After duration. Verify: the wait matches the header.
2. Reduce the page size to lower the request rate. Verify: requests per minute drop.
3. Checkpoint each page durably. Verify: progress survives a restart.
4. Resume from the last checkpoint after the wait. Verify: enumeration continues.
5. Confirm the full enumeration completes. Verify: the user and license counts look complete.

Variant phrasings

Graph API 429

The short phrasing.

throttled mid-run

The state-first search.

enumeration failed

The symptom-first phrasing.

Compatibility: Microsoft Graph API, any agent or script doing bulk enumeration.

Why it happens

Graph throttling is per-app and adaptive: it tightens as you push harder. Ignoring Retry-After escalates the throttle instead of clearing it.

Edge cases / pitfalls

• The throttle applying to the whole tenant's app registration, affecting other tools too.
• Delta queries as the long-term fix: they transfer far less per run.
• Sleeping the exact Retry-After with no jitter can re-collide; add a small buffer.
• The agent parallelizing requests across threads, multiplying the effective rate.

Provenance

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

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

Thread query: agent hit Entra Graph API rate limit mid-run, license enumeration failed

TL;DR: Graph throttles aggressively with 429s carrying a Retry-After header. Honor that header, reduce the page size to slow the request rate, checkpoint each page, and resume from the checkpoint.