Five reasons data catalogs can't be a context layer

A data catalog is a description of your data assets, harvested on a schedule and organized around tables and pipelines. An AI agent needs a runtime model of your business: entities resolved across systems into structure it can traverse at query time. Renaming the catalog does not bridge that gap, and there are five structural reasons why.

The short version

• Catalogs run on scheduled metadata harvests; agents reason in a loop at query time, against live state.
• A column description is documentation. The agent needs structure it can traverse: entities and the relationships between them.
• Catalogs organize around assets (tables, columns, dashboards, pipelines); the business runs on entities (Customer, Account, Order, Contract), and resolving one from the other is the context layer's entire job.
• Hand-authored ontologies do not scale. The agent needs one inferred from the data itself, with confidence scores and a domain expert reviewing the result.
• The catalog category's DNA is governance. Keep the catalog for that job; the context layer is a different product for a different buyer.

A pattern has emerged across the enterprise AI market. Vendors that built data catalogs for the business intelligence era are now selling them as the foundation for the agentic era. Same product, same architecture, same SKU, new homepage. The pitch goes something like this: your agent needs context, your catalog has metadata, metadata is context, therefore your catalog is your context layer. Quod erat demonstrandum.

It's a clean story. It's also wrong.

I work at a company that builds an actual context layer, so the bias here is obvious and worth stating up front. I'm writing this because the catalog rebrand is going to cost enterprises a lot of money and a lot of time, and the people who have to live with the consequences (architects, AI platform teams, the engineers who get paged when the agent confidently answers a question with the wrong number) deserve to know what they're walking into.

Every Fortune 500 I've walked into in the last six months has a data catalog. Not most. Every single one. Sometimes two, because the first one didn't work and nobody got around to turning it off. Catalogs solve real problems: discovery, lineage, classification, governance, the kind of work that keeps auditors and chief data officers in the same room without anyone reaching for a chair. They earned their place in the stack the hard way and they aren't going anywhere.

The catalog can stay. The rebrand is what I'm picking on.

Sometime in late 2024, the word “context” started appearing on catalog product pages, and by mid-2025 it was on the homepage. By the time I'm writing this, every catalog vendor in the market has launched or announced an AI context feature or an agent-ready metadata layer. The marketing teams have been busy. The engineering teams have been busier explaining to enterprise architects why the demo only handles questions that touch one table.

Five structural reasons the rebrand won't hold.

1. Catalogs are harvest pipelines. Agents need runtime systems.

The catalog's core architecture is a scheduled metadata harvest. A crawler walks your warehouse, your dashboarding tool, your ELT jobs, and your git repo of dbt models, then lands what it finds in a search index. Refresh frequency varies; “nightly” is generous, and “weekly” is honest.

This was the right architecture for the original job. Helping an analyst find the right table at design time does not require sub-second freshness. The analyst is going to spend a week building the model anyway.

Agents don't work that way. An agent reasons inside a loop at query time, against live state. It picks a tool, calls it, gets a result, decides what to do next, calls another tool, often within a few hundred milliseconds per step. A nightly metadata refresh hands that loop a snapshot of what the data looked like the last time someone remembered to run the crawler.

The gap is structural. The constraints the agent reasons with are only as fresh as the harvest that produced them, while the data underneath keeps moving; the two are maintained on separate clocks, and a catalog has no mechanism for closing the distance between them.

You cannot bolt runtime semantics onto a harvest pipeline by changing the marketing copy. The foundation was poured for a different building.

2. Descriptions are not semantics.

Catalogs ship a feature called, depending on the vendor, a “business glossary” or a “data dictionary,” or, lately, something involving the word “context.” The feature lets a human write a sentence about a column. customer_id is the unique identifier for the customer. revenue_usd is monthly recurring revenue, in US dollars, after discounts but before refunds, refreshed at 2am Pacific.

These are documentation, and documentation is useful. What an agent needs is different in kind.

An agent reasoning across your business is working out that Customer is an entity, that Customer has an Account, that an Account holds Subscriptions, that a Subscription has a Plan, that the Plan determines a Tier, that the Tier drives a discount applied to revenue_usd, and that all of this is sourced from four different systems with three different definitions of “active.” The agent needs to know how things relate, held somewhere it can traverse. A sentence someone wrote in a description field at deployment time, untouched since, carries none of that.

