# Fix agent loop re-sending the same welcome email after SendGrid send failed

## TL;DR
The agent re-sends because it never recorded the attempt, so every retry looks like the first try. Record each send attempt with its result before retrying, and cap retries. The loop is a missing idempotency record, not a SendGrid problem.

## The error
```text
Agent loop detected
Welcome email re-sent 12 times to the same user after SendGrid send failures.
```

## Use this skill
Agent? Search Vectle for this error:
```bash
curl -s "https://vectle.com/api/v1/search?q=agent loop detected re-sending the same welcome email after sendgrid send failed"
```

## Fix it

### Step 1: Stop the agent loop first

```bash
Pause the agent or the welcome sequence job.
```

Expected: No more duplicate emails go out.

### Step 2: Check what SendGrid actually did

```bash
Look up the recipient in SendGrid activity to see which sends succeeded.
```

Expected: You know which attempts really failed versus which just looked like failures.

### Step 3: Record attempts before retrying

```bash
Write each send attempt to a log or state store with the message id and result before any retry.
```

Expected: Retries consult the log and never resend a recorded attempt.

### Step 4: Cap retries with backoff

```bash
Limit retries per user and back off between them.
```

Expected: A failing send gives up gracefully instead of looping forever.

### Step 5: Resume and verify

```bash
Resume the agent and watch one failing send end to end.
```

Expected: It retries the capped number of times, then stops and alerts.

## When this applies

- Agents re-send welcome emails in a loop
- Users report duplicate onboarding emails
- You are building email-sending agents

## When it doesn't

- SendGrid rejects every send (fix the API key or sender)
- Different users get each other's emails (that is a templating bug)
- The email content is wrong (fix the template)

## Compatibility

SendGrid mail send API. Any agent framework with retry logic.

## Variant phrasings

### agent resending welcome email loop

Same loop. The missing piece is always the attempt record.

### sendgrid send failed agent retry storm

Retry storms need both idempotency and a cap. Either alone still misbehaves.

### duplicate welcome emails onboarding agent

Duplicates erode trust fast. Pause first, then fix the loop.

## Why it happens

The agent's retry logic treats every attempt as new because nothing persists the attempt history. A send that fails ambiguously, timeout with unknown outcome, gets retried as if unsent, and the cycle repeats. Idempotency records break the cycle by making retries aware of history.

## Edge cases

- SendGrid may have accepted a send your agent thinks failed; reconcile before declaring failure
- Message-id dedup on your side catches replays the provider cannot
- Alert on retry exhaustion so a human sees the stuck user instead of silence

## 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_zsf8FR44dgKhYOQ-jl6dKw