In short
A company wants to know how much it spent with a supplier during the year. The purchasing system shows one amount, accounts payable shows another, and the difference lies in three records of the same supplier created by different teams over time. Deciding which records represent the same company is called entity resolution, and the quality of any AI answer about suppliers, products or people depends on it. It is also the base of the Company Brain, the layer that knows the company: what data exists, where it lives, how it relates and who can see what.
Entity resolution is the process of identifying which records, in different systems or within the same system, represent the same real-world entity. Deduplication and record linkage are names used for parts of the same problem: removing repeated records within one database and linking records across separate databases.
The problem arises with any entity that more than one system registers:
Entity resolution projects usually follow the same sequence:
A deterministic rule requires an exact match on a reliable identifier, such as the same barcode in the ERP and in the online store, or the same staff number in the HRIS and in the expenses system. It is simple to audit and depends on the identifier being filled in at both ends.
When there is no common identifier, the probabilistic approach comes in. Each attribute gets a weight, and matching on a rare surname counts for more than matching on a common one. The formal basis of this approach is the model published by Ivan Fellegi and Alan Sunter in 1969, with two score thresholds and three possible outcomes. A U.S. Census Bureau report that reviews the Fellegi and Sunter model and blocking techniques describes the range between the thresholds as the zone set aside for manual review.
Entity resolution goes wrong in two ways. The first is splitting what is the same. The supplier keeps three records and the spend shows up fragmented, a visible error because the answer comes out incomplete.
The second is merging what is different. Two suppliers with similar names become a single record, and the delivery incidents of one go into the history of the other. The error is silent, because the result looks like consolidated data.
With AI, the second error weighs more. The model receives the merged entity as fact and writes a coherent answer about a supplier that does not exist, with the delays of one and the contract of the other. That is why thresholds are usually more conservative for merging: a doubtful case sent to review costs less than a wrong link spread to every query.
For each linked pair, the record keeps the rule or score behind the decision, the attributes compared, who approved it in reviewed cases and the date.
Reversibility depends on how the link is stored. When entity resolution overwrites the original records, undoing a wrong merge means rebuilding data by hand. When the source records stay intact and the link lives in a separate layer, the fix consists of removing the link.
Each node of the knowledge graph is an entity that has already been resolved, linked to its source records in each system. Without this stage, the graph would repeat the fragmentation of the systems.
The business ontology defines what counts as the same entity. Purchasing may treat head office and branch as separate suppliers, because the delivery lead time differs between them, while finance consolidates the two to measure total exposure. The link rule follows that definition, and the graph keeps both levels.
When an agent queries the Company Brain via MCP, it receives the entity already resolved, with an indication of the records that make it up. Permissions are inherited from each source system, and the answer shows where each piece of information came from.
No method links records that share no comparable attributes. If one system stores only the name and another only an internal code, the link depends on a third source or on manual registration.
The thresholds need calibrating with people who know the data, and the review queue needs an owner in the business area. The process is also continuous, because every new record goes through the same stages.
The recommended starting point is a recurring question that currently runs into duplicates, such as annual spend per supplier cross-checked against delivery incidents. It defines the entity, the first two sources and the attributes to compare.
The size of the review queue in the first few weeks shows where it is worth fixing the record at the source. The entities resolved in that slice then serve the next use case, which starts from them instead of reconciling everything again.
