AI-ready data teams: stop arguing over metrics, start serving context

Key takeaways

• •Who this is for. The platform or data product team charged with making enterprise data usable by AI agents, copilots and RAG apps.
• •The problem today. Every new agent needs its own round of definitions, access reviews and PII checks, and the first wrong number in front of an executive sets the whole program back.
• •What changes. Each metric has one governed definition that every agent reads, trusted sources are marked, and a source change reaches the context layer the night it happens, not the week someone complains.
• •What stays with your people. Metric definitions, which sources count as authoritative and agent access to sensitive data: they decide what the company's AI says, so a named owner approves each one.
• •The result. An AI-ready data team that ships governed context to the next agent in days, instead of explaining to the last one why it disagreed with the dashboard.

The PRD for agentic AI-ready 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 AI-ready data teams

• •Put your context layer on autopilot. A source change is traced to every definition and agent that reads it the night it happens, so no agent keeps answering from yesterday's meaning.
• •Run the data back office without the busywork. The work that fills the week today moves to agents: reconciling the third version of a metric, documenting tables for agents, re-running access reviews and re-checking answers after every data change.
• •Scale data without scaling headcount. New agents, new domains and new tables inherit governed definitions, lineage and access rules automatically, so the number of AI use cases grows without the team having to.
• •Get the plumbing off your plate. An AI-ready data team that ships the next agent's context in days instead of arguing about which number is right.

Who this is for

The team that is asked, usually by a CIO or Chief Data Officer, to make the company's data ready for AI. At a software or financial services company it is a platform team inside a central data and AI organization, often a few engineers and a product manager, serving copilot pilots, internal agents and RAG apps built by other teams. At a bank, insurer or manufacturer it may be a governance or knowledge management group that inherited the AI mandate. The people asking the questions are usually the AI builders, who need data an agent can use, and the risk and finance leaders, who need to know what the agent saw and why it said what it said.

The titles: Head of AI Data Platforms, Director of Data for AI, AI Data Product Manager, Lead Data Platform Engineer, Knowledge Engineer, Data Governance Lead. They run one platform and many consumers, each with its own model, its own prompts and its own idea of what "revenue" means. The wider group is covered on the data platform and governance teams page.

The product you ship

The product this team ships is a governed context layer that any AI agent can query safely. In concrete terms:

• •One definition per metric. Revenue, active customer, churn and margin each have one governed definition, one owner and one trusted source, served the same way to every agent.
• •Trusted sources marked. Agents are steered to certified tables and away from the abandoned copy, the analyst's scratch table and the stale snapshot.
• •Lineage and impact. From any number an agent quotes back to the source system, and from any source forward to every agent, dashboard and metric that reads it.
• •Freshness. Every answer carries how current the data behind it is, and stale context is flagged before an agent relies on it.
• •PII handled. Sensitive columns are found, classified and masked before an agent, an index or a prompt can see them.
• •Access policy enforced. Each agent acts under a scoped identity and your existing roles, never a shared superuser key.
• •Traceable answers. For any answer an agent gave, the team can show which definition, which source and which version of the data it used.
• •Evaluation. A set of the team's own reference questions, re-run after every meaningful data change, so accuracy is measured rather than assumed.

This is the practical meaning of ai-ready data: not a clean warehouse in the abstract, but data that an agent can find, understand, trust and be allowed to use. Our AI-readiness checklist walks the 15 points; this page is about running them without a team of stewards.

Where the week goes

• •Every agent brings its own questions. Which table, which definition, which columns are safe, who approved it. The platform team answers the same questions again for each pilot.
• •Definitions are contested. Finance, sales ops and product each have a version of revenue and active customer, and a copilot picks whichever it finds first.
• •Sources change underneath the context. A renamed column or a restated metric reaches the agent before anyone updates the glossary.
• •Documentation for agents is a backlog. Agents need plain-English descriptions, owners and join paths for thousands of tables, and the catalog was written for humans.
• •PII keeps arriving. New columns land in the warehouse every week, and each one is a possible leak into a prompt, an embedding index or a log.
• •Access requests multiply. Each agent and each RAG app needs scoped access, reviewed by hand.
• •Nobody can prove what the agent saw. When a number is challenged, reconstructing the answer takes a day of digging.

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 the next governed agent or domain, moves from 14% of the week to 46%. 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 AI-ready data teams:

• •Conflicting definition reconciled: from about a month to 8 h
• •Agent answer traced to its source: from about a day to seconds
• •Source change traced to every affected agent: from about 2 days to minutes

