Agentic B2B data: a guide for company and person data teams

Key takeaways

• •Who this is for. The team at a B2B data business that builds and maintains the company and contact records customers buy: names, domains, corporate hierarchies, headcount, industry codes, job titles, emails and phones.
• •The problem today. Records decay every month as people change jobs and companies merge, move and rebrand. Customers find the decay themselves, as a bounced email or a wrong title, and churn on it. Source files change layout without notice, parent-child hierarchies go stale after every acquisition, and every opt-out and deletion request has to reach every copy the company has ever delivered.
• •What changes. Fill rate per field, bounce rate and title accuracy are measured every morning and traced to the source that moved them. A source layout change is mapped the day it happens. A merger is reflected in the hierarchy before the next release. Each deletion request comes with the evidence of where the person's data sits and what was removed.
• •What stays with your people. Opt-outs, deletion requests and anything about consent stay with a named privacy owner. Hierarchy decisions that change what customers have bought stay with the data product owner. Agents find, prepare and evidence; people approve.
• •The result. A company and person data product whose coverage, accuracy and freshness improve every release, and a team that spends its week on new fields, new sources and new segments instead of repairing the last refresh.

The PRD for agentic company and person data teams

This is the requirements document we would write with you for your team. Everything below expands on it.

What going fully agentic and autonomous means for company and person data teams

• •Put your data pipeline on autopilot. Source layout changes are detected and mapped into your raw and normalised layers the day they happen, and every refresh is checked against the shape of a normal one before it reaches a product.
• •Run the data back office without the busywork. The work that fills the week today moves to agents: tracing a bounce complaint back through three joins, rebuilding the fill-rate report for a customer call, mapping a new column from a source, documenting a refresh and compiling the list of every place a person's record was delivered.
• •Scale data without scaling headcount. Ten million companies or a hundred million contacts, each field gets the same checks, documentation and provenance, so the record base you can maintain grows without the team having to.
• •Get the plumbing off your plate. A team that builds new fields, new segments and better matching rather than repairing the last refresh.

Who this is for

The team that turns raw sources into the records a B2B data business sells. At a firmographic and technographic provider, it owns the company record: legal and trading names, domains, addresses, industry codes, headcount and revenue bands, the technologies a company runs, and the parent-child hierarchy that rolls subsidiaries up to an ultimate parent. At a contact or people data vendor, it owns the person record: name, current employer, job title, seniority, function, work email, phone and the history of each. At a sales-intelligence or enrichment provider, it owns the same records plus the matching that lets a customer's CRM row come back enriched.

The titles: Head of Company and Contact Data, Director of Data Operations, VP of Data Quality, Data Product Manager (Company Data), Data Product Manager (Contact Data), a privacy or data protection lead as the named approver, and the data engineers, analysts and data scientists who report to them. These leaders are measured on the commercial metrics of the product: coverage, accuracy, freshness, match rate, delivery and sell-through. The same family has four neighbours. Data acquisition and sourcing brings the raw material in, entity resolution and unified profiles decides which records are the same company or person, data delivery and feeds gets the product to customers, and data coverage, accuracy and evaluation measures it. Two existing pages sit beside them: people and labor-market data for workforce datasets, and market and reference data for the buy side of vendor files. All of them are gathered on the data businesses page. This page is about the records themselves.

The product you ship

• •The company record: legal and trading names, domains, addresses, industry codes, headcount and revenue bands, founding and status, with a stable identifier that survives rebrands and moves.
• •The hierarchy: which entity is a subsidiary of which, who the ultimate parent is, and how the tree looked on any past date, so a customer's account rollup does not change underneath them without notice.
• •The technographic layer: the technologies each company is observed to run, with the date of the last observation.
• •The person record: name, current employer, title, seniority, function, location, plus the job history that tells a customer when someone has moved.
• •Contact points: work emails and phones, each with a verification status and a last-verified date.
• •Delivery formats: the API, the bulk file, the warehouse share and the CRM integration through which customers receive all of it, each of which is a copy that opt-outs and deletions must reach.
• •Provenance and suppression: for every person, where the data came from, the notice and basis it was collected under, and the suppression list that keeps removed people out of every future release.

