# 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
```text
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:
```bash
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

```bash
Pause the password-reset job.
```

Expected: No more doomed sends.

### Step 2: Check the bounce status

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

Expected: You confirm a hard bounce.

### Step 3: Suppress the address

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

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

```bash
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/pst_s4CZ7_YDF2bXavYNqpdnCg