Entity resolution is the unglamorous majority of the work.

The same customer is CUST-4471 in the ERP. A different record entirely in the CRM, created by a salesperson who did not know the ERP record existed. An email domain in the inbox. A nickname on site, written on a job sheet by someone who has never once typed the full legal entity name. Until those four things are recognised as one customer, every question an AI system answers about that customer is a question about a quarter of them.

Why this breaks answers quietly

Ask a governed assistant how much a customer owes you, and if the ERP record and the CRM record have not been resolved to one entity, you get one of the balances, not the real one. The answer is not obviously wrong. It looks like a number, formatted like a number, delivered with the same confidence as a correct one. Nobody notices until the invoice is chased twice, or not chased at all, and by then the error has already cost something. This is what makes entity resolution dangerous to skip: it does not fail loudly. It fails as a slightly wrong answer, indefinitely, in a system everyone has started to trust.

Why fuzzy matching alone is not enough

String similarity on a name or a domain catches the obvious duplicates — a typo, a trailing “Pty Ltd” — and that is genuinely useful as a first pass. It falls over on the cases that actually matter: a trading name that is legally a different entity from the one on the contract, a parent company with six subsidiaries that each order separately, a common surname shared by two unrelated households, a customer who was acquired and now trades under a new name against the same billing history. Fuzzy matching cannot tell the difference between a duplicate and a coincidence, and the failure mode is not neutral: a false negative leaves you with two records instead of one, which is annoying but visible. A false positive silently merges two different customers into one, and now your entity graph is confidently wrong in a way that is much harder to find, because it looks resolved.

Why match-at-query-time is the wrong architecture

The tempting shortcut is to run the matching logic live, every time a question comes in, and let the model figure out which records belong together on the fly. This fails for three reasons. It is slow, because similarity scoring across every source system on every query does not scale. It is inconsistent, because the same question can return a different match depending on which records happen to be retrieved first. And it cannot be audited, because there is no durable record of what was matched to what, only a decision that existed for the length of one request and then evaporated.

The alternative is a durable identity mapping: a canonical entity, a crosswalk table that lists every source-system identifier that resolves to it, a confidence score on each mapping, and an effective date. Resolution happens once, when the mapping is built or updated, not on every question. Every answer downstream can then say which canonical entity it used and which source records fed it, which is what lets you actually check the work later.

What a human-in-the-loop resolution workflow looks like

This is not a fully automated pipeline, and pretending it could be is exactly the mistake that produces false positives at scale. It is a graded workflow:

• 01
  High-confidence matches merge automatically

  Exact identifiers, or a combination strong enough that a false positive is very unlikely — a matched tax number plus a matched billing address, say. These merge without a person in the loop, and every merge is logged with what triggered it.
• 02
  Borderline matches go to a queue

  Same surname, similar address, overlapping contact — plausible but not certain. A person sees the two records side by side with the evidence, and confirms, rejects, or splits them. This is minutes of work per case, not hours.
• 03
  Decisions become signal, not one-off fixes

  Every confirm or reject is recorded against the pattern that produced it, so the matching logic gets more conservative or more permissive in exactly the places it has been wrong before, instead of drifting on vibes.
• 04
  High-value entities get a periodic audit pass

  Your twenty largest customers, your highest-risk assets, whatever the entities are that a mistake on would actually hurt — reviewed on a schedule, not only when the automation happens to flag them.

How to know your entity graph is good enough to build on

Three checks matter more than a single accuracy score. First, coverage: what proportion of transactions, jobs or interactions are attached to a resolved canonical entity, versus sitting as an orphaned record nobody has claimed. Second, dispute rate: how often a human reviewer overturns a proposed merge, and whether that rate is falling as the matching logic learns from prior corrections or holding flat because the underlying data is genuinely ambiguous. Third, blast radius: for your highest-value entities specifically, has every source record actually been checked, not just statistically likely to be correct. A graph can be good enough to build a reporting dashboard on before it is good enough to let an agent action a refund against it — the bar moves with what you are about to do with the answer.

This is, honestly, most of the engineering effort in standing up a context layer. It is not the part that demos well. It is the part that determines whether everything built on top of it is trustworthy or merely plausible.

This is the layer Org Brain is built on. If you want to know how resolved your own entity graph currently is, an AI Review scores it as part of the systems and data map.