# 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.

```text
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