## TL;DR
Never let the agent address or personalize by first name alone. Every send must resolve to a unique lead id (or normalized email) first, and the drafting step must show the resolved identity - full name, company, and the numbers it plans to send - so a mismatch is visible before anything goes out.

```
agent mixed up two leads with the same first name  -  sent the pricing follow-up to the wrong person with the wrong numbers
```

## Steps

1. Make lead id (or normalized email) the only identity the send path accepts. Strip any step that looks up "the Sarah" or matches on first name.
   Expected: a search for first-name-only lookups in the workflow finds zero send paths using them.

2. Add an identity line at the top of every draft the agent produces: full name, company, lead id, and the specific figures in the message. Reviewers - human or automated - check this line first.
   Expected: every draft carries the identity line, and a wrong-person draft is catchable at a glance.

3. Before any message containing pricing, quotes, or account-specific numbers, the agent must re-fetch the lead record by id and confirm the numbers belong to that record.
   Expected: the re-fetch happens in the run log right before the send, with the record id visible.

4. Dedupe or flag near-duplicate contacts in the CRM - two records with the same first name at different companies are the setup for this exact failure.
   Expected: a report lists same-first-name contacts the agent touched in the last 30 days, so you can see the blast radius.

5. For the lead who got the wrong pricing, have the AE send a clean correction quickly and note the correct figures; do not let the agent "fix it" with another automated follow-up.
   Expected: the correction goes out from a human within a day, referencing the right numbers for the right person.

## Use this when
- two contacts share a first name (or last name) and the agent confuses them
- personalized numbers or details went to the wrong person
- the agent's lookup step matches on non-unique fields

## Not for this skill when
- the CRM has literal duplicate records for one person - that is a dedupe job
- the right person got wrong data - that is a data-quality problem
- the agent emailed the wrong address for the right contact - that is a contact-data problem

## Variant phrasings
- agent confused two leads with the same name
- pricing follow-up sent to the wrong Sarah
- first-name lookup hit the wrong contact
- personalized details went to the wrong person

## Why it happens
"Hi [first_name]" templates train everyone - including the agent's prompts - to think of the lead as a first name. Lookup steps written casually ("find Sarah") return the first match, and the drafting step happily personalizes with whatever record came back. The identity was ambiguous from the start; the send just made it permanent.

## Edge cases
- Common names at the same company (two Sarahs on one team) - the identity line must include title or department, not just company.
- The lead replies from a different email than the record - re-resolve identity on reply, do not assume the thread belongs to the original record.
- Nicknames vs legal names ("Mike" vs "Michael") - normalize at lookup time so both resolve to the same id.
- Merged records can carry the wrong id forward - after a CRM merge, verify the surviving record before the next send.

## Provenance

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