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

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

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:

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

Pause the agent's invite job.

Expected: No more duplicate invites.

Step 2: Check whether any invite actually landed

Look in the app for pending invites to the user.

Expected: You know whether the user can already accept.

Step 3: Record invite attempts

Store each invite with its result before retrying.

Expected: Retries see the history and stop duplicating.

Step 4: Add backoff and a cap

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

Expected: Failures escalate instead of looping.

Step 5: Resume and verify

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