What Is Entity Resolution? How It Actually Works, and Why It Matters in 2026

We build sales and marketing AI agents for a living, and they're always working across systems. Sales runs on Salesforce. Marketing runs on HubSpot. Support lives somewhere else again.

One agent broke in the quietest way possible. The same customer lived in both systems as two different records. No shared ID. No match. So the agent guessed.

Sometimes it guessed wrong. It logged a call against the wrong account and told a rep a deal had gone cold when it was two calls from closing.

There's a name for the gap that caused this, and most people who ship software with AI in it have never heard it: entity resolution.

Entity resolution decides whether two or more records, however differently they're formatted, describe the same real-world person, company, or thing. Get it right and every system in a stack agrees on identity. Get it wrong and every AI agent, dashboard, and workflow built on top of that data inherits the confusion.

What Do Entity Resolution, Identity Resolution, Record Linkage and Deduplication Actually Mean?

The four terms overlap, and vendors use them loosely, so it helps to separate them properly.

Deduplication finds and merges duplicate records inside a single dataset, such as two rows for the same person in one spreadsheet.

Record linkage is the older, statistical term for matching records that describe the same entity across two or more separate datasets. It's an older idea than most people assume: it comes out of census and public health statistics, where William Winkler and colleagues at the US Census Bureau spent decades formalising it for national data files (Winkler, 2014).

Identity resolution is usually the martech and adtech flavour of the same problem, narrowed to people: stitching a browser cookie, a mobile ID, and an email address into one consumer profile (Fivetran).

Entity resolution is the umbrella term. It covers people, companies, products, addresses, transactions, anything a system needs to recognise consistently, whether the comparison happens inside one dataset or across ten.

How Does Entity Resolution Actually Work?

Under the hood, an entity resolution engine is answering one question over and over: given two records, what's the probability they describe the same thing? Two broad families of technique answer that question.

What Is the Difference Between Deterministic and Probabilistic Matching?

Deterministic matching links records only when specific fields agree exactly, or agree after light normalisation: the same tax ID, the same verified email, the same government identifier. It's fast, explainable, and precise when a strong shared key exists.

Probabilistic matching (also called fuzzy matching) doesn't need one perfect key. It scores similarity across several weaker fields at once, such as a name spelling, an address format, and a phone number, and combines those scores into a single confidence figure.

Most production systems run both: deterministic rules catch the easy, high-confidence pairs, and probabilistic scoring handles everything else.

What String-Similarity Methods Do Matching Engines Actually Use?

Three methods do most of the work, and each one catches a different kind of real-world mess.

Levenshtein distance (also called edit distance) counts the minimum number of single-character insertions, deletions, or substitutions needed to turn one string into another. Vladimir Levenshtein introduced it in 1965, published in English in 1966 (Levenshtein, 1966). It's good at catching typos: "Jonathon" versus "Jonathan" is a distance of one edit.

Jaro-Winkler similarity was built for short strings like names. It scores matching characters within a limited distance of each other, then adds a bonus for a shared prefix, on the logic that people rarely mistype the start of a name. Matthew Jaro proposed the base metric in 1989; William Winkler, then at the US Census Bureau, added the prefix weighting that carries his name (Winkler, US Census Bureau; Oracle FCCM matching guide).

Soundex matches by sound rather than spelling. Margaret Odell and Robert Russell patented it in 1918 for indexing US Census names phonetically, so "Smith" and "Smyth" land on the same code (Soundex history, West Penwith). It still catches transliteration and phonetic drift that edit distance misses.

What Is the Fellegi-Sunter Model, and Why Does It Still Run Under Most Matching Engines?

In 1969, statisticians Ivan Fellegi and Alan Sunter published "A Theory for Record Linkage" in the Journal of the American Statistical Association, and it's still the theoretical backbone that most modern matching engines approximate, rules-based or machine-learned (Fellegi & Sunter, 1969).

Their model compares each field between two records and asks two questions. First, the m-probability: if this pair really is the same entity, how likely is this field to agree? Second, the u-probability: if this pair is not the same entity, how likely is this field to agree purely by chance? A birth month agreeing by chance is roughly one in twelve; a rare surname agreeing by chance is far lower (record linkage overview, Wikipedia).

The ratio of those two probabilities, logged and summed across every compared field, produces a total weight for the pair. Fellegi and Sunter proved that sorting pairs by this weight and cutting them into three groups, link, possible link, and non-link, is the statistically optimal decision rule for a chosen pair of error-rate bounds. That three-way split, with a manual review queue in the middle, is still how most sanctions screening and KYC systems are built today.

How Do Confidence Scores and Match Thresholds Actually Work?

A matching engine turns the Fellegi-Sunter weight, or a machine-learned equivalent, into a single confidence score per candidate pair. Two thresholds then decide what happens to it.

Above the upper threshold, the pair auto-links. Below the lower threshold, it's treated as two separate entities. Anything in between becomes a possible match, usually routed to a person or a secondary rule for review.

Where you set those thresholds is a business decision. It isn't just a statistics problem. A KYC team screening for sanctioned individuals will accept more manual review to avoid missing a true match. A marketing team deduplicating a newsletter list will tolerate more risk in exchange for less manual work.

What Is Blocking, and Why Does It Matter at Scale?

Comparing every record against every other record doesn't scale. A file of one million records has close to 500 billion possible pairs, and scoring each one isn't feasible (Binette & Steorts, arXiv).

Blocking, also called candidate generation, solves this by grouping records on a cheap shared key first, such as a postal code, a birth year, or the first three letters of a surname, and only running detailed comparisons inside each group (Zingg, Entity Resolution at Scale).

Blocking trades recall for speed: an overly aggressive block can split two true matches into different groups before they are ever compared. The usual fix is running several overlapping blocking passes on different keys, so a pair only needs to share one of several possible signals to reach the scoring stage.

