Best practices for agentic entity resolution and unified profiles: a field guide for entity resolution teams

If your company sells data, the unified profile is the product. A customer who buys company or person data is buying one record per entity that they can join to their own systems and trust. Customers notice two failures quickly: two entities merged into one (a false merge), which is a defect they can dispute, and one entity split across two profiles (a false split), which is coverage they thought they paid for.

The mandate for a Head of Entity Resolution or Master Data is to raise coverage and accuracy together, release after release. The trap is that every re-match run changes records customers already use, while the checking is still a hand sample, the rules still live in a stored procedure, and the stewardship queue only grows.

Our view: the work that keeps a profile correct is repeatable, so agents should do it, and people should keep the judgment calls. This field guide, the companion to the team playbook, judges each practice by what it does to the profile you sell. It serves teams across the data businesses family and the master data teams inside enterprises that resell what they know.

The old world

It is 08:15 on a Monday. On Thursday an engineer edited a name-matching rule so that trading names and legal names would link. Friday's run rebuilt profiles from fourteen suppliers, the team checked forty merges by eye, and the release went out. Now a bank customer reports that two subsidiaries have become one profile and their onboarding checks are flagging a clean counterparty. Someone finds Friday's run, works out which rule and which supplier records joined, and replies on Wednesday. Nobody can say how many other pairs the same rule merged. A person has also asked for their record to be removed, and the profile blends fields from four suppliers with four different notices.

The new world

Same week with Data Workers. The rule edit arrived as a reviewed diff with tests. Before Friday's run published, Quality Monitoring compared it with the last release and saw merges up sharply in one country. The Data Context & Catalog agent listed the profiles and three customer feeds that would change, and Autonomous Data-Conductor held that country's records and sent the data steward one decision with the evidence. She narrowed the rule and the release shipped on time. The bank never saw the merge, and the erasure request was traced to every supplier record behind the profile.

The same hand-offs, for a different trigger (a supplier changes its identifier format):

The 7 practices below make a week like that possible. At a glance:

The practices, one by one

1. Ship every re-match as a release, with a baseline

A re-match changes profiles customers already hold, so it deserves a release's discipline: a candidate, a comparison with the last release, and a decision.

Why it's harder than it looks: a hand sample covers a sliver of millions of profiles. A rule edit rarely breaks everything; it shifts a few thousand records in one country or supplier, exactly where forty sampled merges do not look. Teams also change a rule and add a supplier at once, so nobody can say which moved the numbers.

1. 1.The Pipeline Building agent builds each change to your matching pipeline as a diff with generate_pipeline, tests it with validate_pipeline, and only then deploys with deploy_pipeline.
2. 2.The Quality Monitoring agent runs run_quality_check on the candidate against the last release: match rate, merges, splits and duplicates.
3. 3.The Data Context & Catalog agent runs blast_radius_analysis to list the profiles and feeds that would change, so the release notes write themselves. Autonomous Data-Conductor holds only the records that moved.
4. 4.The data steward approves or narrows the change. An unexplained shift always reaches her.

What to measure. Releases that ship with a comparison attached.

2. Catch supplier changes the day they arrive

Suppliers change identifier formats, country fields and name conventions without telling you. The file still arrives on time with every column in place, so nothing fails.

Why it's harder than it looks: a schema alert stays silent because the schema is intact. The change is in the values, and the symptom is a match rate that sags while duplicates pile up.

1. 1.The Connectors and Data Ingestion agents register each delivery against its schedule, with get_connector_status. The Schema Evolution agent runs detect_schema_change and assess_impact on layout changes.
2. 2.Quality Monitoring watches each supplier's match rate and new-profile creation with get_anomalies, and set_sla records the freshness you promise.
3. 3.The Incident Debugging agent runs get_root_cause to name the column that changed, and Pipeline Building drafts the mapping fix and tests it with validate_pipeline against last week's file.
4. 4.The data steward approves the mapping for that supplier. Other suppliers are not held.

A per-supplier contract in an open format makes this stricter: see data contracts and AI agents and Inside the Schema Evolution Agent.

What to measure. Hours from supplier change to a tested mapping.

Across the routine work these practices cover, here is the difference in elapsed time:

The biggest change is tracing a disputed merge, from about two days to ~15 min, because agents detect, trace and verify in one pass.

3. Measure match quality per supplier and entity type

A single global match rate hides the problem: thirteen healthy suppliers average out one broken one.

Why it's harder than it looks: a rule that merges too eagerly raises match rate while creating false merges, and a cautious one lowers it while creating false splits. You need the rate, duplicate and merge counts and a steward-measured sample of true errors, read together by supplier.

