Make your data catalog agentic
A catalog people document by hand is out of date by the time an agent reads it. Data Workers turns the catalog you run into context agents read and keep current: what each table means, who owns it and which copy to trust, with a named owner approving changes.
Before and after
| Today | With Data Workers |
|---|---|
| A catalog stewards update by hand, page by page | Pages agents draft and refresh as the data changes |
| Documentation weeks behind the warehouse | An incident, schema change or new owner shows on the asset's page |
| Analysts and copilots guessing which table is right | The trusted source marked for each concept, ready to ask |
| Owners chased in spreadsheets | Owners proposed, confirmed by the people who hold them |
| Several catalogs, several searches | One search across every connected catalog |
Step 3 of 4 on the AI maturity curve for data teams. Once agents share agreed metric definitions, they still need to know what each table is, where it comes from and which copy to trust. A catalog nobody has time to update fails that test, which is why copilots stall when answers disagree with reports. This is the step where the catalog stops being a place people document and becomes context agents read, the shift behind an agentic data catalog. The whitepaper from a traditional data catalog to an agentic data catalog makes the full case.
How it works
1. Read the catalogs you already run
The Connectors Agent connects read-only to DataHub, Microsoft Purview, Databricks Unity Catalog, OpenMetadata, Google Dataplex, AWS Glue and Lake Formation, Hive Metastore and Iceberg catalogs (list_all_catalogs, search_across_catalogs). The Data Context & Catalog Agent adds what none of them hold: metric definitions, real ownership, past fixes and cross-platform lineage (correlate_metadata). Your catalog stays the system of record for access and governance.
2. Let agents write and refresh the pages
The Data Context & Catalog Agent drafts a page for each table, model and dashboard: what it is, how it is built, what it feeds and who owns it (generate_documentation). It flags stale pages and gaps for an owner instead of waiting for a documentation drive (check_staleness, flag_documentation_gap). People suggest edits and add context right on the page. Spellbook Data Catalog, in preview, is where those pages live.
3. Serve trusted context to every agent
The agent marks the authoritative table for each concept (mark_authoritative), so analysts, copilots and your own agents ask for context before they write a query (get_context). A named domain owner approves definitions and changes through the Data Access & Governance Agent (request_governance_review), and every proposal shows what it would touch and how to undo it.
The impact metrics we move
- •Catalog freshness: from about a month to under 1 h
- •Finding the right dataset: from about 8 h to 30 s
- •Owner assigned: from about 2 weeks to ~1 h
Where teams start
- •The domain with the most "which table?" questions. Revenue or customer data first: agents draft the pages and propose owners.
- •A catalog people stopped updating. Run beside DataHub, Purview, Unity Catalog or OpenMetadata and compare freshness; teams replacing a hand-run catalog can read the catalog modernization page too.
- •A copilot or coding-agent rollout. Give assistants trusted context before launch, not after the first wrong answer.
- •Estates with more than one catalog. After a merger or a second cloud, search Glue, Unity Catalog and Dataplex in one place. Teams comparing Atlan, Collibra or Alation can run one domain through this first.
- •Dead and duplicate assets. Find unused tables (
detect_dead_assets) before they confuse the next agent.
What powers it
The Data Context & Catalog Agent and the Connectors Agent do the reading and writing of context, the Data Context Wizard keeps the shared picture of your estate that every agent works from, and Spellbook Data Catalog (in preview) holds the pages. Autopilot Routines run documentation-gap and freshness sweeps on a schedule or when something changes, the Autonomous Data-Conductor routes the work, and the Data-Agents Swarm shares one approval path. The how-to for making a catalog queryable by LLM agents goes deeper on the MCP side. This step shows up in AI-ready data teams and in governed product metrics. Previous step: Build your semantic layer. Next step: Zero data ops.
The climb: from assisted to autonomous to agentic
Every domain climbs the same ladder from our thesis. Agents start by watching and suggesting, then act after a named owner approves, and a domain can go further only on its own review record. L0 to L2 run today; L3 and L4 are where a domain can go on evidence.
The pilot
- •Scope. One domain, read-only access to the catalog you run, and a named owner for the pages.
- •First week. Agents start by watching and suggesting: the pages, owners and stale entries they would propose, each with a receipt, and a baseline of where freshness starts.
- •By week two. Draft pages and stale-page flags arrive on a routine; the domain owner approves what ships and anything sensitive stays with a named approver.
- •At day 30. We review the impact metrics against your baseline:
- •Catalog freshness: from about a month to under 1 h
- •Finding the right dataset: from about 8 h to 30 s
- •Owner assigned: from about 2 weeks to ~1 h
- •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.
FAQ
Do we have to replace our catalog? No. Data Workers reads from the catalog you run and adds what it does not hold; your catalog stays the system of record for access and governance.
What stays with people? Owners approve definitions, trusted-source marks and changes, and anyone can add context on a page.
What if an agent writes something wrong? The proposal shows what it touches and how to undo it, the owner declines or reverts, and if people keep reverting a domain's changes, that domain pauses itself.
How is this different from a self-maintaining catalog? That page covers the upkeep behind the catalog; this one is the maturity step, where self-maintaining catalog pages become context agents rely on.
Which stacks does it work with? DataHub, Microsoft Purview, Databricks Unity Catalog, OpenMetadata, Google Dataplex, AWS Glue and Lake Formation, Hive Metastore and Iceberg catalogs, and the catalog you already run.