Best practices for agentic data product offices: a field guide for CDOs and data product owners
Federated data products only work if standards hold across every domain. This report covers how chief data offices use agents to make standards enforce themselves.
Banks, insurers and large enterprises have spent the last five years building chief data offices, data mesh programs and data product job families. The structure is right: domains own data products, a central office sets standards, stewards own definitions.
The execution is where it breaks. Catalogs are registered once and go stale. Standards are checked quarterly in spreadsheets. Definitions conflict across domains, and AI pilots stall because nobody trusts which table is right.
Agents close the gap between the operating model on paper and the one in production. The office sets the standards; agents keep them true in every domain, every day.
The old world
The CDO's quarterly review: 140 data products in scope, 38 without an owner, 61 with conflicting definitions, a catalog last updated in spring. Stewards spent the quarter chasing spreadsheets. The firm's copilot pilot is paused because 'client' means three different things.
The new world
With Data Workers, the standard is an Autopilot rule. Data Context & Catalog proposed owners from usage history, Context Wizard reconciled definitions and flagged the 12 that needed a steward's decision, Quality Monitoring added rules to every certified product, and the dashboard shows each domain's gap closing week by week. The copilot answers from governed definitions.
Here is that new world as a chain of hand-offs between agents:
The full playbook walks through this scenario and three more use cases in depth.
The rest of this report walks through the 6 practices that make that morning possible. At a glance:
The practices, one by one
1. Write standards as rules agents enforce
Standards on paper drift in practice.
The old world. Quarterly checks in spreadsheets.
The new world. Autopilot turns standards into org rules every domain is held to.
In practice. Every certified product has an owner, SLA and governed definition.
What to measure. Domains meeting standards.
2. Keep the catalog alive
Registered once, stale forever is the default.
The old world. Manual stewardship.
The new world. Data Context & Catalog keeps owner, SLA, lineage and definitions current as agents work.
In practice. Lineage updates the day a pipeline changes.
What to measure. Catalog entries current within a week.
Practices like these compound. Across the routine work they cover, here is the difference in elapsed time:
The biggest change is Access request handled: from about a week to 5 min. Work that waited in queues finishes in minutes or hours, because agents detect, fix and verify in one pass.
3. Reconcile definitions before AI uses them
Copilots amplify conflicting definitions.
The old world. Conflicts surface in executive meetings.
The new world. Context Wizard finds and reconciles conflicts and flags those needing a steward.
In practice. Three definitions of client become one.
What to measure. Conflicting definitions in certified products.
4. Make access policy executable
Access queues slow every domain.
The old world. Tickets per domain.
The new world. Data Access & Governance handles requests against firmwide policy and logs every grant.
In practice. Routine access is granted in minutes.
What to measure. Hours to policy-compliant access.
5. Measure autonomy per domain
What gets measured gets automated.
The old world. Unknown.
The new world. The Autopilot dashboard shows autonomy and token cost per domain.
In practice. Leadership sees which domains lag and why.
What to measure. Share of domain upkeep autonomous.
That balance, autonomy where work is reversible and a named approver where it matters, shows up clearly by task class:
Catalog and ownership upkeep closes autonomously 88% of the time. For Regulated and financial numbers, autonomous closure is 0% by design: every change is proposed with a full diff and approved by a named person.
6. Migrate legacy platforms in waves
Big-bang migrations fail.
The old world. Multi-year programs.
The new world. Data Migration moves workloads in approved waves with parity checks.
In practice. A legacy EDM is retired on evidence.
What to measure. Legacy platforms retired.
Designing the autonomy ladder
Autonomy is set per task class, not per tool. This is where we would set each class for a mature deployment, and why:
| Task class | Closed autonomously | Escalated | Handled by a person | Where we set it | Why |
|---|---|---|---|---|---|
| Catalog and ownership upkeep | 88% | 8% | 4% | L4 once the receipts are clean | The work is reversible and repeatable |
| Access provisioning | 84% | 10% | 6% | L4 once the receipts are clean | The work is reversible and repeatable |
| Standards compliance checks | 80% | 14% | 6% | L4 once the receipts are clean | The work is reversible and repeatable |
| Quality rules | 58% | 30% | 12% | L3: acts and keeps a rollback point | Most cases are routine; the rest escalate with evidence |
| Definition reconciliation | 30% | 56% | 14% | L3 for routine cases, L2 for the rest | Judgment is needed often enough to keep a person close |
| Regulated and financial numbers | 0% | 84% | 16% | L2: always proposed to a named approver | The number carries accountability outside the data team |
The operating model: who owns what
Agents change who does the work, not who is accountable for it:
| Role | Owns | What the agents take off their plate |
|---|---|---|
| Head of Data Products | Standards, autonomy levels per domain and which domain goes next | Assembling status, chasing owners, keeping the catalog current |
| Domain owners and approvers | Changes to regulated, capital or financial-reporting numbers | Preparing the diff, blast radius and rollback plan for every proposal |
| Data engineers | Reviewing agent proposals and building new data products | Standards are checked in every domain every week; the catalog updates as agents change pipelines |
The swarm behind the practices
No single agent delivers these practices. Each one is a hand-off between specialists, coordinated under the autonomy you set per domain.
| Agent | What it does for a CDO office |
|---|---|
| Data Context & Catalog | Registers and maintains every data product with owner, SLA, lineage and definitions |
| Quality Monitoring | Writes and runs quality rules per domain and reports against standards |
| Data Access & Governance | Applies firmwide policy to every request and logs every grant |
| Pipeline Building | Builds new domain data products to the firm's standards |
| Data Migration | Moves legacy EDM and warehouse workloads in approved waves |
| Incident Debugging | Traces a bad number across domains to its source |
Spellbook Data Catalog is where agentic governance happens: agents keep definitions, ownership and policy work current, and the office points the fleet and audits anything. Context Wizard gives copilots and agents governed meaning with provenance. Autopilot turns firmwide rules into org standards every domain is held to automatically.
What disappears
The clearest sign the practices are working is what stops happening:
- •Quarterly standards spreadsheets.
- •Stale catalogs.
- •Definition conflicts surfacing in executive meetings.
- •Domain access queues.
- •Stalled copilot pilots.
- •Endless legacy migrations.
The magic is not any single agent. It is that the back office simply keeps running. Bad data is caught where it enters, not where it is read. Every new table gets quality rules and documentation without anyone writing them. Access follows policy instead of a queue. Fixes are rerun, verified and explained before anyone opens a dashboard. Cost is cleaned up every week instead of every budget cycle. And every one of those actions leaves a signed receipt, so the team can see exactly what happened and roll anything back. For the people on the team, the experience is quieter mornings, fewer tickets and more time for the products the business asked for.
A product manager's scorecard
If you own this data as a product, these are the numbers to bring to every quarterly review:
- •Share of products certified
- •Conflicting definitions in certified products
- •Catalog freshness
- •Hours to compliant access
- •Autonomy per domain
- •Legacy platforms retired
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 chief data offices and data product teams in banks and insurers, the climb looks like this:
- •Assisted. Agents work alongside your team. They read the whole stack, show what needs doing and propose every fix with a receipt; changes to regulated, capital or financial-reporting numbers always go to a named approver.
- •Autonomous, under your governance. Routine work runs on its own: standards are checked in every domain every week, the catalog updates as agents change pipelines, and routine access requests are handled against firmwide policy. Your team governs the agents instead of doing the upkeep.
- •The agentic enterprise. A data office whose standards hold in every domain without stewards chasing owners. 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 chief data offices and data product teams in banks and insurers start
The pilot is how your team proves the value on its own data before committing.
- •What we connect. Snowflake, Databricks or Teradata; Collibra, Alation or Unity Catalog; dbt; Airflow; BI, over MCP, inside your infrastructure. Nothing migrates.
- •Scope. Certify the top 50 products as a mission.
- •First week. Agents run at L1 across the scoped domain. They map every pipeline, definition and lineage path and show the fixes they would have made, with receipts, so your team sees the value before anything changes.
- •By week two. Standards are checked in every domain every week and the catalog updates as agents change pipelines start running on reversible work. Changes to regulated, capital or financial-reporting numbers stay at L2 with a named approver.
- •At day 30. We review the impact metrics against your baseline:
- •Access request handled: from about a week to 5 min
- •Finding a data product: from about 8 hours to 30 s
- •Standards checked across domains: from about a month to ~1 h
- •the share of catalog and ownership upkeep closed autonomously, targeting 88% as the deployment matures
- •What you decide. Whether to expand to the next domain. The pilot fee is credited in full against the first year.
- •Cost. Start with a pilot ($7,500 one-time, 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 38% of agent actions run fully autonomously and manual work falls below 10%, while regulated numbers stay with a named approver.
Read the full playbook: CDO offices, data product owners and domain stewards