1. 1.Quality Monitoring learns each supplier's normal behaviour and flags departures with get_anomalies, and keeps a running view with get_quality_score.
2. 2.create_quality_tests_for_pipeline writes the tests a new supplier or entity type needs, ready as a pull request against your dbt project.
3. 3.The steward's periodic sample, which defines false merge and false split for your product, stays the reference. Agents report it next to the monitoring so the two are read together.
4. 4.The Data Context Wizard holds one governed definition of match rate, false merge rate and coverage, so a release report and a customer data sheet quote the same number. The Head of Entity Resolution signs off any change to a definition.

What to measure. Suppliers within their own normal range; the steward-measured error rate by entity type. Quality monitoring in general is covered in Inside the Quality Monitoring Agent.

4. Write survivorship rules down, with an owner

Survivorship decides which supplier wins each attribute: address, headcount, phone, legal name. It is the most consequential logic in the profile and the least documented.

Why it's harder than it looks: the rules sit in code one or two people understand, and they interact: adding a supplier changes which fields it wins without anyone deciding that. When a customer asks why a value is on the profile, the answer is an investigation.

1. 1.The Data Context & Catalog agent runs import_tribal_knowledge to pull rules out of the code, documents and conversations where they live.
2. 2.It records each with define_business_rule, with an owner, and keeps it current with update_business_rule.
3. 3.Any proposed change arrives as a diff with the profiles and attributes it would change, using blast_radius_analysis.
4. 4.generate_documentation gives each attribute a plain-English page in Spellbook Data Catalog. A named data steward approves every survivorship change; no agent edits a rule on its own.

What to measure. Share of profile attributes with a documented rule and a named owner. The wider practice is in AI data stewardship.

5. Trace every dispute to the rule, then fix it everywhere

A customer's dispute is information about a rule, not just about one pair of records.

Why it's harder than it looks: the evidence is spread across run output, rule versions and supplier files. Teams answer the ticket and close it, the rule stays in place, and the next customer finds the next pair.

1. 1.The Incident Debugging agent opens the dispute with diagnose_incident, names the run, rule and source records with get_root_cause, and checks with get_incident_history whether this rule or supplier has been involved before.
2. 2.The Data Context & Catalog agent runs trace_cross_platform_lineage for the path from each supplier record to the profile, then blast_radius_analysis to list every other profile the rule touched, so one dispute becomes one fix.
3. 3.The steward gets the evidence, a proposed split and the list of other affected profiles. A named approver decides, because a split changes what customers already hold.

What to measure. Time from dispute to traced cause; disputes caused by a rule already seen.

6. Carry consent and provenance per attribute

A person profile blends fields from suppliers with different notices and permitted uses. When someone exercises a right, you need to know what is behind each field.

Why it's harder than it looks: merging erases the boundary between sources. Under the GDPR, personal data must be accurate (Article 5(1)(d)), can be corrected (Article 16) or erased (Article 17), and obtaining it from someone other than the individual brings notice duties (Article 14); see the regulation text. Each reaches back to every supplier record in the profile.

1. 1.The Data Access & Governance agent runs scan_pii before a source reaches the shared layer and check_policy against the terms recorded for it.
2. 2.The Data Context & Catalog agent tags what it finds with auto_tag_dataset and keeps attribute-level lineage current.
3. 3.When a removal or unmerge request arrives, trace_cross_platform_lineage finds every supplier record behind the profile and blast_radius_analysis lists the feeds that carry it.
4. 4.request_governance_review routes the decision to a named approver; a source with an unclear basis is held out of the shared layer. generate_audit_report exports the evidence for the response.

Data Workers supplies controls and evidence; your people and counsel decide what is allowed. See PII detection and masking.

What to measure. Hours from a data subject request to a complete list of affected records.

7. Put uncertain matches and rule changes in front of a named steward

Autonomy stops where judgment starts: the uncertain match, the rule change, the unmerge.

Why it's harder than it looks: stewardship queues are ordered by arrival, so cases that need judgment sit behind routine ones, and reviewers decide without the evidence. The answer is to hand the person a case ready to decide.

1. 1.Quality Monitoring and Incident Debugging attach the records, the evidence and the likely consequence of each choice. The Data Context & Catalog agent adds the rule behind each candidate and what else it touched.
2. 2.Autonomous Data-Conductor routes each item to the named steward for that entity type and escalates anything unanswered.
3. 3.The steward decides. Every decision leaves a signed receipt with who approved it and how to undo it, and corrections are remembered so the same wrong call does not recur.

Autonomy is earned per task class, as the share closed without a person shows:

