Entity Resolution Is Becoming AI Infrastructure, Not Data Cleanup

A while ago I watched an AI agent give a confidently wrong answer for an entirely boring reason. A business had two records for the same corporate customer. One held the old trading name and a finance contact. The other held the new legal name the company had adopted after an acquisition, along with a different billing address. The agent was asked a simple question: is this account in good standing? It found one record, saw no overdue invoices, and said yes. The overdue invoices were filed under the other name.

Nothing was hallucinated. The model reasoned cleanly over the data it was given. The data just happened to describe two customers where there was, in the real world, one. The mistake was not in the language model. It was in the join.

I have come to think this is one of the most underrated risks in enterprise AI, and one of the least discussed. We talk endlessly about model accuracy, prompt design, and governance. We talk much less about whether a system actually knows which real-world customer, supplier, or account it is acting on. That question has a name. It is called entity resolution, and after sixty years in the background it is quietly turning into a piece of live infrastructure.

The problem changed tense

For most of its working life, “are these two records the same entity?” was a cleanup question. You ran it in a batch, on a schedule, somewhere inside a master data management programme, a warehouse, or an analytics pipeline. It was never perfect, but it was survivable, because the output was a report somebody read next week. If two records for the same supplier were not merged, a spend figure came out slightly wrong, an analyst noticed, and it got fixed in the next run. The system had slack in it. Time absorbed the errors.

An AI agent removes that slack. It changes the tense of the question from “eventually” to “now.” When an agent is about to approve a refund, route a case, update a profile, or answer a compliance question, the resolved entity is no longer feeding a dashboard. It is feeding an action. The cost of a wrong join moves from a number that is slightly off to something that happens in the world, immediately, and often with no human in the loop to catch it.

That is the shift worth sitting with. The underlying problem is old and well understood. What is new is that we have wired it directly into systems that act on their own.

A 1960s statistics problem

Entity resolution did not arrive with large language models. It arrived with punch cards. In 1959, H. B. Newcombe and his colleagues published a short paper in Science on the automatic linkage of vital records, describing how a computer could decide whether a birth record and a marriage record referred to the same person. A decade later, Ivan Fellegi and Alan Sunter gave the idea a formal mathematical theory, defining the three outcomes any matching system still produces today: a link, a non-link, and a possible link that a person needs to review.

There is a detail in that lineage worth dwelling on, because it is the part people most often get wrong. Record linkage was never just exact matching on an email address or a shared ID. From the very beginning it was probabilistic. It weighed the evidence that two records agreed on a surname, a date, a place, and produced a score, because human-entered data is messy and exact keys fail constantly. Modern entity resolution still works this way. It combines deterministic rules, where a shared stable identifier is decisive, with probabilistic and fuzzy machine-learning matching that copes with typos, nicknames, transposed fields, abbreviations, and the dozen small ways the same person or company shows up differently across systems. A good survey of the field traces an unbroken line from those 1950s vital records to the clustering and machine-learning methods used now.

What has genuinely changed is when we need the answer. Researchers were writing about resolving entities at query time, rather than purely in advance, well before the current wave of AI. Back then it was an interesting optimisation. Now it is closer to a requirement.

Why agents turn it into infrastructure

Most enterprise AI systems do not answer from the model’s memory. They retrieve. The pattern popularised as retrieval-augmented generation has an agent pull relevant context at the moment of the question and reason over it. This is, on balance, a good thing. It grounds answers in your data rather than the model’s training.

But it carries a consequence that is easy to miss. The agent inherits whatever the retrieval step hands it. If retrieval returns a fragmented customer, three partial records that were never connected, the agent will reason about three customers. If retrieval returns a wrongly merged one, two different companies collapsed into a single profile, the agent will reason about one. The ambiguity already sitting in your source systems is passed straight through and presented to the model as settled fact. The model has no way to know the join was wrong, any more than you would, reading a tidy summary of records you had never seen.

So resolution cannot be an afterthought that runs once a quarter and lands in a separate table. The entity has to be assembled when data is ingested, and the current resolved view of it has to be retrievable at the instant the agent asks. That is a runtime dependency. It behaves far more like a database or an authentication service than like a periodic data-cleaning project, and it has to be designed, monitored, and trusted the same way you would treat any other system your application calls in real time.

The readiness gap nobody is naming precisely

The industry already senses something is missing here. Cisco’s AI Readiness Index 2025 found that 83 percent of organisations plan to deploy autonomous agents, while only about a third feel their infrastructure is genuinely ready for them, and only around a quarter feel equipped to control and govern what those agents actually do. McKinsey’s most recent State of AI survey describes a similar gap from the other direction: roughly 88 percent of organisations now use AI in at least one function, yet most have not scaled it across the enterprise.

When people explain that gap, they tend to reach for two words: data quality and governance. Both matter, and neither is optional. But there is a narrower question sitting underneath them that clean, well-governed data does not answer on its own. Can the system tell which real-world entity a given record refers to, across all the places that record lives, right now? You can hold high-quality data in every individual system and still fail that test, because the failure does not live inside any one system. It lives in the spaces between them, where the same customer wears three slightly different faces.

What to check before you let an agent act

If you treat entity resolution as live infrastructure, you can inspect it like infrastructure. The operational failure modes are specific and testable: split identities that should be one, false merges of records that should stay separate, stale survivorship rules that keep promoting a superseded address, missing persistent identifiers, and agents inheriting source-system ambiguity as if it were resolved truth.

A practical readiness test does not require a new model or a new vendor category. Assemble a ground-truth set of entities you genuinely understand. Run it through the same retrieval path your agent uses, not a separate clean copy built for the demo. Then measure the things that actually decide outcomes: how many false merges and false splits, how the system handles genuine ambiguity, where its confidence thresholds sit, when it escalates to a human instead of guessing, and how cleanly it hands off to your existing master data and governance controls. If a team cannot answer those questions, the agent is acting on an identity it cannot verify, and confidence in its output is misplaced.

None of this replaces master data management, governance, customer data platforms, or the warehouse. Those answer different questions, and they remain necessary. Governance decides what an agent is allowed to do. Entity resolution decides who, or what, it is doing it to. The first is mature in most large organisations. The second is the layer many are about to discover they need beside it, in real time, the moment they let an agent act rather than advise.

The agent I watched did not need a smarter model. It needed to know that two names were one customer before it was allowed to sound certain. As we hand these systems real authority to act, that quiet, sixty-year-old discipline stops being cleanup and starts being load-bearing.