A description is a sentence, and semantics is a graph: a network of entities and how they relate. The catalog ships sentences and increasingly markets them as graphs. The marketing is free; the graph is not.

3. Catalogs organize around assets. Businesses run on entities.

Open any catalog. Browse the navigation. You'll see tables, columns, dashboards, pipelines, jobs, schemas, and lineage edges between them. This is the data engineer's mental model, and it's correct for the data engineer's job.

Now ask any executive how their business works. They'll tell you about Customers, Accounts, Products, Contracts, Orders, Tickets, Campaigns. None of these things appear in your catalog as first-class objects. They're scattered across tens or hundreds of tables, half of which are named after the system that produced them rather than the thing they describe. The data model was never the business's model of itself; that model, in most enterprises, lives in the heads of the experts who built the systems.

A catalog can tell you that crm_accounts.id and billing_subs.account_fk both exist. It cannot resolve them into a single Account entity that an agent can traverse from sales to billing to support to product telemetry. That resolution is the entire job of a context layer, and it is a different category of product from the catalog.

I've watched catalog demos handle this by adding a “business object” tab where someone manually labels which tables represent a Customer. It works in the demo, and it collapses at the scale of a real enterprise, for the reason in the next section.

4. Manual ontology authoring does not scale, and “AI-assisted” doesn't mean what the slide says.

The catalogs that have shipped ontology features require humans to define them. Click new entity, type Customer; click add property, type email. Repeat for ten thousand more entities and a hundred thousand more properties, then keep them current as the underlying schemas drift. The data team that cannot keep column descriptions accurate is going to maintain a hand-built ontology in their copious free time.

Some vendors have responded by adding AI assistance to ontology authoring. In practice this means a large language model auto-fills the description field with a paraphrase of the column name. customer_id becomes “the customer identifier.” Useful, in the sense that filling in a form faster is faster than filling in a form slower.

What the agent actually needs is an ontology inferred from the data itself: entity resolution run against the records rather than the labels, confidence scores on every inference, reasoning a reviewer can trace, and a workflow that lets a domain expert review and refine the result instead of authoring it from scratch. The inference will be wrong in places, which is exactly why the review workflow is load-bearing. Delivering that takes an inference engine sitting on a graph store, processing the actual data rather than its metadata alone, and a feature on top of a catalog does not get there. It points at a different stack, a different roadmap, a different product surface, and eventually a different company.

5. The category was built for governance. Reasoning is a different sport.

A category's DNA is the buyer it was built for, and the catalog category was built for the chief data officer and the data governance team. The roadmap reflects it. Lineage, compliance reports, sensitive data classification, access policies, audit trails. These are good products solving real problems for the people who buy them.

Agent reasoning is a different problem, bought by a different buyer: the AI platform lead, the head of applied AI, the architect tasked with making the agent strategy actually work, and increasingly the CIO asking where the context layer lives. The success metric moves with them, from a happy auditor to the agent getting the right answer across systems. So does the product surface, from a UI a human browses to a runtime API the agent calls.

A category can change its marketing in a quarter; its DNA does not change in a quarter. The engineers who built lineage features for seven years will not wake up Monday morning as graph reasoning experts, and the customers who bought the catalog for their auditors will keep asking for what they bought it for. The roadmap follows the customers paying the bills, and those customers want the next compliance report rather than the next agent primitive.

Categories work this way, no moral failing involved, and it is exactly why the rebrand won't hold.

So what do you do with the catalog you already bought?

Keep it, and use it for what it's good at. Lineage is genuinely hard and governance is genuinely necessary. Discovery still beats running a wiki search across a thousand tables, and none of that goes away because agents arrived.

But when your CIO asks where the context layer for your AI strategy lives, don't point at the catalog. The catalog is a description of your data assets. The context layer is a runtime model of your business. They are different products for different buyers. The vendors telling you otherwise are hoping the rebrand sticks before the architecture catches up. So far the architecture is winning.

If you want a quick test, ask your catalog vendor's sales engineer to demo, in real time against live data, a question that traverses three systems and four entities, with the agent showing its reasoning. Then ask what fraction of their roadmap is going to that capability versus the next governance feature their largest customer asked for. The answer will tell you everything you need to know about whether they're building a context layer or rebranding the one they already have.