Ask a large language model where your company’s monthly recurring revenue number lives, and it will answer confidently. It might even be right. The trouble is that a data catalog has always held that answer’s raw material, the tables, the lineage, the query history, without ever being asked to serve it the way an agent needs. That gap, not a missing feature, is the actual problem behind the phrase “data catalog for AI.” In Atlan’s AI Labs benchmark, adding governed context lifted text-to-SQL accuracy from 16.1% to 22.2%, a 38% relative gain across 174 unique queries and 522 evaluations.
That number is the payoff. Getting there means fixing three separate things, and a catalog can fail at any one of them on its own: who produces context, how an agent consumes it, and whether the system notices its own gaps.
| Aspect | Description |
|---|---|
| What it is | A governed metadata layer that makes enterprise data discoverable, understandable, and trustworthy for both people and AI agents, generated from evidence rather than manual entry. |
| How it differs from a traditional catalog | Built for machine consumption first: metadata reaches an agent through a governed, typed interface at the moment it reasons, not a page a person browses later. |
| The three things it has to get right | Who produces context (supply), how an agent consumes it (delivery), and whether the system notices and repairs its own gaps (self-correction). |
| What it solves | Documentation backlogs that never close, context an agent cannot reliably retrieve, and no mechanism for finding out why an answer was wrong. |
| How it’s measured | Not coverage. Whether an agent asked a real question got the right answer, and if not, why not. |
| Proof at scale | Mastercard enriched 30,000+ assets and recovered 6,200 hours of steward time in two weeks by scoping to what mattered most first. |
Why manual metadata curation could never scale
The person who writes a column description is almost never the one who benefits from having written it. Someone else, on a different team, months later, gets the payoff while the person who wrote it gets nothing back for the time it cost. That mismatch, not laziness or bad tooling, is why documentation backlogs never close. Economists call this a public-goods problem: the cost is individual, the benefit is shared, and shared benefits chronically get under-produced.
This predates AI by decades. Data dictionaries, master data management programs, and formal governance frameworks all ran into the same wall: someone has to do unrewarded work so someone else can benefit later, and that work reliably does not happen at the pace an organization needs. What AI-assisted enrichment actually changes is not that a machine is smarter than a person. It is that evidence, such as SQL query history, pipeline code, and BI semantics, can generate a first draft automatically, so nobody has to volunteer. A human reviews and certifies instead of starting from a blank field. That is the fix to the real problem, not a faster version of the old one.
The catalog still has to know what it does not know. An automated draft is only useful if the system that produced it can be trusted to flag its own gaps, which is the second half of this problem and comes later. First, delivery has to work, because generating context nobody can retrieve accurately is its own kind of waste.
Why serving an AI agent isn’t the same problem as serving a person
A human who cannot find what they need asks a follow-up question. An agent making a tool call usually cannot, it commits to an interpretation and acts on it, which means a wrong guess is no longer a private confusion, it is a query, a write, or a decision. That single difference explains why putting metadata where people already work, a Slack channel, a wiki page, a ticket, was real progress for humans and is not sufficient for agents.
The mechanism is not just intuition. According to Liu et al. (2023), language model accuracy is highest when relevant information sits at the beginning or end of the context an agent is given, and degrades measurably when the right answer is buried in the middle, even in models built for long context windows. A bigger context is not automatically a better one. A smaller, correctly ranked slice of context reliably beats a larger, noisier one.
That is the case for a protocol like MCP: a governed interface that returns a scoped, typed result instead of a page for a person to scroll. It only works, though, if it is built around how agents actually query, not how a catalog assumes they will: a semantic search tool and sub-graph lineage retrieval instead of full-graph traversal. Smaller, better-ranked context is not a nice-to-have. It is the difference between an agent that reasons correctly and one that reasons on noise.
Why “how much is documented” was always the wrong scoreboard
A confident wrong answer is worse than no answer: the person asking trusts it, acts on it, and only finds out later, if at all, that the agent was wrong. Almost nobody can then tell whether the cause was a documentation gap, a bad retrieval, or the wrong model for the job. Extensible tooling, more APIs, more webhooks, does not fix this. A system can be fully open and still have no idea what it does not know.
Traditional catalogs measured themselves by what existed: assets documented, terms defined, seats onboarded. None of that answers the question that actually matters, which is whether an agent asking a real question gets the right one back.
There is a direct way to check this yourself. Take ten questions your team actually asks every week, run them against your current setup, and score each one answered, wrong, or unknown. That ratio is a far more honest maturity signal than any percentage of assets documented, because it measures outcomes instead of inventory. A catalog that is 90% documented and answers three of ten questions correctly is not 90% ready. It is 30% ready.
Coverage was always a proxy. Answers are the actual thing being measured.
What it takes for a catalog to improve itself
A catalog that scores its own answers still needs somewhere to route what it learns. The mechanism is structurally familiar to anyone who has worked with machine learning evaluation: simulate a real question, score the answer for completeness and correctness, route the gap to whatever can fix it, then re-ground and repeat. It is the train-serve-monitor-retrain loop, applied to metadata instead of model weights. Not a new invention, just the same discipline evaluation harnesses have used for years, pointed at a catalog’s own blind spots instead of a model’s.
Two things are worth being honest about here. First, preference is not correctness: when users say AI-generated descriptions read better than human-written ones, that is a fluency judgment, not an accuracy audit. Second, review does not disappear in a self-improving system, it moves from writing to reviewing, and reviewing has its own failure mode: a steward who rubber-stamps an AI draft without reading it has replaced one problem with a quieter one. A loop that checks completeness without checking correctness just gets confidently wrong faster.
Done honestly, though, this compounds. It is not proof of the loop in isolation, but it is evidence that the underlying discipline, evidence-generated context checked by a human, works at real scale. At a recent session of Context in Practice, Atlan’s live series where real teams share what it actually took to ship AI-generated context inside their own enterprises, Atlan reported that its customers have generated over 2 million AI-generated descriptions and recovered more than 210,000 steward hours between them, across 200-plus organizations.
The three shifts, together
Put the last few sections side by side and a pattern holds: each axis moves independently, and a catalog can still fail on any one even after fixing the other two.
| What has to work | Old failure mode | What actually fixes it |
|---|---|---|
| Who produces context | Manual entry nobody was incentivized to do | Context generated from evidence: query history, pipeline code, usage patterns |
| How an agent consumes it | Context placed where people work, not where agents call | A governed, typed interface built around real agent query patterns, not assumed ones |
| Whether the system learns | Static once published, no way to know what it was missing | A loop that simulates real questions, scores answers, and routes the gap back to get fixed |
A team can automate documentation and still fail agents if delivery is wrong. It can fix delivery and still stagnate because nothing tells it what is missing. All three have to hold at once.
Inside Mastercard’s two-week sprint to make its catalog agent-ready
Mastercard hit a familiar ceiling before fixing any of this: a data estate growing faster than a small team could document it, AI initiatives raising the cost of getting a definition wrong, and metadata ownership spread across teams with no single throughline. Zhenni Hu, Manager of AI and Data Governance at Mastercard, described a team drafting descriptions from scratch, working from memory and tribal knowledge, at a pace measured in days per domain.
The approach was deliberate rather than exhaustive. Mastercard scoped to a controlled set of assets first instead of attempting the entire estate at once, grounded decisions in real evidence, query patterns, lineage, and the existing glossary, rather than guesses, and kept stewards certifying every change rather than removing them from the loop. Hu described the shift plainly: her team moved from writing data descriptions from scratch to certifying what AI generates at scale, which is judgment work, not documentation work.
The result, in two weeks: more than 30,000 assets enriched and 6,200 hours of steward time recovered. Work that took days per domain now takes minutes per asset. The team did not get smaller. It got redirected toward the calls that actually need a person, not the ones that only needed someone to type.
Real stories from real customers: Metadata that serves agents, not just people
"AI initiatives require more context than ever. Atlan's metadata lakehouse is configurable, intuitive, and able to scale to hundreds of millions of assets. As we're doing this, we're making life easier for data scientists and speeding up innovation."
— Andrew Reiskind, Chief Data Officer, Mastercard
"Atlan captures Workday's shared language to be leveraged by AI via its MCP server. As part of Atlan's AI labs, we're co-building the semantic layer that AI needs."
— Joe DosSantos, VP, Enterprise Data and Analytics, Workday
Why the standard for a data catalog just changed
None of this was ever about picking the right tool. It was about noticing that a well-funded, well-staffed catalog can still fail an agent, because supply, delivery, and self-correction are three separate engineering problems with three separate failure modes. Fixing one does not fix the others.
The honest version of “AI-ready” is not a feature list. It is a catalog that generates context from evidence instead of asking someone to volunteer it, delivers a small and correctly scoped result instead of a page to browse, and knows when it got something wrong, then goes and fixes it. Mastercard’s two weeks are the proof that this does not require rebuilding the entire data estate at once. It requires deciding, honestly, what your catalog cannot yet answer, and building toward that.
FAQs about data catalog for AI
1. What is the difference between a traditional data catalog and a data catalog for AI?
A traditional data catalog is built for human discovery: helping analysts find and understand data assets. A data catalog for AI goes further by generating context from evidence rather than manual entry, and by exposing it through a governed interface an agent can call at the moment it reasons, not a page it has to browse.
2. Why did manual data cataloging fail at most enterprises?
Not carelessness. A structural incentive problem: the person who writes a column description rarely benefits from having written it, and someone else, months later, benefits from reading it. That mismatch is why documentation backlogs never closed, regardless of which catalog tool an organization used.
3. Why is serving an AI agent different from serving a human user?
A human tolerates ambiguity by asking a follow-up question. An agent mid tool call usually cannot: it reasons inside a fixed context budget, where extra, irrelevant material can lower accuracy rather than just cost more. Agents also call typed functions, not pages, which is why delivery mechanisms like MCP exist.
4. What is the difference between a data catalog for AI and a metadata knowledge graph?
A metadata knowledge graph is one component of a data catalog for AI. It encodes relationships between assets, terms, and metrics as a graph, so an agent can traverse connections instead of querying isolated records. The data catalog adds discovery, lineage, governance, and MCP server delivery on top of that graph.
5. How should a team measure whether its data catalog is actually ready for AI agents?
Not by percentage of assets documented. Take ten real questions your team asks weekly, run them against your current setup, and score each one answered, wrong, or unknown. That ratio is a more honest maturity signal than coverage, because it measures whether an agent actually gets the right answer rather than whether a page exists somewhere.
6. Does a data catalog for AI replace a semantic layer?
No. A semantic layer defines what a metric means and how it is calculated. A data catalog for AI wraps that definition with lineage, quality signals, governance, and usage patterns, then delivers all of it to an agent at runtime. The semantic layer is one input into the catalog, not a substitute for it.
7. How long does it take to make an existing data catalog AI ready?
It depends on scope, not total data volume. Mastercard enriched more than 30,000 assets and recovered 6,200 hours of steward time in two weeks by starting with the assets queried most and riskiest to get wrong, not the entire estate at once.
8. Can AI-generated metadata be trusted without human review?
Not on its own. Preference is not correctness: surveys showing readers prefer AI-written descriptions measure fluency, not accuracy. Review does not disappear when AI drafts metadata, it moves from writing to certifying, and that step still needs to be real, not a rubber stamp.
Sources
- Lost in the Middle: How Language Models Use Long Contexts, arXiv
- Context in Practice: The Rise of the Agentic Data Catalog, Atlan
- Enhanced Metadata Improves AI Query Accuracy, Atlan AI Labs
- Gartner Magic Quadrant for Data & Analytics Governance Platforms 2026, Atlan
- Gartner Critical Capabilities for Metadata Management 2025, Atlan
- Forrester Wave: Enterprise Data Catalogs Q3 2024, Atlan
Data catalogs built for AI are evolving into context delivery platforms. The Enterprise Context Layer Hub collects 53+ guides on how catalogs, context graphs, and governance connect to power production AI.