Across the routine work in this domain:

The biggest change is reconciling a conflicting metric definition: from about a month to 8 hours. Work that waited in a committee finishes the same day, because agents find every copy, show the conflict side by side and hand one decision to the owner.

Use cases, in depth

One metric definition that every agent uses

Today. Finance counts an active customer as anyone billed in the last 90 days. Product counts anyone who logged in. Sales ops counts anyone with an open contract. The copilot the CFO uses picks a table, answers confidently, and disagrees with the board deck. Three other agents built by three other teams have each picked a different table.

With Data Workers. The Data Context & Catalog agent finds every copy of the metric across dbt models, BI tools, semantic layers and wikis with list_semantic_definitions, and shows the conflicts side by side. It records the definition the owner chooses in Data Context Wizard with define_business_rule and marks the trusted source with mark_authoritative. From then on any agent that asks for the metric over MCP gets the same governed answer through resolve_metric, with its owner and source attached. If you already keep definitions in dbt MetricFlow, Cube or Looker, bring them in rather than rewriting them. The Observability agent re-runs the team's reference questions with get_evaluation_report to confirm the agents now agree with the dashboard.

What changes. The next time someone asks "which number is right", the answer is a link, not a meeting. For the difference between a catalog and a context layer, see data catalog vs context layer; for how a semantic layer fits, see context layer vs semantic layer.

Keeping agent answers fresh and traceable when a source changes

Today. A billing table renames a column on Thursday night. The glossary is updated the following week. In between, a revenue agent quotes a number built on the old meaning, and nobody can say which agents read that column, which answers were affected or when the drift began.

With Data Workers. The Schema Evolution agent catches the change with detect_schema_change. The Data Context & Catalog agent runs blast_radius_analysis to list every definition, dashboard and agent that depends on the column, and flags stale context with flag_stale_context and check_freshness so affected answers say so. The Quality Monitoring agent ties the restated numbers to finance with run_quality_check. The Observability agent records what changed, when and on whose approval in the audit trail, readable with get_audit_trail.

What changes. A source change reaches the context layer the night it happens. When a number is challenged, the team can show the source, the definition and the freshness the agent used, in minutes rather than a day.

Handling PII before a copilot or RAG app can see it

Today. A new column with customer emails lands in a table that a support copilot indexes. Nobody notices until a prompt log is reviewed.

With Data Workers. The Data Access & Governance agent scans new columns with scan_pii, checks them against your policy with check_policy and applies role-based rules with enforce_rbac, so the column is masked before an agent or an embedding index reads it. How that works in practice is covered in how Data Workers handles PII.

What changes. Sensitive data is handled on arrival, and the audit report for the agent's access is a click away.

Agents working together: A source changes at 02:00

Every AI data team knows this night. A source system changes under a live agent, and by morning an executive is quoting a number the glossary does not yet explain. This is the same night run by Data Workers.

The setup

The company runs a revenue copilot, a support agent and an internal analyst agent on Snowflake and dbt, orchestrated by Airflow. All three read through the same governed context layer over MCP. Autonomy in Autopilot:

• •Lineage refresh, freshness flags and documentation: L2 today; a candidate for L3 on evidence.
• •PII scans of new columns: L2, with every classification approved by a named person.
• •Metric definitions and authoritative sources: L2, held for the metric owner.
• •Agent access to sensitive data: L2, held for the data owner.

The team scheduled one routine earlier: "When a source feeding a governed metric changes, trace it, re-verify and report."

02:00 - the source changes

Billing renames a net amount column and adds a free-text notes field. Finance restates "net revenue" to exclude partner credits.

02:04 - catch and trace

Schema Evolution agent detects the rename and checks that downstream models still compile. Data Context Wizard finds every definition, dashboard and agent that reads the column: the net revenue metric, two board dashboards and all three agents.

02:10 - protect

Data Access & Governance agent scans the notes field, finds customer emails in it, classifies it as sensitive and masks it for every agent identity. The grant is logged.

02:20 - tie it out

Quality Monitoring agent ties restated net revenue to finance and checks that the data behind each affected definition is as fresh as its stated SLA.

02:40 - re-ask the questions

Autonomous Data-Conductor re-runs the team's reference questions against the three agents and compares their answers to the dashboards. Two agents match. One still quotes the old definition, so it is held back from answering revenue questions until the new definition is approved.

03:15 - one decision

Because metric definitions sit at L2, Conductor sends one request to the metric owner: the old and new definitions, the tie-out to finance, the list of affected agents and the rollback point.