Catalog and docs upkeep closes autonomously 88% of the time. For survivorship rule changes, autonomous closure is 0% by design: every change is proposed with a full diff and approved by a named steward.

What to measure. Median time an uncertain match waits; decisions with a named approver on record.

Designing the autonomy ladder

L0 to L2 (watching, suggesting and acting after a named person approves) run today. L3 and L4 are where a domain can go on its own review record, never everywhere at once. Here is where we would set each class:

The operating model: who owns what

Agents change who does the work, not who is accountable:

The swarm behind the practices

Each practice is a hand-off between specialists, coordinated under the autonomy you set per entity type.

Autonomous Data-Conductor holds the records that moved and routes decisions to the steward. Data Context Wizard holds one governed definition of each measure you sell. Spellbook Data Catalog gives each entity type, attribute and supplier a page in plain English. The matching itself stays yours, in your warehouse or your MDM tool; if you run one, see how this sits alongside Ataccama.

What disappears

The clearest sign the practices are working is what stops happening:

• •The release that ships on a sample of forty.
• •The Monday wave of duplicates after a supplier changes a format.
• •Days of log archaeology per disputed merge.
• •Survivorship rules that leave with the engineer who wrote them.
• •Consent provenance rebuilt on request.
• •A stewardship queue ordered by arrival.

The magic is not any single agent: drift is caught at the supplier's door, every rule has a page and an owner, and every action leaves a signed receipt so the team can see what happened and undo it. For the people on the team, the experience is quieter Mondays and a week spent on coverage.

A Head of Entity Resolution's scorecard

If you own the profile as a product, these are the targets to bring to every quarterly review, set as goals against your own baseline:

• •False merge and false split rate by entity type, as your stewards sample them
• •Match rate by supplier, against its own normal range
• •Share of re-match runs released with a comparison attached
• •Time from dispute to traced cause
• •Share of attributes with a documented rule and a named owner
• •Coverage lift per new supplier, and supplier delivery to changed profile
• •Share of upkeep closed autonomously, and its token cost

The climb: from assisted to autonomous to agentic

Our thesis is that the data platform climbs the way analytics did, in stages, and that the hard part of data work was never knowing what to do but doing it. For entity resolution teams:

• •Assisted. Agents read every supplier feed and release, show what needs doing and propose every fix with a receipt; uncertain matches and survivorship changes go to a named steward.
• •Autonomous, under your governance. Routine work runs on its own: runs are compared with the last release, suppliers are watched and disputes traced. Your team governs the agents instead of doing the upkeep.
• •The agentic data business. A team that improves the profile instead of defending the last run. People set direction; the platform carries it out.

You choose the altitude, every step is visible and reversible, and the pilot below is the first rung. Practices 3 and 5 build on data quality on autopilot and end-to-end lineage; profiles also feed data delivery and feeds and are sourced through data acquisition and sourcing.

The pilot: how entity resolution teams start

• •Scope. Release checks on the nightly re-match plus dispute tracing for one entity type (companies or people), at L2.
• •What we connect. Your supplier drops, Snowflake or Databricks, dbt, Airflow or Dagster and the delivery layer, over MCP, in your infrastructure. Nothing migrates; the matching stays yours.
• •First week. Agents run at L1 across the scoped routines. They profile every supplier delivery, map lineage from supplier records to profiles and show the comparisons and traces they would have run, with receipts, before anything changes.
• •By week two. Run-to-run comparison, per-supplier monitoring and documentation upkeep start running on reversible work. Matching changes, survivorship rules and personal data stay at L2 with a named steward.
• •At day 30. We review the impact metrics against your baseline:

• •Disputed merge traced to its rule and source records: from about two days to ~15 min
• •Match-rate drop traced to its cause: from about three days to under an hour
• •Re-match checked before release: from about two days to about an hour
• •the share of catalog and docs upkeep closed autonomously, targeting 88% as the deployment matures

• •What you decide. Whether to expand to the next entity type. The pilot fee is credited in full against the first year.
• •Guarantee. In a 90-day pilot, ten engineering hours per data engineer per week are recovered against a baseline both sides sign on day one, or the $7,500 fee is refunded.
• •Cost. Start with a pilot ($7,500 one time, a 6 to 12 week pilot, credited in full against the first year). Scale is from $1,000 a month and Enterprise from $3,000 a month, billed annually, with unlimited seats, no usage meter and no markup on model spend. See pricing.

The pilot is the start of a longer curve:

By month 12 in this illustration, more than 42% of agent actions run fully autonomously and manual work falls below 10%, while uncertain matches and survivorship rules stay with a named steward.