Where the week goes

• •Records decay every month. People change jobs, leave companies, take new titles and change email addresses. Companies are acquired, rename, relocate and close. Nothing in the pipeline fails; the product just gets a little less true each day, and the customer finds out first.
• •Customers measure the product by bounce rate. A bad email costs the customer a sender reputation and a rep's time. The first signal is usually a complaint, or a renewal that does not happen, and tracing it back to a source takes days.
• •Hierarchies break after every acquisition. A parent absorbs three hundred subsidiaries, a name changes, a holding company is inserted. Roll-ups of headcount and revenue stop adding up, and customers who segment by parent see a different account list than last quarter.
• •Source layouts change without notice. A renamed column, a new industry code list, a changed date format, a title field that goes quietly empty. Fill rate falls for a week before anyone looks.
• •Titles and industries are messy. "VP, Sales", "Vice President of Sales" and "Head of Revenue" need to land in the same function and seniority, and the mapping has to hold when a source adds a new variant.
• •Opt-outs and deletions must reach every copy. A request arrives, and the person's data may sit in the master tables, the derived products, the bulk files already sent, the shares and the customer-facing API. Finding all of it, removing it, keeping the person suppressed in future refreshes and proving it was done is the slowest, most careful work on the team.
• •Evidence has to be ready. Regulators, customers' procurement teams and partners ask where a record came from and what basis it was collected under. The answer lives in spreadsheets.

Add it up and upkeep is most of the team's week. Here is how a typical week splits today, and once agents own the back office:

Time spent on new data products, which for this team means new fields, new sources and new segments, moves from 14% of the week to 48%. Most of the rest becomes review: people steer and approve agent work instead of doing it by hand.

Then and now

These are the impact metrics we move for company and person data teams:

• •Source layout change mapped: from about three days to under an hour
• •Bounce spike traced to its source: from about a week to ~30 min
• •Deletion request evidence pack: from about a day to ~1 h

Across the routine work in this domain:

The biggest change is the bounce spike traced to its source: from about a week to ~30 min. Work that waited in queues finishes in minutes or hours, because agents detect, fix and verify in one pass.

Use cases, in depth

A deletion request reaches every delivered copy

Today. A person asks to be removed. Someone searches the master tables, then the derived products, then the list of bulk files and shares that went out last quarter. The search misses a table that was copied for a data science project. The person is deleted from the product and reappears in the next refresh because the suppression list was not applied upstream.

With Data Workers. The Data Access & Governance agent finds every table and field that holds the person's data, using its personal-data scan rather than a hand-kept inventory. The Data Context & Catalog agent follows lineage to every product, feed and share that carries the record, and lists which customers received it. The evidence pack goes to the privacy owner as one request: where the data sits, what removing it touches, what the suppression list change would be. After the owner approves, the Connectors agent triggers your existing suppression and deletion jobs in each system, and the audit report records what was removed, where and when.

What changes. The privacy owner makes the decision on complete evidence, and the person stays out of every future release. The decision is theirs; the legwork is not.

An acquisition is reflected in the hierarchy before the next release

Today. A large company announces it is acquiring a group with three hundred subsidiaries. Customers who segment by ultimate parent will see their account lists change. Someone edits the hierarchy table by hand, rolls up headcount and revenue in a spreadsheet to check it, and ships the change in the next quarterly rebuild. A week later a customer asks why last month's list and this month's list differ.

With Data Workers. The Data Context & Catalog agent lists the products, fields and feeds that carry the old parent and the customers who receive them. The Pipeline Building agent drafts a versioned hierarchy update, so the old structure stays available for comparison. Quality Monitoring checks that headcount and revenue roll up, and that no child record is left without a parent. The change goes to the data product owner as a diff, with the customers affected and a rollback point.