08:10 - approved

The owner approves the restated definition and edits one sentence of its description. Data Context Wizard publishes it and the held agent is released.

09:00 - the CFO asks the copilot

The answer matches the board dashboard and carries its source, its definition and its freshness. Nobody files a ticket.

What stays behind

• •A governed definition with an owner, a trusted source and a change history.
• •A receipt for every change: who proposed it, who approved it and how to roll it back.
• •Updated Spellbook Data Catalog pages for every affected table and metric.
• •A reusable routine. Next time a source feeding a governed metric changes, it runs the same way, and the team can move more of it to L3.

Minute by minute

This is an illustrative example. Three agents read governed context over MCP. Metric definitions and sensitive access are at L2.

The agents on the job

Data Context Wizard holds one governed definition of each metric, with its owner, trusted source and change history, and serves it to every agent over MCP. It brings in the definitions you already keep in dbt, Cube, Looker or a catalog and checks them against each other and against the warehouse. Spellbook Data Catalog makes every governed table and metric discoverable by people and agents in plain English, and holds changes for the right approver. Autonomous Data-Conductor verifies the outcome that matters: whether the agents' answers still match the numbers the business trusts.

What goes on autopilot

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

• •Documentation, ownership and lineage for every table an agent can reach stay current, so a new agent starts from a described estate, not a blank catalog.
• •Source changes are traced to every affected definition and agent overnight, so stale meaning is flagged before a user sees it.
• •New columns are scanned for PII and masked on arrival, so nothing sensitive reaches a prompt, an index or a log.
• •Reference questions are re-run after meaningful data changes, so a regression in answer quality is caught by the team, not by a user.

Where your people stay in charge

Agents never get blanket access. Each domain 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 documentation, lineage refresh and freshness flags is usually first to run on its own.

• •Metric definitions always go to a named approver: they decide what the company's AI says about revenue, churn and risk, so the metric owner approves every change with the before-and-after numbers.
• •Which sources are authoritative is a data owner's call, with the impact on every agent shown first.
• •Agent access to sensitive data goes to the data owner, with the policy check and the audit trail attached.

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

Definition and docs upkeep closes autonomously 88% of the time. For new or changed metric definitions, autonomous closure is 0% by design: every change is proposed with a full diff and approved by a named person.

What happens when an agent is wrong

• •At L2 propose, nothing changes until a named person approves. The proposal shows the full diff, the agents it affects 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.
• •When a user catches a bad answer, the correction is recorded against the definition or source it came from, so the same mistake is not served again. The Incident Debugging agent traces it to the change or gap that caused it.
• •No agent approves or promotes its own work. Autonomy only grows on evidence, domain by domain, and repeated reverts pause the domain.
• •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: Snowflake, Databricks or BigQuery; dbt and your semantic layer; your catalog; Airflow or Dagster; and the assistants and agents your builders use. Each agent is an MCP server, so the same governed context is available to Claude, ChatGPT Enterprise, Cursor and internal agents, and in Slack or Teams through Spellbook. Nothing migrates.

• •Runs in your infrastructure with your credentials and your model key. The hosted Autonomous Data-Conductor sees workflow metadata only, never rows.
• •Uses the access you already govern. Agents act under scoped service identities and your existing roles; every grant goes through provision_access and is logged.
• •Works with the semantic layer and catalog you chose. Existing definitions are brought in and checked, not replaced. See Snowflake semantic views for one example.
• •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.

Governance and regulation

AI-ready data is partly a governance question. The EU AI Act's Article 10 sets data governance expectations for high-risk AI systems, including documented data origin, quality and bias examination, and the NIST AI Risk Management Framework asks organizations to map, measure and manage the data their AI depends on. Data Workers keeps definitions, lineage, access and PII handling documented in one place and records every agent action in a tamper-evident audit trail.

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 AI-ready data teams weigh

Build it yourselves. A strong team can wire a coding agent to MCP servers for the warehouse, dbt and the catalog, and many do for a first pilot. The work is everything around it: one definition per metric across tools, routing approvals to the right owner, tracing a source change to every agent, PII handling and a record of what each agent saw. See can't we just build this ourselves.

Catalogs, semantic layers and point tools. A catalog documents, a semantic layer defines metrics, and a quality tool tests. Each is part of the answer. Data Workers brings in what they already know, checks it against the others and the warehouse, keeps it current and serves it to every agent. For the Atlan, Collibra and dbt cases see the guides for Atlan, Collibra and dbt.

