agent loop detected re-sending password reset to bounced email that failed delivery

Fix agent loop re-sending password resets to bounced emails

TL;DR

The agent re-sends because it never checks deliverability and retries blindly. Check the bounce status before resending, suppress hard-bounced addresses, and alert instead of retrying. Re-sending to a dead address helps nobody.

The error

Agent loop detected
Re-sending password reset to bounced email that failed delivery. 15 sends, all bounced.

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=agent loop detected re-sending password reset to bounced email that failed delivery"

Fix it

Step 1: Stop the resend loop

Pause the password-reset job.

Expected: No more doomed sends.

Step 2: Check the bounce status

Look up the address in your email provider's bounce or suppression list.

Expected: You confirm a hard bounce.

Step 3: Suppress the address

Add it to the suppression list so no future sends target it.

Expected: The address is excluded from all sending.

Step 4: Alert for human follow-up

Notify support or the account owner that the user needs a working email.

Expected: A human resolves what the agent cannot.

Step 5: Gate future sends on deliverability

Before sending, check suppression and recent bounce state.

Expected: Bounced addresses never enter the send loop again.

When this applies

• Agents loop on bounced password resets
• Users never receive resets at dead addresses
• You are building password-reset agents

When it doesn't

• The email does not bounce but never arrives (check spam and filters)
• The reset link itself is broken (fix the link)
• The address is valid and bounces transiently (retry with backoff)

Compatibility

Password reset flows with email providers: SendGrid, SES, and others.

Variant phrasings

agent resending to bounced email

Same loop. Suppression plus deliverability gates fix it.

password reset bounce loop

Bounce loops waste sends and hurt reputation. Suppress fast.

agent retrying hard bounce

Hard bounces never recover. Soft bounces get backoff; hard bounces get suppression.

Why it happens

Password-reset agents often retry on any delivery failure without distinguishing hard bounces (dead address) from transient ones. A hard-bounced address fails identically every time, so the retry loop is futile and damages sender reputation with every attempt.

Edge cases

• Distinguish hard from soft bounces; only hard bounces suppress permanently
• Users with bounced emails need an alternate contact path; build one
• Log bounce-driven suppressions so support can see why a user got no email

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/psts4CZ7YDF2bXavYNqpdnCg