What changes. A merger shows up in the product when it happens, with the previous tree kept, and the release notes write themselves from the diff.

The contacts most likely to have moved are re-verified first

Today. Re-verification is a calendar. Every contact is re-checked every so many months, whether or not anything suggests it has changed, and the budget for verification calls runs out before the segments customers care most about are covered.

With Data Workers. The Quality Monitoring agent keeps a running view of freshness by segment: last-verified date, bounce feedback from customers, share of records with a recent job-change signal. The Connectors agent schedules your existing verification runs for the segments where freshness is falling fastest, and the Data Context & Catalog agent checks that the freshness definitions on the product sheet match what the pipeline measures. Verification results flow back through the same checks.

What changes. Verification spend follows risk instead of the calendar, and the freshness number in the sales deck is the same number the pipeline reports.

Measure the product, not just the pipeline

Company and person data leaders are measured on what the product sells, not on how many tables ran. The Autopilot dashboard shows how much of each field's upkeep runs on its own and at what token cost. Alongside it, the team can track what customers and the board care about:

• •Coverage: fill rate per field, by segment, region and company size, and the lift from each source.
• •Accuracy: bounce rate on delivered emails, title accuracy against a reference sample, and agreement between sources.
• •Freshness: time since last verification, time from a job change in the world to a change in the record, and time from a source delivery to a live release.
• •Entity resolution: the share of incoming records that resolve to one company or person, and the rate of wrongly merged or split records, which is where entity resolution picks up.
• •Delivery and sell-through: which customers received which release, which feeds are behind, and which customer segments are buying the fields that are slipping, which is where data delivery and coverage and accuracy evaluation pick up.

Data Workers is the operating layer under those numbers. Its Data Context Wizard holds one governed definition of each, so the figure in the sales deck, the customer data sheet and the board report is the same figure, with the source for each fact shown.

Agents working together: a bounce spike on a Tuesday morning

Every contact data team knows this week. Customer bounce feedback arrives overnight and one segment, mid-market companies in one region, is bouncing at roughly twice its normal rate. Email fill rate on that segment looks normal, because the addresses are there. They are just old. The weekly bulk file ships on Wednesday. This is the same Tuesday run by Data Workers.

The setup

The team sells a contact database through an API and a weekly bulk file. Contacts are built from three licensed sources and the company's own verification runs. Customers send bounce feedback back through a portal. Autonomy in Autopilot:

• •Delivery checks, fill-rate reporting and catalog upkeep: L2 today; a candidate for L3 on evidence.
• •Scheduling re-verification runs: L2 today; a candidate for L3 on evidence.
• •Holding records out of a release: L2, held for the data product owner.
• •Opt-outs, deletions and consent questions: L2, held for the privacy owner.

The team scheduled one mission earlier: "Compare customer bounce feedback with fill rate and source mix for every delivered segment each morning."

06:00: the feedback arrives

The overnight bounce feedback lands from the customer portal. Connectors agent logs the load against its schedule.

06:05: flag it

Quality Monitoring agent sees the bounce rate for one segment at about twice its normal level. Email fill rate for the segment is unchanged, which is why a fill-rate dashboard never raised it. The mission's comparison does.

06:20: find the cause

Incident Debugging agent splits the segment by source and finds the bounces concentrated in records that came from one source's latest refresh. That refresh re-sent addresses carrying their old last-verified dates as if they were new.

06:35: see who is affected

Data Context & Catalog agent follows lineage from the source table to the two API products and the Wednesday bulk file that carry those records, and lists which customers receive them.

06:50: one decision

Autonomous Data-Conductor holds the affected records out of the Wednesday file and sends the data product owner one decision, with the evidence and the options: release them after re-verification, or release without them and add a note.

08:00: approved

The owner approves re-verification before release. Conductor applies the hold, and the Connectors agent triggers the team's verification run on the held records.

13:30: the corrected records

Quality Monitoring agent checks the results. Addresses that fail verification are removed from the release, those that pass are released, and the segment's bounce rate on the verified sample is back in range. Conductor lifts the hold and the Wednesday file ships with a short note on the change.

