In part 4 of the Agentic CDP series I made a claim and then moved on rather quickly.

Identity resolution stops being a data-team hygiene project and becomes a precondition for anything agentic being trusted with a budget.

That deserved more than the paragraph it got, so here is the longer version.

Your agentic CDP will optimize whatever you measure

Every agentic CDP will be sold on goals-based marketing. That assumes a goal an agent can chase and a signal fast enough to learn from. Most teams have neither.

Martech Therapy: CDP strategy and agentic AIMatthew Niederberger

There is an awkward footnote I need to address first.

I have also argued, in the Contextual CDP series, that memory rather than identity is what makes context work.

I still think that holds, but memory has to attach to something.

An agent that remembers three separate people who happen to be the same customer does not have a memory problem.

Basically, the memory is fine. What it is attached to is wrong.

And that failure is a sneaky one to miss.

A human skimming a weekly report smooths over a fractured profile without noticing they are doing it.

An agent takes the misattributed outcome at face value, decides a channel underperformed, and moves the budget away from it.

Confidently. Every single day.

The usual reason given for caring about any of this is that third-party cookies are going away. They are not.

Google abandoned deprecation in July 2024, dropped the choice prompt in April 2025, and retired most of Privacy Sandbox in October 2025. Safari, Firefox and Brave still block, so roughly a fifth of traffic behaves as though the deprecation happened and the rest carries on as if nothing happened.

The cookie survived and its standardized replacement died, which leaves a set of proprietary identity products acting as the interoperability layer for everyone else.

Either way, the question underneath has not changed. Somebody has to decide that these two records are one person. This piece is about who that somebody is, and what you give up depending on the answer.

Agentic AI in Martech: The billion decision problem

Part 1: Why scale changes everything about AI in Martech

Martech Therapy: CDP strategy and agentic AIMatthew Niederberger

Identity resolution is two jobs

The first job is match: deciding which records belong to the same person.

The second is merge: deciding what that person's attributes are once you have decided the records belong together.

Most of the marketing in this category is about matching. Most of the pain in production is about merging.

Matching gets the attention because it has the interesting math in it. Merging is where somebody has to sit down and decide which of three disagreeing postal addresses survives, and why. Look, nobody said this would be easy.

One interesting find was that Amperity publishes its precedence order, which I appreciate, because it makes the shape of that work visible:

• completion score first
• then source priority
• then field priority
• then recency.

Four rules applied in order, and every one of them is a business decision that someone in your organization is qualified to make but probably has not been asked to.

This distinction matters commercially, because tools split on it.

Zingg's open-source edition does the match half and stops. It appends a cluster identifier and a confidence range to your input rows and hands them back. No golden record, but survivorship does appear in the enterprise edition.

That is not a criticism of Zingg. It is a warning about how the option gets discussed in a planning meeting, where "we could use the open source one" is really "we could build the second half ourselves".

You say potato, I say potato

As with a lot of confusion in Martech, it comes down to understanding the taxonomy. Let's dive in.

Deterministic matching means exact agreement on a shared identifier.

Same hashed email, same customer number, same loyalty card. It is cheap, explainable, and defensible in front of a regulator. It also misses everything that does not share an identifier, which in most organizations is a considerable amount of everything.

Probabilistic matching scores similarity across attributes and calls it a match above some threshold.

Sarah Jones at 12 Oak Street with a typo in the postcode is probably the Sara Jones at 12 Oak St. It finds what deterministic misses and occasionally finds things that are not there.

Just like anything Martech, almost nothing serious is purely one or the other.

Hybrid is the honest description of most production systems: deterministic rules do the easy work and narrow the field, then similarity scoring runs on what is left.

Amperity's Stitch works this way, rule-based blocking followed by pairwise machine learning. Tilores runs configurable matchers with probabilistic available rather than assumed.

Even the vendors who lead with AI are usually running rules first, because rules are fast and most matches are easy.

Then there is batch against real-time, where buyers get misled without anyone intending it. A vendor can offer a very fast profile lookup while rebuilding the identity graph once a night.

Amperity is the clean example: the Profile API returns quickly because it reads a precomputed index, and the graph behind it is rebuilt daily. A real-time query of a batch decision, and perfectly reasonable engineering.

Not the same thing as resolving identity as the event arrives, which is what Tilores does at around nine milliseconds at the ninety-fifth percentile on a million records, in its own published benchmark.

Whether you need the second one comes down to whether a decision has to be made while the customer is still on the page.

Right-time marketing and the speed of context decay

