Pasting Your Schema Into the Prompt Is Not Grounding

The standard way to make an AI agent useful against a warehouse is to give it the schema: dump the DDL, or scrape INFORMATION_SCHEMA into a text blob, and paste it into the context window with "use this to answer questions about our data." It works well enough to demo, which is why it survives long enough to cause problems.

But it is not grounding. Grounding means the model's claims are anchored in facts someone can check, and a schema dump fails that test four ways that no amount of prompt engineering repairs.

It carries no meaning. T-SQL's INFORMATION_SCHEMA — the surface a Fabric Warehouse, SQL analytics endpoint, or SQL Server database presents to any tool — has names, types, ordinal positions, and nullability. It has no descriptions. In SQL Server, documentation lives in extended properties, which most estates never populate and most extraction never reads. The agent learns a column is nvarchar(200) and nothing about what belongs in it.

It carries no relationships. Warehouses are full of key-shaped columns with no declared PRIMARY KEY or FOREIGN KEY. Our own audit has a finding for this, and its wording is the thesis of this article: relationship intent is invisible to tools. An agent is a tool. Faced with CustomerId in one table and Id in another, it pattern-matches on names and writes a confident join. Usually the convention holds. Occasionally CustomerId is a migration leftover, the real key is elsewhere, and the query runs, returns rows, and is wrong.

It has no freshness signal. A pasted schema is a photograph with no timestamp: the agent cannot tell whether it reflects this morning's estate or last quarter's, and has no way to find out.

It cannot be verified. Nothing in the blob distinguishes a fact from a guess, so nothing downstream can either — the agent's confidence is uniform across what it knows and what it invented.

What the agent actually needs is declared facts

Once a Fabric or SQL Server estate is governed in CoreModels, the picture the agent consults is different in kind from a schema dump: everything in it was either extracted from a declaration or reviewed by a person.

Each table and view is a governed Type with the identity database.schema.table. Each column is an Element carrying its reconstructed native type — varchar(200), nvarchar(max), decimal(18,2), with bit as Boolean — and its nullability as an explicit check rather than a string to parse. Declared primary keys are uniqueness checks, grouped by constraint so a composite key reads as one key rather than three coincidences. Foreign keys are governed references: real, queryable relationship facts.

And because the T-SQL extract carries no descriptions, the governed graph is the estate's documentation home — meaning written down and attached to the node it describes, rather than scattered across pages nobody updates.

For an agent, that is the difference between "these columns probably join because their names rhyme" and "the governed model declares a reference from this column to that table" — a guess with a confidence score versus a fact with provenance, imported from the warehouse's own constraint rows or curated by a human, and checkable either way.

Consultation beats retrieval

The other half is when the agent gets the facts. Prompt-stuffing is retrieval: someone decides in advance what the agent will know. Consultation is the agent asking at the moment it needs to know, through a protocol built for the purpose.

CoreModels serves a read-only Model Context Protocol endpoint that any MCP-capable client can connect to: https://coremodels.example.com/mcp, protected by OAuth. Every tool on it runs at Viewer role and declares an explicit read-only hint, so an agent platform can verify the posture rather than trust a description.

A grounded session has a natural shape. The agent lists the projects it can see, pulls a project summary — the types, elements, and taxonomies of the governed estate — and searches the nodes relevant to the question in front of it. Before relying on any of it, it asks get_vendor_integration_status for the fabric vendor and learns when the estate was last imported and what state was recorded — turning freshness from an unknown into an answer.

When freshness matters, the agent can go further: with a current extract in hand, audit_vendor_project returns the full coverage, drift, and conformance report — the same coded findings and counts the CI gate uses, including whether any column's type has drifted from governed meaning. Extracts too large to inline can be passed as URLs, which the server fetches under strict guards — HTTPS only, redirects disabled, internal and private addresses refused, response size capped. An agent that audits before it answers knows whether its ground truth is current — something no amount of context-window capacity provides.

The loop closes in the generating direction too: generate_vendor_artifacts produces the governed T-SQL CREATE TABLE DDL for the estate, derived from reviewed meaning rather than the agent's own reconstruction.

The boundary that makes it safe

For agentic systems, the most important design decision here is the write boundary.

Everything above — summaries, search, exports, status, audit, generation — is read-only and served on the public endpoint. The tools that write, including estate import and cross-estate reconciliation, are served only on a separate admin endpoint and require Admin membership in the project. Even then, import is additive: it adds new objects and never mutates or deletes what is already governed. Changing what something means remains a human act performed against evidence.

That split is what makes it reasonable to hand agents real schema knowledge. An agent can know everything the governed model knows, verify how current that knowledge is, and detect drift against live artifacts — while being structurally incapable of rewriting the ground truth it is standing on. Grounding without that boundary is a feedback loop in waiting: a system that can edit its own facts eventually agrees with itself about everything.

The takeaway

Enormous effort goes into making agents sound authoritative about estates nobody ever told them about. The cheaper and sturdier path is to make the estate legible: two documented INFORMATION_SCHEMA queries, one import, and your Fabric Warehouse or SQL Server schema becomes a governed model with declared types, keys, references, and a real home for meaning — served to any agent over one OAuth-protected endpoint, with drift detection included.

Agents do not need to get smarter about your warehouse. Your warehouse needs to stop being a guessing game.

The Microsoft Fabric quickstart in our docs covers the extract, the import, and the agent-facing tool calls against a governed estate.