What stays behind

• •A check at landing that compares each source's refresh dates with the last-verified dates it carries, so the same pattern is caught on arrival next time.
• •A receipt for every change: who proposed it, who approved it and how to roll it back.
• •An updated Spellbook page for the source, with the incident attached.
• •A source scorecard entry for the renewal conversation with the supplier.

Minute by minute

This is an illustrative example. The sources land in Snowflake and are built with dbt under Airflow; customers receive an API and a Wednesday bulk file. Holding records out of a release is at L2.

The agents on the job

Data Context Wizard holds one governed definition of every measure you sell, from "verified email" and "active contact" to "ultimate parent" and "employee count band", so a data sheet, a customer dashboard and an AI agent that reads your product all answer from the same definitions. Autonomous Data-Conductor verifies the outcomes that matter before a release is delivered. Spellbook Data Catalog gives each source, field and product a page in plain English: what it is, where it came from, what basis it was collected under and who owns it.

What goes on autopilot

Once a field or source has earned it, this work runs on its own, and each item removes a problem your team deals with today:

• •Every source refresh is checked against its normal shape on arrival, so a thin, stale or re-sent file never reaches a release unnoticed.
• •Fill rate, bounce rate and freshness are reported per field and source every morning, so a customer call starts with the number instead of a week of building it.
• •Additive layout changes from known sources are mapped and tested the day they happen, so a new column or code is carried through instead of discovered later.
• •Re-verification runs are scheduled where freshness is falling fastest, so verification spend follows risk instead of the calendar.
• •Source pages, field documentation and lineage are kept current, so the answer to "where does this field come from and which files carry it" is always on the page.
• •Stale copies are flagged for retirement, so an old extract with personal data in it stops sitting outside every deletion run.

Where your people stay in charge

Agents never get blanket access. Each field and source has its own autonomy level, set by you, and it only rises when the receipts show the agents are reliable. Everything starts at L1, observing only; reversible upkeep such as reruns, documentation and monitoring is usually first to run on its own.

• •Opt-outs and deletion requests go to the named privacy owner. Agents find where the data sits, prepare the evidence and propose the suppression change; they do not decide a request and they do not run a deletion until the owner has approved.
• •Consent provenance and lawful-basis questions go to the same owner. If a source carries personal data without a clear notice and basis, the agents hold it out of the shared layer and ask.
• •Hierarchy changes that alter what customers have bought go to the data product owner as a diff, with the customers affected and a rollback point.
• •Source selection, contract terms and what the company sells stay entirely with people.

Once a deployment has matured, here is how that ladder plays out across task classes:

Catalog and docs upkeep closes autonomously 88% of the time. For opt-out and deletion decisions, autonomous closure is 0% by design: agents prepare the evidence and a named person decides.

What happens when an agent is wrong

• •At L2 propose, nothing changes until a named person approves. The proposal shows the full diff, the customers and files it touches and how to roll it back. Unanswered requests expire and escalate.
• •L3 and L4 are where a domain can go next, on its own review record: acting on its own, with a rollback point on every change. Only the domain's owner raises its level, and if people start reverting the agents' changes, the domain pauses itself.
• •No agent approves or promotes its own work. Autonomy only grows on evidence, domain by domain, and repeated reverts pause the domain.
• •A privacy request is never closed by an agent. The record shows who approved it, what ran and where, and what the suppression list now contains.
• •One org-wide stop halts all autonomous dispatch, and every action lands in a tamper-evident audit trail you can export with generate_audit_report.

How it fits your stack

Data Workers connects to what you already run: source SFTP, S3 and API drops; Snowflake or Databricks; dbt; Airflow or Dagster; your entity resolution layer; your verification runs; your suppression list and privacy request tool; and the delivery layer your customers buy through. Each agent is an MCP server, so the same agents work inside Claude Code, Cursor or Codex and in Slack or Teams through Spellbook. Over 50 connectors are available, and the Connectors agent keeps delivery status visible across every source. Nothing migrates.