“Real-time” hides three different clocks. What it means from a data warehouse, why context decay is the real metric, and where five CDPs draw the line.

Martech Therapy: CDP strategy and agentic AIMatthew Niederberger

Let's move on to the following question:

How many sets of rules can you run at once?

I have sat through a lot of these demos and presentations, and can honestly say that I do not remember it coming up.

That needs to change.

The rules that should govern a marketing suppression list are not the rules for a service desk lookup, which are not the rules for a fraud check.

• Suppression wants to over-merge, because if in doubt you treat them as the same person and do not send the email twice.
• A service desk wants the opposite, since showing one customer another customer's order history is a considerably worse outcome than making someone repeat their postcode.
• Fraud wants a third thing again, links between people that marketing must never act on.

Give all three teams one graph and somebody has to decide which of them is right, after which the other two go off and build workarounds. Admit it, it happens.

More tools support this than I expected when I went and checked. Hightouch will run a separate identity graph per matching strategy, each with its own models, identifiers and rules. Treasure Data AI lets you declare multiple canonical IDs and multiple master tables in a single unification file. Tilores splits it further again, keeping separate rulesets for indexing, linking, searching and deduplication. Salesforce Data Cloud supports more than one ruleset per object and then recommends against it, on the grounds that maintaining two rulesets per object increases what you are billed for identity resolution. An unexpected honest move.

The capability is mostly there. What varies is the price of using it, in license, in compute, and in the modeling work of keeping two definitions of the same customer that are supposed to disagree with each other.

If you take one procurement question away from this piece, make it that one. Ask how many identity rulesets the tool supports, and what the second one costs.

Five ways to answer the question

I have ordered these by how much of the matching logic you own, from least to most. That ordering is the argument of the piece.

The five are positions on a line rather than boxes with products in them. Nothing serious is purely one archetype, the same way nothing serious is purely deterministic or purely probabilistic.

Amperity runs a managed platform and also writes its results back into your warehouse. Meiro sells a packaged product that deploys in your own cloud, in whatever region you name. Expect most tools to sit between two of these.

Let's take a look at some of the most common identity resolution approaches.

The rented graph

You send hashed identifiers to a vendor and get back a stable pseudonymous key that also exists inside the ad platforms and publishers you want to reach.

LiveRamp is a reference implementation here.

The value is real and hard to replicate because you get to reach into destinations you do not control. The catch sits in their own terms of service, which state that LiveRamp owns the software and technological functionality that establishes and enables the linkage.

You own the data.

You rent the join.

The identifiers are not portable, and the graph refreshes monthly, so what you hold decays if you stop paying.

The embedded graph

Identity often arrives as a feature of something else you bought.

Every packaged CDP and most engagement platforms have one. You configure it in a settings screen, it works reasonably well on the data you loaded into that tool, and the resolved graph does not leave the product.

This is a perfectly good answer for a lot of organizations, and the composable crowd is dismissive about it. What you accept is that the rules are configurable within limits you did not set, and that the graph belongs to the platform rather than to you. Replace the platform and you replace the graph.

The managed matching platform

Here identity is the product rather than a feature of something else, and Amperity is the one to picture.

Hybrid matching, operated by the vendor, with confidence categories from zero to five, pairwise strength scores and a cluster graph you can inspect. You can tune it, but overriding an individual match decision by hand is not documented anywhere. You can see what the system did and adjust the dials without ever writing the rule.

For a lot of large organizations that is the right trade, because writing the rule yourself means somebody owns it forever, including the quarter after they resign. Check whether the tuning surface goes deep enough for your hardest cases.

The engine you point at your own data

You author the rules, you can read them, and the result lands somewhere you can query.

Two quite different approaches live here.

The first is a dedicated resolution service. Tilores is the example, a GraphQL API over a serverless stack you deploy into your own AWS account. The rules are JSON configuration you own, and resolution happens as records arrive rather than overnight.

Can identity resolution work without AI? Steven Renwick from Tilores explains

Tilores’ CEO explains why rules still rule, and how GenAI plays a supporting role in identity resolution, not the starring one.

Martech Therapy: CDP strategy and agentic AIMatthew Niederberger

The second is the warehouse-native activation layer, where I was wrong when I started researching this piece. I had assumed Hightouch, RudderStack and GrowthLoop were doing lightweight embedded identity. All three write the resolved graph back into your warehouse as tables you can query, and all three do survivorship rather than just matching.

Hightouch is transparent by default, with one exception. Its probabilistic tier does not run in your warehouse. It moves your data out to an external cloud storage bucket, runs a vendor model against it, and gives you three settings:

Exact, Strict, Loose.

That is the whole configuration surface. Business tier, contact sales. Switch that one feature on and you have moved, inside a single product sitting at the ownership end of the scale, some distance back toward the rented end.

How Snowflake recruited Zeotap’s composable CDP

Zeotap’s composable CDP now runs inside Snowflake as a Native App. Snowflake recruited it, the way Databricks built CustomerLake.

Martech Therapy: CDP strategy and agentic AIMatthew Niederberger

Build it yourself

Zingg, dbt models, graph algorithms, or some combination of the three. You own all of it, including the operating burden. The open-source edition of Zingg is AGPL, probabilistic only, needs roughly thirty to forty labeled positive examples to start, and runs on Spark in batch. Deterministic matching, persistent identifiers, incremental runs, explainability and survivorship all live in the enterprise edition.

Which produces an awkward moment in the buying conversation.

Either you build the missing half or you buy the enterprise license, at which point the reason you chose open source has evaporated.

If you are betting on the warehouse solving this for you, check which warehouse you are on. Databricks announced CustomerLake with Agentic Identity Resolution in June 2026, in private preview. Snowflake has no first-party identity product at all.

How you pay for it belongs in this section too.

If a vendor is listed in your cloud provider's marketplace, buying through it draws down against a commitment you have already signed, so nobody has to write a new budget case.

The programs are not equivalent.

Google Cloud draws down at the full hundred percent of eligible spend against your minimum commitment, Databricks caps its drawdown at ten percent, and Snowflake requires enrollment and does not publish a percentage.

I have recently sat in several of these conversations to know that difference can settle a shortlist before anyone opens an architecture diagram, which is a strange way to choose an identity layer and completely understandable at the same time.

A note for the B2B readers

Everything above assumes the entity is a person. Life is just not that simple.

In B2B the unit that matters is usually the account, which turns one resolution problem into three, and the third changes every time somebody moves job. Most tools built for consumer marketing treat account as an attribute rather than an entity, which is the specific thing to test in a proof of concept rather than assume.

Nobody has the answer key

You cannot measure identity resolution accuracy, because measuring it would require already knowing which records are the same person, and if you knew that you would not need the system.

So everything is a proxy, and there are two ways to be wrong.

• Over-merging collapses two people into one.
• Under-merging leaves one person as two.

Every threshold trades one against the other and no setting avoids both, which is why the multiple-rulesets question earlier is more than a technical detail.

It is also why "match rate" is close to useless as a comparison metric, and why it is the number vendors lead with. A high rate can mean the system is finding real connections or that it is over-merging enthusiastically. LiveRamp, to its credit, publishes the trade explicitly. According to LiveRamp, there is a 99.5% match on full personal information, 89.8% on email alone, and a stated policy of accepting less scale than probabilistic competitors in exchange for deterministic accuracy.

What you can do instead is build a small labeled set by hand, a few hundred record pairs your team has looked at and judged. It is dull, it takes an afternoon or two, and it will tell you more about a shortlist than any vendor can truly promise.

Zingg requires labeled pairs before it will run at all, which is inconvenient but refreshingly enough also the most honest thing about it.

What actually separates these

Read back over the five and the technical differences start to look secondary.

Deterministic against probabilistic is a tuning decision, batch against real-time is a use case decision, and both are answerable in a single afternoon.

The choice is who owns the logic that decides two records are one person, and whether anyone in your organization can inspect it.

Which is why the Hightouch detail matters more than its size suggests. Ownership turns out to be a property of the feature you switched on rather than of the vendor you picked. You can buy a transparent tool and opt into opacity with a checkbox, and nothing in procurement will flag that you did.

The agentic version of this is why I wrote the piece.

An agent that reallocates budget daily is making decisions on resolved profiles, so if nobody can explain why two records were joined, nobody can explain why the budget moved.

You have automated the decision and outsourced the premise, and the audit trail stops at a vendor's confidence score. That is a governance problem.

Where to start

Not with a vendor shortlist, but with these 4 steps 👇🏻

Start with how many identity rulesets your use cases actually need, because that number decides which options are viable at all, and it is usually more than one.

Then ask whether resolution has to happen while the customer is on the page or whether last night's answer is fine, which halves the list again. Work out whether you are buying matching, merging, or both, and write it down in those words so everyone is looking at the same scope.

And check the contract mechanics before the architecture debate, because a ten percent drawdown cap and a hundred percent drawdown produce different shortlists.

The next customer record that arrives at your organization will be matched to something by somebody's rules. Worth knowing whose.