What Is a Resolution Graph, and How Is It Different From a "Golden Record"?

Older master data management flattened everything into a single "golden record," a merged row that overwrote the sources it came from. That approach loses the original evidence and makes it hard to unwind a bad match later.

The alternative most modern platforms use is a resolution graph: source records stay untouched as nodes, and deterministic and probabilistic matches become edges between them. The "entity" is the connected cluster you can walk in either direction, back to any original record (Aerospike, entity resolution and golden records; Binette & Steorts frame entity resolution formally as a graph clustering problem). New records can be added and the graph updates incrementally, instead of forcing a full re-merge.

Entity Resolution, Explained

Real-Time vs Batch Entity Resolution: What's the Difference, and Why Does It Matter?

Entity resolution runs on two different clocks, and the right one is a function of whether a decision is waiting on the answer, not a matter of style.

Batch is the right tool when nothing is blocked on the answer: a nightly dedupe of a marketing list, a quarterly reconciliation of a warehouse table. Real-time matters the moment a live decision depends on identity: approving a new account, screening a transaction, or letting an AI agent answer a customer correctly on the first try. Streaming, API-native matchers resolve and update the graph as records arrive, rather than waiting on the next batch window. AWS Entity Resolution and API-native platforms such as Tilores (tilores.io) both work this way; they sit alongside older batch-first master data management tools rather than replacing every use case for them.

Why Does Entity Resolution Matter Right Now?

Data quality and Customer 360. Every company with more than one system of record has the same problem we opened with: the same customer exists as slightly different rows in different tools, and nobody owns the reconciliation, so it doesn't happen. Entity resolution is the mechanism, not the aspiration, behind a genuine "single view of the customer."

KYC, AML, and sanctions screening. Checking a new customer's name against a sanctions or politically-exposed-persons list is a record-linkage problem wearing a compliance hat: is this applicant the same person as this listed name, given transliteration, nicknames, and typos? Regulators expect a risk-based compliance programme built around exactly this kind of screening control (OFAC, A Framework for OFAC Compliance Commitments). Set the matching threshold too loose and investigators drown in false positives; set it too tight and a real match slips through.

AI agents and RAG. This is where it gets underrated. When an agent or a retrieval pipeline pulls "the customer record," it's trusting that something upstream already answered which records belong to that customer. If entity resolution is missing, wrong, or inconsistent, the agent doesn't know it's wrong. It just answers confidently from whichever fragment it retrieved, because a language model has no way to tell a fragmented identity from a complete one. Commentators tracking enterprise RAG failures increasingly trace hallucinations back to exactly this kind of upstream data problem rather than the model itself (CX Today, AI hallucinations and dirty data). Feed an agent a resolved, deduplicated identity layer and it stops guessing. Feed it two fragments of the same person and it will pick one, confidently, and sometimes pick wrong, which is exactly what happened to us.

Can Two Records With No Shared Key Really Resolve to the Same Person?

Yes, and it's worth walking through because it's the part people find hardest to believe.

Say a CRM holds a contact: "Maria Alonso-Diaz," company "Fernwood Supply," city "Austin," no phone number on file. A separate marketing tool holds a lead captured from a webinar form: "M. Diaz," a personal Gmail address, phone "(512) 555-0199," company "Fernwood Supply," city "Austin."

No single field matches exactly. The emails are different. The names are formatted differently. There's no shared customer ID. A deterministic, exact-match rule would call these two different people and move on.

A probabilistic matcher doesn't need one perfect key. It sees the company name agree exactly, which is a strong signal because "Fernwood Supply" is not a common string (low u-probability of agreeing by chance). It sees the city agree. It sees the surname "Diaz" agree, and it scores "Maria Alonso-Diaz" against "M. Diaz" with a string-similarity method that rewards the shared surname and initial rather than penalising the missing first name. None of these signals alone would justify a link. Combined, in a Fellegi-Sunter style weighted sum, they cross the threshold, and the pair resolves into one entity, with both original records preserved as evidence underneath it.

That's the mechanism our own agent was missing. Not a magic AI feature. A weighted combination of ordinary, individually weak signals, formalised more than fifty years ago and still running under most of the identity layer any of us touch today.

Sources

1. Fellegi, I.P. and Sunter, A.B. (1969). "A Theory for Record Linkage." Journal of the American Statistical Association, 64(328), 1183-1210.
2. Winkler, W.E. (2014). "Matching and Record Linkage." WIREs Computational Statistics.
3. Winkler, W.E. "Matching and Record Linkage" (working paper rr93-8), US Census Bureau.
4. Wikipedia. "Record linkage" (Fellegi-Sunter model, m/u-probabilities, decision regions).
5. Wikipedia. "Levenshtein distance."
6. Oracle Financial Crime and Compliance Management. "Jaro-Winkler matching guide."
7. West Penwith Local History Group. "Soundex - the True Story" (Odell and Russell, 1918 patent).
8. Binette, O. and Steorts, R.C. "(Almost) All of Entity Resolution." arXiv:2008.04443.
9. Zingg. "Entity Resolution at Scale, Part 3: Blocking."
10. Aerospike. "Achieving the Perfect Golden Record with Graph Data."
11. US Department of the Treasury, Office of Foreign Assets Control. "A Framework for OFAC Compliance Commitments" (2019).
12. Fivetran. "Identity vs Entity Resolution in B2B Tech and Retail."
13. CX Today. "AI Hallucinations Start With Dirty Data: Governing Knowledge for RAG Agents."
14. Tilores. "What Is Entity Resolution? A Practical Guide for AI, KYC and Customer 360 (2026)."
15. Schmitdy Gadget. "Entity Resolution, Explained." YouTube.