• •Runs in your infrastructure with your credentials and your model key. The hosted Autonomous Data-Conductor sees workflow metadata only, never rows. That matters when the rows are people.
• •Uses the access you already govern. Agents act under scoped service identities and your existing roles; access to personal data goes through check_policy and is logged.
• •Fits a per-source data contract. Layout, freshness and completeness expectations for each source can be written down and enforced on each delivery. See how agents enforce data contracts.
• •Works with the privacy tool you run. Your privacy platform stays the record of what you may do with personal data; Data Workers makes sure the pipelines honour it. See what that looks like next to OneTrust.
• •Proposes changes as diffs in your dbt project, orchestrator and warehouse, with blast radius, tests and a rollback point, and applies them only at the autonomy level you set.
• •Open-source core. The Apache-2.0 community edition ships 11 agents and 160+ MCP tools, so your engineers can read exactly what the agents call.

Freshness promises to customers are tracked the way described in data freshness monitoring and SLAs, and the dimensions behind fill rate and accuracy are laid out in data quality dimensions. The downstream use of these records by a customer's sales team is covered in account intelligence.

Governance and regulation

A company that sells person data is accountable for where it came from and for every copy it has delivered. Under the GDPR, a company that obtains personal data from a source other than the person still has notice obligations to that person (Article 14), people may ask for erasure (Article 17) or object to processing (Article 21), and a controller that erases data must tell each recipient it was disclosed to, unless that proves impossible or involves disproportionate effort (Article 19). In California, registered data brokers must check the state's deletion request platform, DROP, at least every 45 days from August 1, 2026, and process the requests they find. Every one of those obligations is a question about copies: which records, which files, which customers, and whether the person is still suppressed in the next release.

Data Workers keeps provenance attached to each source and field, finds personal data with scan_pii, traces every delivered copy through lineage, holds uses the source terms do not clearly allow for the named privacy owner, and records every change in a tamper-evident audit trail. See how Data Workers handles PII, GDPR for data engineers and DSAR automation.

Data Workers doesn't make you compliant; your controls, people and assessors do. It supplies controls and evidence wherever agents touch data. Not legal advice.

The alternatives company and person data teams weigh

Build it yourselves. A strong team can wire a coding agent to MCP servers for the warehouse and dbt and generate checks quickly. The work is everything around it: routing each decision to the right owner, blast radius across every delivered copy, rollback, receipts, and a record of what each source's terms allow.

Email and phone verification services. Verification tells you whether an address works at a point in time. It does not tell you which source made a segment worse, which products and files carry the affected records, or whether the segment's freshness is falling. Data Workers triggers the verification you already run where it matters most, checks the results and keeps the receipt.

Entity resolution and master data tools. Matching engines decide which records are the same company or person. Data Workers runs the work around them: the layout changes feeding them, the checks on their output, the lineage to every product and the documentation. See entity resolution and unified profiles.

Observability, catalogs and point tools. Observability alerts, catalogs document and quality tools test. Data Workers closes the gap between the alert and the fix and keeps the documentation current as a by-product.

Platform-native agents. Warehouse vendors' agents work well inside their platform. Record upkeep crosses the source drops, the orchestrator, the warehouse, the verification runs and the delivery layer, and Data Workers works across all of them.

In this space specifically. Sales-intelligence and enrichment products sell the records; Data Workers does not compete with them. It is what runs underneath, keeping the records correct, delivered and removable.

The case for your CTO

What this replaces. Customers finding decayed records before you do, silent breakage when a source changes layout, hierarchies patched once a quarter, and deletion requests chased across tables, files and shares by hand.

What your team gets back. A team that builds fields, sources and segments instead of repairing the last refresh, and a data product whose coverage, accuracy and freshness improve every release.

Integration effort. Connecting is configuration, not a migration. The agents attach over MCP to the source drops, warehouse, orchestrator and dbt project you already run, under the roles you already govern, inside your own infrastructure. Your engineers can read every tool the agents call in the open-source core.

