## TL;DR

Contain it, find the exact failure, fix the mechanism (not the instance), and add the guard that would have caught it. Agent failures repeat until the mechanism changes; fixing one lead, one run, or one message is triage, not a fix.

## The query

```text
agent's voicemail drop used text-to-speech with the wrong voice  -  the 'personal' recording sounded robotic for a week
```

## Use this when

- an agent failure does not match a more specific pattern
- you need the general contain-diagnose-fix-guard loop

## Not for

- provider error codes with documented meanings (use the specific skill)
- issues already covered by the idempotency, auth, or rate-limit skills

## Steps

### Step 1: Contain the blast radius first

Pause the agent, the sequence, or the job before diagnosing. An agent that is still running is still creating new instances of the problem while you investigate.

**Expected: the faulty path is paused; no new damage accrues during diagnosis.
### Step 2: Reproduce with the smallest case

Reduce the incident to one lead, one run, one message that shows the failure. The minimal repro separates 'the data was bad' from 'the logic is wrong' faster than any log dive.

**Expected: a minimal repro that fails reliably, or proof the input data was the cause.
### Step 3: Fix the mechanism, not the instance

Change the code, config, or guardrail that allowed the failure: the missing check, the wrong default, the absent cap. Patching the one affected lead leaves the mechanism armed for the next run.

**Expected: the change is in the shared path, not in per-lead cleanup.
### Step 4: Verify with the repro and a clean run

The minimal repro now passes, and a full clean run completes without the failure. Check both: the repro proves the fix, the clean run proves you did not break the normal path.

**Expected: repro passes; clean run completes; no regressions in the normal flow.
### Step 5: Add the guard that would have caught it

A pre-send assertion, a config validation, a test with the failing input, an alert on the metric that moved. Every incident should leave behind exactly one guard aimed at its mechanism.

**Expected: one new guard exists; the incident class cannot recur silently.

## Why it happens

Agent failures look novel but are usually one of a small set of mechanisms: missing idempotency, dead credentials, stale data, bad config, unbounded loops. The incident is new; the mechanism is old. Fix the mechanism.

## Edge cases

- Do not 'fix' by adding human review to every run; fix the mechanism and keep the automation.
- One-off data repairs without a mechanism fix guarantee a repeat incident.
- If the same failure hits twice, the first fix addressed the instance, not the mechanism.

## Finding this skill

This skill was written for sales-outreach (SDR) agents hitting the failure above. Search Vectle for the exact error text or symptom to find it and related skills.

## Provenance

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