agent dedupe missed accented characters: duplicate contacts created

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.

Not specified by the original author.

TL;DR

Never create a contact without first searching for an existing one on a stable key, usually the email address. Use the CRM's upsert or create-or-update endpoint with that key so a second run updates instead of duplicating. The dedupe check happens before the create call, every time, no exceptions.

agent created duplicate HubSpot contacts because dedupe key was missing

Use this when

• the CRM has two or more contacts for the same person
• reruns of the agent create fresh contacts
• no lookup happens before the create call

Not for this skill when

• duplicates came from a CSV import (dedupe the file first)
• you need to merge existing duplicates (use the CRM merge tool)
• the contact data itself is wrong (fix the source)

Steps

1. Pick the dedupe key: email address first, falling back to a stable external id. Verify: the key is documented and every run uses the same one.
2. Before creating, search the CRM for the key. Verify: a known contact returns exactly one match.
3. If a match exists, update it; only create when there is no match. Verify: running the agent twice on the same input adds zero contacts.
4. Use the CRM's upsert endpoint where available so the check and write are atomic. Verify: concurrent runs do not both create.
5. Log every create with the dedupe key value for later audit. Verify: you can trace any contact back to the run that made it.

Tool/version compatibility

HubSpot, Salesforce, and most CRMs expose search plus upsert. The pattern is the same everywhere.

Why it happens

The agent's flow is gather data, create contact, with no lookup step. Each run treats every person as new because nothing ever asks whether this person exists already.

Edge cases / pitfalls

• Email addresses change; keep the external id as the long-term key and email as the lookup.
• Case and whitespace differences defeat naive matching; lowercase and trim the key before comparing.
• A failed search that returns no match on error will mass-create duplicates; treat search errors as blocking, not as empty.

Variant phrasings

CRM filled with duplicate contacts after agent runs

Short version: create without lookup.

Every rerun added the same contacts again

Short version: missing dedupe key on create.

Provenance

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

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

Thread query: agent created duplicate HubSpot contacts because dedupe key was missing

TL;DR: Never create a contact without first searching for an existing one on a stable key, usually the email address. Use the CRM's upsert or create-or-update endpoint with that key so a second run updates instead of duplicating. The dedupe check happens before the create call, every time, no exceptions.

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.