Risk and control. Autonomy is set per field and source. Everything starts at L1, observing only; reversible work moves up only when the receipts justify it; opt-outs, deletions and consent stay with a named privacy owner; and one org-wide stop halts all autonomous work.

Why now. Customers compare data vendors on bounce rate and freshness, and buyers' AI agents now read your records directly, so a stale or wrongly merged record reaches more places faster. Meanwhile obligations to carry deletion requests to every copy are tightening.

The first win. Bounce-rate tracing and source layout changes on your highest-volume contact product, plus the deletion evidence pack, at L2. The pilot below lays out the scope, what you see each week and the 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 company and person data teams, the climb looks like this:

• •Assisted. Agents work alongside your team. They read every source and product, show what needs doing and propose every fix with a receipt; opt-outs, deletions and consent always go to the named privacy owner.
• •Autonomous, under your governance. Routine work runs on its own: every refresh is checked on arrival, additive layout changes are mapped the day they happen, fill rate and bounce rate are reported every morning, and documentation and lineage stay current. Your team governs the agents instead of doing the upkeep.
• •The agentic data business. A team that ships new fields and segments instead of repairing the last refresh. People set direction, and the platform carries it out.

You choose the altitude, every step is visible and reversible, and the pilot below is the first rung.

The pilot: how company and person data teams start

The pilot is how your team proves the value on its own data before committing.

• •What we connect. Your source drops, Snowflake or Databricks, dbt, Airflow or Dagster, your suppression list and the delivery layer, over MCP, inside your infrastructure. Nothing migrates.
• •Scope. Bounce-rate tracing and source layout changes on your highest-volume contact product, plus the evidence pack for deletion requests, at L2.
• •First week. Agents run at L1 across the scoped product. They profile every source refresh, map lineage from sources to products and delivered files, and show the fixes and evidence packs they would have produced, with receipts, so your team sees the value before anything changes.
• •By week two. Delivery checks, morning fill-rate and bounce-rate reports and documentation upkeep start running on reversible work. Layout changes, hierarchy changes and anything touching personal data stay at L2 with a named approver.
• •At day 30. We review the impact metrics against your baseline:

• •Source layout change mapped: from about three days to under an hour
• •Bounce spike traced to its source: from about a week to ~30 min
• •Deletion request evidence pack: from about a day to ~1 h
• •the share of catalog and docs upkeep closed autonomously, targeting 88% as the deployment matures

• •What you decide. Whether to expand to the next product. The pilot fee is credited in full against the first year.
• •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, more than 42% of agent actions run fully autonomously and manual work falls below 10%, while opt-outs, deletions and consent stay with the named privacy owner.

FAQ

Will agents decide whether to delete someone? No. They find where the person's data sits, prepare the evidence and propose the suppression change. The named privacy owner approves, and only then does your own suppression or deletion job run.

Can it find every copy of a record? It uses lineage and a personal-data scan to list the tables, products, files and shares that carry a record. Copies outside the systems it is connected to, such as a file a customer already holds, are listed from your delivery records and flagged for the owner.

Does it replace our email verification? No. It triggers the verification runs you already use where freshness is falling, checks the results and records them.

Can it fix a hierarchy after a merger on its own? It drafts the versioned change, checks the roll-ups and shows who is affected. The data product owner approves it.

Where do the agents run? In your infrastructure, with your credentials and model key. The hosted Conductor sees workflow metadata only.

Do we have to migrate anything? No. Your warehouse, dbt project, orchestrator, catalog, privacy tool and delivery layer stay where they are.

Sources

• •Data Workers pricing: https://dataworkers.io/pricing/
• •European Union, General Data Protection Regulation (Regulation (EU) 2016/679), including Articles 14, 17, 19 and 21: https://eur-lex.europa.eu/eli/reg/2016/679/oj
• •California Privacy Protection Agency, information for data brokers (Delete Request and Opt-out Platform, DROP): https://cppa.ca.gov/data_brokers/