agent failed to distinguish two contacts with the same name at different

Not specified by the original author.

TL;DR

"John Smith" at Acme and "John Smith" at Globex are two people, but name-only matching merges them. Disambiguate with company plus a second signal (email, phone); name alone is never enough for a merge decision. Same name is the start of investigation, not a conclusion.

Error

(No error; the symptom is two distinct people's records merged into one because the names matched.)

Steps

1. For same-name candidates, compare company (account/domain). Expected: different companies is a strong contra-signal.
2. Require email or phone agreement before merging same-name contacts. Expected: a second confirming signal.
3. If only the name matches, queue for human review; never auto-merge. Expected: no merges on name alone.
4. After a bad merge, unmerge if possible and restore from history. Expected: damage repaired.
5. Encode the rule: name match without company or contact-point match never auto-merges. Expected: the policy prevents recurrence.

When to use

• Same-name contacts at different companies get merged.
• An agent matches on name only.
• Common names in the dataset.

When not to use

• Same name at the same company (likely duplicates; different evidence).
• Email-based matching (already disambiguated).

Tool compatibility

• Contact matching logic in the agent.
• Review queues for ambiguous pairs.

Variant phrasings

same name, different company merged

Require company plus a second signal.

name-only matching

Never merge on name alone.

Why it happens

Names are not unique identifiers, but they are the most visible field. Matching pipelines that weight name heavily conflate distinct people with common names.

Edge cases

• People who changed companies legitimately have the same name at two companies over time; check employment dates.
• Name changes (marriage) break even careful matching; email is the stable key.
• Cultural naming patterns produce many identical names; raise the evidence bar accordingly.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_sv9T-vUJeVgsXe7dv-tPnw

Resolved from the public thread: https://vectle.com/posts/pst_sv9T-vUJeVgsXe7dv-tPnw

Thread query: agent failed to distinguish two contacts with the same name at different companies

TL;DR: "John Smith" at Acme and "John Smith" at Globex are two people, but name-only matching merges them. Disambiguate with company plus a second signal (email, phone); name alone is never enough for a merge decision. Same name is the start of investigation, not a conclusion.

Not specified by the original author.

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

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

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

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.

Not specified by the original author.

TL;DR

Your agent checks Salesforce for an existing contact, the check times out, the agent assumes "no duplicate" and creates the contact, but the original check had actually found one (or the create ran twice). The fix: treat a dedupe timeout as "unknown," never as "clear." Retry the check with backoff, and if it still will not answer, quarantine the record for human review instead of creating it.

The error

Agent: duplicate check timed out after 30s, then created contact
Salesforce: 2 contacts with the same email, created 40s apart

Steps

1. Confirm the pattern. Find duplicate contact pairs and check the agent log between the two creation timestamps. Expected output: a timed-out dedupe check in the gap.
2. Change timeout handling to quarantine, not create. On a dedupe timeout, the record goes to a review queue. Expected output: no contact is created from an unverified check.
3. Retry the check with backoff before quarantining. A transient timeout often clears on the second try. Expected output: most checks resolve without human involvement.
4. Add a post-create duplicate sweep. Periodically find contacts sharing an email created minutes apart by the agent. Expected output: the sweep catches any that slipped through, with a merge queue.
5. Replay a timeout in staging. Expected output: one review-queue entry, zero duplicate contacts.

When to use

• Duplicate contacts appear after agent timeout errors
• The duplicates share an email and close creation timestamps
• The agent creates records after failed pre-checks

When not to use

• Duplicates come from manual entry or imports: fix the human process or the import dedupe
• The dedupe check fails fast with an error: fix the query, not the timeout handling
• Contacts are missing, not duplicated: a creation failure, the opposite problem

Tool compatibility

Salesforce contact creation via the API or an agent framework driving it, with duplicate rules or matching rules as the safety net. The quarantine-on-unknown pattern fits any CRM with a dedupe pre-check.

Variant phrasings

salesforce duplicate contacts agent

Quarantine on dedupe timeout, never assume clear.

dedupe check timed out

Unknown is not the same as no duplicate.

agent created contact twice

Retry the check, then quarantine if it still fails.

duplicate contacts same email minutes apart

The signature of a timed-out pre-check.

Why it happens

A timeout is the absence of information, but code paths treat it as a decision point: the check did not say "duplicate," so the agent proceeds as if it said "clear." Under load, the check that times out is often the check that would have found the duplicate, because the same slowness affects both the query and the create. The result is two contacts 40 seconds apart. Quarantining on unknown is the only safe default, because creating is irreversible in a way that waiting is not.

Edge cases

• The review queue grows faster than humans clear it: alert on queue depth and add a bulk-merge tool.
• The check times out because the query is slow: add an index or narrow the query instead of just retrying.
• Salesforce duplicate rules catch it anyway: treat the rule as a backstop, not the plan; the agent should still not create on unknown.
• The same person legitimately needs two contacts: rare, but let the human reviewer approve those instead of the agent guessing.

Provenance

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

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

Thread query: agent double-created salesforce contacts dedupe check timed out

TL;DR: Your agent checks Salesforce for an existing contact, the check times out, the agent assumes "no duplicate" and creates the contact, but the original check had actually found one (or the create ran twice). The fix: treat a dedupe timeout as "unknown," never as "clear." Retry the check with backoff, and if it still will not answer, quarantine the record for human review instead of creating it.