# Fix agent loop re-inviting the same user every hour after the invite failed

## TL;DR
The agent re-invites hourly because the failed invite never got recorded and the retry has no backoff or cap. Record the invite attempt, back off between retries, and stop after a few tries with an alert. The user already has enough invites.

## The error
```text
Agent loop detected
Re-inviting the same user every hour after invite failed. 9 invites sent.
```

## Use this skill
Agent? Search Vectle for this error:
```bash
curl -s "https://vectle.com/api/v1/search?q=agent loop detected re-inviting the same user every hour after invite failed"
```

## Fix it

### Step 1: Stop the invite loop

```bash
Pause the agent's invite job.
```

Expected: No more duplicate invites.

### Step 2: Check whether any invite actually landed

```bash
Look in the app for pending invites to the user.
```

Expected: You know whether the user can already accept.

### Step 3: Record invite attempts

```bash
Store each invite with its result before retrying.
```

Expected: Retries see the history and stop duplicating.

### Step 4: Add backoff and a cap

```bash
Space retries increasingly and stop after a few attempts with a human alert.
```

Expected: Failures escalate instead of looping.

### Step 5: Resume and verify

```bash
Resume the agent and watch one failed invite.
```

Expected: It retries bounded times, then alerts.

## When this applies

- Agents loop on failed user invites
- Users get spammed with repeat invites
- You are building invite-sending agents

## When it doesn't

- Invites fail for a fixable reason (fix the invite API call)
- The user never gets any invite (check delivery)
- Different users get each other's invites (check the addressing)

## Compatibility

User invite flows generally: SaaS apps and IdPs.

## Variant phrasings

### agent re-inviting user loop

Same loop. Attempt records plus caps break it.

### invite failed agent retry hourly

Hourly retries with no backoff are a schedule bug. Back off and cap.

### duplicate invites onboarding agent

Duplicates come from retries without history. Record first, retry second.

## Why it happens

Invite jobs that run on a schedule retry every tick with no memory of past ticks. A persistently failing invite, bad email, app error, gets re-sent every hour forever. The schedule needs state: what was tried, what failed, and when to give up.

## Edge cases

- Some invites fail because the email bounces; check deliverability before retrying
- Pending invites in the app may block re-invites; clear or reuse them
- Alert the inviter, not just ops, when an invite needs human help

## If it still fails

- Reproduce with a minimal run: one user, one file, one step.
- Read the agent's full trace, not just the final error; the failure is usually upstream.
- Check the underlying API or tool directly, outside the agent, to separate agent bugs from service bugs.
- Reduce concurrency to one and see if the failure persists; races hide as flakes.
- If the run is business-critical, add a human checkpoint before the destructive steps.

## Prevention

- Checkpoint long runs so any failure resumes instead of restarting.
- Cap and back off every retry loop; unbounded retries are outages waiting to happen.
- Validate inputs at each pipeline stage; fail fast with clear errors.
- Log enough context per step that a timeout is diagnosable without rerunning.
- Give destructive steps a human checkpoint or a dry-run mode.

## Provenance

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