Platform-native context. Snowflake and Databricks each offer context and metric features that work well inside their own platform. This work crosses platforms, BI tools and the agents built by different teams, and Data Workers works across all of them. See Snowflake Horizon context vs Data Workers.

In this space specifically. Retrieval and RAG tooling makes documents searchable; Data Workers makes sure the structured data behind an answer is defined, current, permitted and traceable. For how grounding affects accuracy, see how Data Workers avoids AI hallucinations.

The case for your CTO

What this replaces. A queue of per-agent definition, access and PII reviews, and the manual work of explaining why an agent and a dashboard disagree. Gartner predicts that through 2026 organizations will abandon 60% of AI projects unsupported by AI-ready data.

What your team gets back. An AI-ready data team that ships governed context to the next agent in days instead of rebuilding the same checks for each one.

Integration effort. Connecting is configuration, not a migration. The agents attach over MCP to the warehouse, dbt project, catalog and orchestrator 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 domain. Everything starts at L1, observing only; reversible work moves up only when the receipts justify it; metric definitions, authoritative sources and sensitive access stay at L2 with a named approver; and one org-wide stop halts all autonomous work.

Why now. Every new agent multiplies the cost of a wrong or ungoverned number, and the number of agents is growing faster than the number of stewards.

The first win. One copilot on one domain, with its top metrics governed. The pilot below lays out the scope, what you see each week and the cost. For the transformations behind it, see make your data catalog agentic and build your semantic layer.

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 AI-ready data teams, the climb looks like this:

• •Assisted. Agents work alongside your team. They read the whole stack, show every conflicting definition, ungoverned table and unmasked column, and propose every fix with a receipt; definitions and sensitive access always go to a named approver.
• •Autonomous, under your governance. Routine work runs on its own: documentation and lineage stay current, source changes are traced overnight, and new columns are scanned for PII on arrival. Your team governs the agents instead of doing the upkeep.
• •The agentic enterprise. An AI-ready data team that ships governed context to the next agent in days. 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 governed layer you build here is also what lets every other agent in the company act safely; see one governed data layer for every AI agent.

The pilot: how AI-ready data teams start

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

• •What we connect. Your warehouse, dbt project, semantic layer, catalog and orchestrator, plus one copilot or agent, over MCP, inside your infrastructure. Nothing migrates.
• •Scope. One copilot or agent on one domain, with its top metrics governed at L2.
• •First week. Agents run at L1 across the scoped domain. They map every definition, source and lineage path the agent reads, flag the conflicts and unmasked columns, and show the fixes they would have made, with receipts, so your team sees the value before anything changes.
• •By week two. Documentation, lineage refresh and freshness flags start running on reversible work, and new columns are scanned for PII. Metric definitions and sensitive access stay at L2 with a named approver.
• •At day 30. We review the impact metrics against your baseline:

• •Conflicting definition reconciled: from about a month to 8 h
• •Agent answer traced to its source: from about a day to seconds
• •Source change traced to every affected agent: from about 2 days to minutes
• •the share of definition and docs upkeep closed autonomously, targeting 88% as the deployment matures

• •What you decide. Whether to expand to the next domain or the next agent. 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 40% of agent actions run fully autonomously and manual work falls below 10%, while metric definitions and sensitive access stay with a named approver.

FAQ

What does ai-ready data actually mean? Data that an agent can find, understand, trust and be allowed to use: described, defined once, current, permissioned and traceable. See the AI-readiness checklist.

Do we need a new semantic layer first? No. Data Context Wizard brings in the definitions you already keep in dbt, Cube, Looker or your catalog and checks them against each other. Teams that want to build one can start with build your semantic layer.

Which AI tools can read the governed context? Any tool that speaks MCP, including Claude, ChatGPT Enterprise, Cursor and internal agents.

Will an agent change a metric definition on its own? No. Definitions are L2: proposed with a diff and approved by the metric owner.

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, catalog and BI stay where they are.

Sources

• •Data Workers pricing: https://dataworkers.io/pricing/
• •Gartner, Lack of AI-Ready Data Puts AI Projects at Risk (Feb 26, 2025): https://www.gartner.com/en/newsroom/press-releases/2025-02-26-lack-of-ai-ready-data-puts-ai-projects-at-risk
• •EU AI Act, Article 10, Data and data governance: https://artificialintelligenceact.eu/article/10/
• •NIST, AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
• •Model Context Protocol specification: https://modelcontextprotocol.io/specification