One Customer, Four Records: AI Agents for Messy CRM Data Matching
Exact rules miss matches; fuzzy rules merge the wrong companies. The hybrid pipeline: rules do the volume, an AI agent judges the ambiguous 20%, you spot-check.
A Bangkok B2B supplier's CRM had the same customer four times: "Siam Foods Co.", "Siam Food Co., Ltd.", "The Siam Foods Group", and one record whose only identifier was an @siamfoods.co.th email. Reports were wrong, marketing sent duplicates, and the sales team had quietly built a private spreadsheet because it was more trustworthy than the system. An intern spent a week manually merging and gave up at record 200 of 1,100.
This — deciding whether two messy real-world entries are the same thing — is one of the perfect jobs for AI. Not the creative stuff. The judgment calls.
AI agents excel at "adaptive work": matching tasks that need just enough judgment to defeat rigid rules, but not enough to need a human researcher. For CRM deduplication, use a hybrid pipeline: deterministic scripts handle ingestion, formatting, and exact-match merging (the bulk), while an AI agent handles only the ambiguous residue — comparing "Siam Foods Co." vs "The Siam Foods Group" across names, domains, addresses, and corporate parents. The agent outputs a structured verdict (match ID, confidence, evidence-based reasoning), and can optionally browse the web to verify a parent company. Fast where rules work, intelligent where they don't. :::
Why rules and fuzzy matching both fail
Every dedup project starts with rules and ends in frustration:
| Approach | What it catches | How it fails |
|---|---|---|
| Exact match | "Siam Foods Co." = "Siam Foods Co." | Everything else — suffixes kill it |
| Normalization (strip Ltd/Co) | "Siam Foods" = "Siam Foods Co., Ltd." | Legal suffixes gone, brand variants remain |
| Fuzzy string match (≥85% similar) | Typos, minor variants | Merges "Siam Foods" and "Siam Food Products" — two different companies |
| Human review | Everything | 1,100 records × 90 seconds = three weeks nobody has |
The trap closes from both ends: too strict, you keep duplicates; too loose, you merge distinct companies — which is worse, because now sales history from two customers lives on one record.
The residue after rules run — maybe 15–30% of records — is exactly the "adaptive" band: needs common sense, not creativity.
The hybrid pipeline
Same doctrine as the quoting architecture: deterministic code does the volume, AI does the judgment, and a table holds the state.
STAGE 1 — deterministic (code, free, instant)
normalize names (legal suffixes, case, Thai transliteration variants)
exact + normalized matches → auto-merge, log the rule used
STAGE 2 — candidate search (code)
fuzzy score every remaining record against others
keep only PAIRS scoring 70–95% ("ambiguous zone")
discard <70% (different) and auto-merge >95% (same, verify later)
STAGE 3 — agentic judgment (AI, only the ambiguous pairs)
input: the pair + all context (emails, domains, phones, addresses)
output: JSON verdict
STAGE 4 — human spot-check (you, 10% sample)
confidence < high → review queue; else auto-applied
The agent sees only pre-filtered candidate pairs — never the whole database. That's what keeps it fast, cheap, and focused.
What the agent actually does differently
Given "Siam Foods Co." vs "The Siam Foods Group," the agent weighs evidence the way you would:
{
"task": "decide if these two records are the same company",
"evidence_to_weigh": [
"name_similarity (beyond string match: brand words, word order)",
"email domains: siamfoods.co.th vs siamfoodsgroup.com — related?",
"addresses: same district? same building?",
"phone numbers: shared main line?",
"known corporate structures: 'The X Group' often parents 'X Co.'"
],
"allowed_actions": ["web_browse: check the site's About page for parent/company name"],
"output": {
"verdict": "same | different | uncertain",
"confidence": "high | medium | low",
"match_key": "record id if same",
"reasoning": "one sentence citing ONLY provided evidence"
}
}
Three things make this production-grade rather than a demo:
- Evidence over vibes — the reasoning must cite the provided fields; if evidence is missing, verdict is
uncertain, never guessed (the quote-or-empty discipline again) - Web browsing as the tiebreaker — when domains conflict, the agent visits the About page and checks whether "The Siam Foods Group" is the parent of "Siam Foods Co." — the same check a human would make, in seconds
- Structured output — a verdict row, not prose; stage 4 samples it, and low confidence routes to you
Field-tested failure modes (and their fixes)
Agent gets stuck on broad searches. "Find and match this company" is too open — the agent wanders. Fix: scripts build the candidate queries; the agent only judges what the queries return. Judgment and searching are separate blocks.
Right answer, wrong reason. The agent merges correctly but says "same city" when the cities differ — it's pattern-filling from examples. Fix: state in the prompt that examples show structure only, and reasoning must reference actual field values; reject any verdict whose cited evidence doesn't check out programmatically.
Cost creep on big backlogs. 1,100 records × every pair is O(n²) madness. Fix: stage 2's candidate filtering means the agent sees hundreds of pairs, not millions — and one pair costs a fraction of a cent.
The realistic outcome
For a typical messy SMB database:
- Stage 1+2 auto-resolves ~70–80% of duplicates with zero AI cost
- Stage 3 clears most of the remainder at high confidence
- Stage 4 review lands on a few dozen genuinely weird cases — an afternoon, not three weeks
- Going forward, the pipeline runs nightly on new records; the mess never rebuilds
And once your customer records are trustworthy, your reporting becomes trustworthy — including where customers come from. Pair the clean CRM with a free geo-grid scan at https://gbppeak.com/free-maps to see where your Google Maps visibility actually stands across your service area.
Frequently Asked Questions
What makes this "agentic" rather than just an AI call?
The decision may require dependent steps: search candidates, notice the evidence conflicts, choose to browse the company's website, then conclude. A single prompt can't do that sequence; an agent with tools can decide when to dig deeper — like a careful human researcher, at machine speed.
Isn't fuzzy matching enough?
Fuzzy matching compares strings; it can't know "The Siam Foods Group" parents "Siam Foods Co.", or that two near-identical names are fierce competitors. Use it as stage 1 filtration, and give the ambiguous residue to an agent that weighs context instead of character distance.
How do I stop the AI from confidently merging two different companies?
Require verdict + confidence + reasoning that cites only the provided fields, reject verdicts whose cited evidence fails a programmatic re-check, and route medium/low confidence to human review. Merges are also reversible if you log the rule/verdict used for each one.
Does this work for Thai company names and mixed-language data?
Yes — mixed Thai/English records are precisely where string matching collapses and LLM reasoning shines (transliteration variants, จำกัด vs Co., Ltd., brand names in both scripts). Keep the agent's evidence fields bilingual and let the prompt note common Thai corporate naming patterns.
Final note
You don't replace your rules with AI. You find the exact spot where your rules stopped working — the ambiguous 20% that consumed 100% of your intern's week — and hand just that slice to something with judgment. That's the whole pattern: volume to code, judgment to AI, trust checks to you.