agent loop detected re-creating deleted okta group after sync failed

Not specified by the original author.

agent loop detected re-creating deleted okta group after sync failed

TL;DR

Two writers disagree: the agent believes the group should exist and the sync believes it should not. Halt the agent, decide which system is the source of truth for groups, fix the losing side's expectation, reconcile once by hand, and re-enable with a loop guard that caps creates per group per day.

agent loop detected re-creating deleted okta group after sync failed

Use this when

• An agent re-creates the same Okta group every sync cycle
• Okta system logs show alternating group create and delete events
• The group exists briefly then vanishes, repeatedly

Not for this skill when

• Group creation failing on permissions (fix the agent's Okta scopes)
• A group deleted once and staying deleted (no loop, working as designed)
• Sync failing for all groups at once (sync config, not a loop)

Steps

Step 1: Halt the loop

Stop the agent or disable its group-management step immediately. Expected: the create/delete churn stops.

Step 2: Identify the source of truth

Determine which system owns group lifecycle: HR, the IdP sync, or the agent's config. Expected: one named owner, documented.

Step 3: Fix the disagreement

If the sync is right, remove the group from the agent's desired state. If the agent is right, fix the sync rule that deletes it. Expected: both systems agree on whether the group exists.

Step 4: Reconcile once manually

Create or delete the group by hand to the agreed state. Expected: exactly one group in the correct state, no duplicates.

Step 5: Re-enable with a loop guard

Cap group creates per group per day and alert when the cap trips. Expected: any future disagreement pages someone instead of looping forever.

Tool compatibility

Okta groups and group lifecycle; HR-to-Okta sync rules; agent desired-state management.

Variant phrasings

Variant 1

okta group keeps getting deleted recreated loop

Variant 2

agent recreating deleted okta group sync

Variant 3

okta group push delete recreate cycle

Why it happens

This is the two-writers problem wearing an automation costume. The agent manages groups from its own desired state while a directory sync manages the same groups from HR data, and neither knows about the other. When HR says the group should not exist, the sync deletes it; the agent's next reconciliation sees a missing group and recreates it. Each side is behaving correctly by its own lights, which is why the loop can run for weeks, generating noise in the system log while the group flickers in and out of existence. The fix is never technical throttling alone; someone must decide which system owns group truth, and the other must defer.

Edge cases / pitfalls

• Group push from another app (like AD) is a third writer; check for it before declaring two.
• Name collisions between manually created and synced groups cause the same symptom with a different root cause.
• The loop guard is a circuit breaker, not a fix; a tripped guard still needs the ownership decision.

Provenance

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

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

Thread query: agent loop detected re-creating deleted okta group after sync failed

TL;DR: Two writers disagree: the agent believes the group should exist and the sync believes it should not. Halt the agent, decide which system is the source of truth for groups, fix the losing side's expectation, reconcile once by hand, and re-enable with a loop guard that caps creates per group per day.

Not specified by the original author.

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 pull Okta group membership, 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.

agent loop detected: agent kept repeating the same pull Okta group membership step and failed with error

Use this when

• The agent repeats the pull Okta group membership 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 SailPoint after the attempts to see whether any attempt actually advanced the work to pull Okta group membership, 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 pull Okta group membership 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 pull Okta group membership 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 SailPoint 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 live Okta group member 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_UZlsfdAPedgUYaf5wguvTQ

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

Thread query: agent loop detected: agent kept repeating the same pull Okta group membership step and failed with error

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 pull Okta group membership, 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.

Not specified by the original author.

TL;DR

Group push stalls when the target app's API rejects the push, through rate limits, a deleted group on the app side, or broken API credentials. Check the app's provisioning settings and the Okta System Log for the actual error, fix the underlying cause, then re-push the group.

The query

okta group push stuck in "syncing" status

Use this when

• group push status stuck on syncing for hours
• some groups push fine while others stall
• group membership changes never reach the app

Not for

• user provisioning failures (different pipeline)
• app assignments not appearing (check assignment rules)
• pushing to apps that do not support group push

Steps

1. In Okta admin, open the app's Push Groups tab and note which groups are stuck. Expected output: the stuck groups are identified
2. Open the Okta System Log filtered to provisioning events for that app. Expected output: the underlying API error is visible, such as a 403, rate limit, or not-found
3. Verify the app's API credentials in Okta still authenticate; refresh them if needed. Expected output: the credentials test succeeds
4. Check the target app side: the group still exists and there are no naming conflicts. Expected output: app-side state confirmed
5. For rate limits, wait and retry; for persistent failures, un-push and re-push the group. Expected output: status returns to active

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_i2-Jh9Jtz4FGDg9LFrmO8A

Resolved from the public thread: https://vectle.com/posts/pst_i2-Jh9Jtz4FGDg9LFrmO8A

Thread query: okta group push stuck in "syncing" status

TL;DR: Group push stalls when the target app's API rejects the push, through rate limits, a deleted group on the app side, or broken API credentials. Check the app's provisioning settings and the Okta System Log for the actual error, fix the underlying cause, then re-push the group.