Entity Resolution

The same decision shows up under three different names in three different tools. Nothing about the words says they're the same thing. One of Brief's agents exists to say so anyway.

August 19, 2026 6 min read

A team decides to redesign checkout. In the Slack thread where it got argued out, it's "the checkout redesign." In Linear, it's ticket BRI-4821, "revamp payment flow." In the customer call that prompted it, the rep calls it "the new payment experience" three separate times. Three sources, one decision, and not one string of text in common between them. A system reading all three sees three unrelated records, because as far as the words go, that's exactly what they are. A person who sat in on all three conversations would connect them without thinking about it. A system with no memory of its own has no such shortcut, and has to be told, deliberately, that these three things are one thing.

That problem has a name older than any tool now running into it: entity resolution, the task of deciding whether two records from different sources, described in different words, refer to the same real-world thing. Get it wrong in one direction and you split one decision into three untracked fragments. Get it wrong in the other and you merge two different decisions into one, which is worse, because now the record is confidently pointing at the wrong thing.

The theory is older than the problem looks

Statisticians Ivan Fellegi and Alan Sunter gave this its first formal treatment in 1969, in "A Theory for Record Linkage" (Journal of the American Statistical Association, vol. 64). Census bureaus and public-health researchers had been matching people across data sets by hand for decades, deciding by eye whether "J. Smith, 1942" in one file and "John Smith, b. 1942" in another were the same person. Fellegi and Sunter turned that judgment call into a decision rule: compare a pair of records on a set of features, use the pattern of agreement and disagreement across those features to compute a likelihood ratio, and classify the pair as a match, a non-match, or uncertain enough to route to a person. The contribution wasn't the intuition that similar records might be the same thing. It was making that intuition falsifiable, a rule with a known error rate instead of a hunch.

The field built on that theory has gone by a few names since, record linkage, coreference resolution in NLP, and now most often entity resolution, but the shape of the decision hasn't moved: given two descriptions, decide whether they're two views of one thing or two different things that merely resemble each other.

Why it's not just deduplication

The two get confused because they look similar from a distance, and it's worth being precise about the difference. Deduplication finds near-identical copies within one source, the same customer record entered twice with a typo in the second one. Entity resolution is the harder problem: recognizing that two records from different sources, described in genuinely different language by different people through different tools, are about the same underlying thing. "The checkout redesign" and "revamp payment flow" share no words at all. A system built only to catch near-duplicates would never flag them, because they aren't duplicates. They're the same entity, described twice, by people who had no reason to coordinate their phrasing.

What breaks without it

Here's the part that isn't obvious until you look for it: supersession depends on entity resolution working first. Marking a decision "superseded" only makes sense once a system can say two records are about the same decision, an old one and a version that replaces it. Without that link, a new record just looks like a new, unrelated fact sitting next to an old one nobody flagged as outdated. A decision record that stays current, rather than one more entry in a pile that silently drifts out of date, depends on getting this one problem right first.

This is also what turns a set of separate lists into something worth calling a graph, rather than a shared name for several trackers that happen to sit in the same product. A persona pulled from a call, a decision pulled from Slack, a feature pulled from Linear, and a deal pulled from a CRM don't relate to each other on their own. They relate to each other once something recognizes when two of them, described in unrelated language from unrelated tools, are actually about the same thing.

The agent that does this and nothing else

That's the job of Brief's Entity Resolution Agent, one of two agents in the roster that runs without a page you ever visit, because there's nothing to review: it links objects across sources so instances of the same real-world thing, described differently in different tools, get recognized as one thing instead of several. It's the quietest agent on the team, and the parts of the system that depend on knowing which records are about the same underlying thing, supersession chief among them, depend on it having already done that work.

The other agents get the visible credit: features tracked, personas drawn, decisions surfaced. None of what they produce adds up to one coherent picture rather than fifteen separate feeds unless something has already answered a quieter question first. When two of them describe the same thing in different words, does the system know?

Frequently asked questions

What is entity resolution? The task of deciding whether two records, described in different words from different sources, refer to the same real-world thing. Fellegi and Sunter formalized it in 1969 as a decision rule: compare records on a set of features and use the pattern of agreement to classify the pair as a match, a non-match, or uncertain.

How is entity resolution different from deduplication? Deduplication catches near-identical copies within one source, the same record entered twice with small variations. Entity resolution is the harder case: two records from different sources, in genuinely different language, that describe the same underlying thing without sharing any of the same words.

Why does a product context system need entity resolution specifically? Because supersession depends on it. Marking a decision current or outdated only makes sense once a system can tell that two records, an old one and a new one, are about the same decision in the first place. Without that link, a new record just sits beside an old one, and nothing marks the old one as replaced.

What does Brief's Entity Resolution Agent actually do? It links the objects every other agent produces, personas, decisions, features, deals, so instances of the same real-world thing from different sources are recognized as one thing instead of several unrelated records. It runs without a page you visit, because its output is a link between records, not something to review or approve.