The Data Catalog Is Becoming the Control Plane for AI Agents
Catalogs were where documentation went to die. Agents change the economics: they need machine-readable meaning, ownership, freshness, and entitlement.
An agent is asked how many readmissions the hospital had last quarter. It finds a table called enc_fact_v2, writes syntactically perfect SQL, and returns 1,284. The number lands in a board deck.
Nobody can answer the follow-ups. Which of three competing readmission definitions did it apply? Was that table refreshed after the last ETL failure? Was the service account it ran under allowed to read rows from every facility, including the two the requester has no business seeing?
That failure mode is pulling the data catalog from the periphery of the stack to the centre. Alation’s July 2026 launch of AIOS — an “intelligence operating system” layered on its catalog to coordinate data, context, and agents — is the loudest signal, and TechTarget read it right: a transition from catalog vendor to control plane for autonomous agents. IBM shipped an agentic control plane in watsonx Orchestrate; Microsoft and Atlan are converging on the same shape. When vendors independently redraw their product boundary this way, the category is moving, not the marketing.
Ten years of documentation nobody read#
Be honest about where catalogs have been. Most were bought during a governance push, populated by a crawler, seeded with a few hundred descriptions by a steward who has since left, and abandoned. The catalog became a compliance artifact — a thing you show an auditor, not a thing you use on a Tuesday.
The reason is economic, not technical: documentation only pays off if someone reads it, and humans routed around it. Whoever needed to know what enc_fact_v2.disch_dt meant pinged the one person on Slack who knew. Tribal knowledge beat the catalog on latency, so the catalog never earned the usage that would have justified maintaining it. Death spiral.
Agents break that equilibrium, because an agent cannot ping anyone. It has no colleague and no instinct that a column named status went unreliable after the 2024 migration. It has whatever metadata it can retrieve at runtime, and when that is missing it does not stop — it guesses, fluently. Alation’s CEO put it bluntly: “85% right is 100% wrong” when the output is a lawsuit.
Four questions an agent must resolve before it touches a row#
Strip away the vendor framing and the requirement is concrete. Before an agent executes a query it needs machine-readable answers to four things:
- Meaning — what this column represents in business terms, edge cases and the definition that changed in March included.
- Ownership — who is accountable, and who you escalate to when it is wrong.
- Freshness — when it was last updated, and whether that is inside this question’s tolerance.
- Entitlement — whether the human the agent is acting for may see these rows and these columns.
Now look at where each answer lives. Meaning is split across a dbt YAML file, a Confluence page from 2023, and the head of a senior analyst. Ownership is in a spreadsheet, or inferred from git blame. Freshness is in the orchestrator — Airflow knows the DAG succeeded, but that fact never reaches the catalog. Entitlement sits in warehouse RBAC, an identity provider, and increasingly a policy engine the catalog has never heard of.
Four answers, four systems, none queryable in a single call. Survivable when the consumer was a human with a Slack account; not survivable when it is a loop firing a hundred times an hour. Consolidating those four answers behind one interface is the entire content of the “catalog as control plane” claim. Everything else is packaging.
Entitlement cannot live in the prompt#
Of the four, entitlement is the one teams get catastrophically wrong, and always the same way: they put the access rules in the system prompt. “The user is a ward nurse at Facility 3. Only answer questions about patients at Facility 3.” It demos beautifully. It is not access control — it is a polite request to a stochastic text generator, and it fails under three ordinary conditions: a clever user, a tool result carrying injected instructions, and a model update that reweights the system prompt.
The middle one needs no malicious user. The injection arrives through retrieved content — a document, a ticket comment, a field in a record — which enters context indistinguishable from instructions. Aptible’s writeup of tool poisoning and blast radius in MCP describes the outcome: an agent provisioned for weekly reporting gets talked into a query returning customer PII. It did nothing it was not technically permitted to do — that is the point. It held a credential broader than the request it was serving, and text was all that stood between the two.
The fix is unglamorous: enforce at query time, in the engine, under the identity of the requesting human. Row- and column-level policies defined once at the catalog layer and pushed down, so the agent physically cannot retrieve a row it should not see. Credential passthrough instead of a shared service account. Masking applied before results are serialized, because anything reaching the context window eventually reaches a log or a user.
The rule: if your access control would survive rewriting the system prompt to “ignore all restrictions,” it is real. If not, you have a suggestion.
Lineage as the audit trail for agent actions#
The second shift is what lineage is for. Historically it was an impact-analysis tool: which dashboards break if a column is dropped. Useful occasionally, rarely urgent.
With agents in the loop it becomes the evidence chain. When a regulator or a CFO asks why the system produced a given answer, the defensible response is not “the model said so.” It is a trace: this agent, acting for this identity, called this tool, which resolved to these tables, derived from these sources through these transformations, last refreshed at this timestamp, under these policies. Column-level granularity is what makes that worth anything; table-level lineage says the number came from somewhere in the warehouse, which is no defence.
Two implications. Lineage has to be captured from execution rather than declared by hand — which is why the OpenLineage standard and query-log inference matter more than a diagramming tool, and why stale lineage in an audit is worse than none. And agent tool calls must themselves be lineage events; if an agent’s reads are not in the graph, your audit trail has a hole exactly where the interesting behaviour lives. Atlan’s framing, that agents query the lineage graph before using any data, turns lineage from post-incident forensics into a pre-execution check.
Catalog as a tool, not a schema dump#
The architectural mistake that quietly caps how good these systems get is dumping the schema into context: serialize every table the agent might need into the system prompt and let the model figure it out. It works for twelve tables; at two thousand it is impossible, and at every size it is stale the moment a migration lands. A schema dump is also structure without semantics: it says disch_dt is a date, not that discharge date is null for in-progress encounters, or that the table is certified for operational reporting but not regulatory submission.
The pattern that scales is the catalog as a callable tool. The agent does not receive the schema — it receives the ability to ask. search_assets for candidates, get_asset_context for definition, owner, certification, freshness and applicable policy, get_lineage for provenance, then and only then a query. Context stays small and current, and every retrieval is logged, which gives you an access pattern you can audit and an eval surface you can measure.
The Model Context Protocol made this cheap to wire up, which is exactly why connectivity keeps getting mistaken for governance. Atlan’s analysis of MCP-connected catalogs names the failure well: silent content failure, where the agent reaches a fully authenticated server, receives stale metadata, and returns a fast, well-formatted answer that happens to be wrong. Their read of a 2026 measurement study also found a large share of live MCP servers running with no authentication at all.
In a Hospital Management System, entitlement is the whole ballgame#
Every enterprise has an entitlement problem. Healthcare’s is legally enumerated, which makes it the clearest place to see what the catalog must carry. “Can this identity see this row” is not a flag. It is a composite of role, department, facility, care relationship, purpose of use, consent status, and record sensitivity — behavioural health and reproductive care carry stricter rules than the rest of the chart, and those rules bite at the row and column level inside tables everyone otherwise reads.
None of that survives being expressed in a prompt. It has to be policy the query engine enforces, with the catalog as the place that policy is defined, versioned, and discoverable — so an agent asking about a cohort gets back the lawful cohort, and the log shows who asked, on whose behalf, and why. The same structure governs a School ERP: a teacher, a counsellor, and a parent each see a different slice of a student record, and an agent that flattens those distinctions has created a disclosure incident.
Legacy ERP vendors are structurally disadvantaged here. Their entitlement logic is buried in application code and stored procedures, expressed in screens rather than data, unreachable by anything that does not enter through their UI. You cannot expose that to an agent without rebuilding it or handing over a god-mode service account. Building the ERP as a data platform with thoughtful UI on top — policy at the data layer, the interface one consumer among several — is what makes Operational Automation tractable.
Most catalogs are not ready, and here is what ready means#
Blunt assessment: the catalog you own almost certainly cannot serve this workload. Coverage is partial, descriptions are stale, ownership is fictional, freshness is untracked, policy lives elsewhere. Buying an agent-governance SKU on top of that inventory puts a well-lit lobby in front of an empty building.
Ready is a short list because each item is hard:
- Programmatic-first. Every fact a human sees in the UI is retrievable via API in one call, at a latency an agent loop can afford.
- Semantics, not schema. Definitions, valid values, caveats, certification scope — maintained as a product with an owner.
- Freshness as a live signal, so an agent can refuse to answer from a table that missed its SLA.
- Policy defined once, enforced in the engine, under the end user’s identity.
- Lineage captured from execution, column-level, agent calls included.
- Metadata treated as production infrastructure. If your catalog’s staleness pages nobody, it is not ready.
The catalog was the least interesting system in the data estate for a decade because its only consumers were humans who could route around it. It is interesting again for an unsentimental reason: agents cannot, and everything they get wrong, they get wrong at speed and in complete sentences. That is not a governance story — it is the load-bearing part of any serious AI implementation.
Agents are only as trustworthy as the metadata they can query at runtime. If you are wiring agents to production data and the catalog is the weak link, /#contact.