Snowflake logoAgents

Stop Letting Your AI Agent Guess What Your Snowflake Columns Mean

Ask a capable AI agent to "join orders to customers" in a warehouse it has never seen, and watch what it actually does: it reads column names and guesses. `CUSTOMER_ID` probably matches `ID` on the customers table. `STATUS` probably takes values like `'active'`. That JSON blob in `PAYLOAD` probably has a `user_id` inside. The SQL it writes will be syntactically flawless and semantically hopeful — and hopeful SQL in an analytics pipeline is how confident wrong answers get made at scale.

Stop Letting Your AI Agent Guess What Your Snowflake Columns Mean

Ask a capable AI agent to "join orders to customers" in a warehouse it has never seen, and watch what it actually does: it reads column names and guesses. CUSTOMER_ID probably matches ID on the customers table. STATUS probably takes values like 'active'. That JSON blob in PAYLOAD probably has a user_id inside. The SQL it writes will be syntactically flawless and semantically hopeful — and hopeful SQL in an analytics pipeline is how confident wrong answers get made at scale.

This isn't a model-quality problem. It's a grounding problem, and Snowflake estates make it unusually acute.

Why a warehouse is hard terrain for an agent

Even an agent with full read access to INFORMATION_SCHEMA only sees structure — and Snowflake structure systematically underdocuments intent. Key declarations are informational and frequently absent, so join paths aren't recorded anywhere machine-readable; every relationship is an inference from naming conventions. There are no enforced CHECK constraints, so the allowed values of a category column — the thing an agent needs to write a correct filter — simply don't exist in the catalog. Table comments are optional and usually missing. And VARIANT columns are the worst case: semi-structured payloads whose inner shape is invisible to any consumer that hasn't already parsed the data.

We take this seriously enough that agent legibility is baked into our audit rules for Snowflake. The semi-structured-column finding warns that a VARIANT, OBJECT, or ARRAY column "carries ungoverned semi-structured data — its inner schema is invisible to consumers and agents." The table-no-comment finding notes that "undocumented objects resist governance and agent grounding." When we audit an estate, we are literally scoring how well an AI agent could be grounded in it.

What grounding actually looks like

The CoreModels Snowflake integration turns the estate into governed facts an agent can consult instead of guess at. After import — built from three credential-free queries you run in Snowsight — every table and view is a governed Type with the stable identity DB.SCHEMA.TABLE; every column is an Element carrying its exact native type; declared primary keys are uniqueness checks; declared foreign keys are explicit governed references between Types; object dependencies are lineage relations; and comments are descriptions. And because Snowflake itself has nowhere to record a column's allowed values, the governed model is where the team adds them — as governed taxonomies attached to the columns they constrain. The difference for an agent is categorical: "these two columns have similar names" is a hunch, while "this Element carries a governed reference to that Type" is a fact with provenance.

MCP: consultation instead of speculation

Those facts are served where agents live. CoreModels exposes an MCP server — connect an agent to https://coremodels.example.com/mcp, authenticate over OAuth, and the governed model becomes a set of tools rather than a document to summarize. An agent starts with list_projects and get_project_summary to orient itself, uses search_nodes to find the entities a question mentions, and reads the same governed identities, types, references, and lineage a human reviewer would.

The integration verbs are agent-callable too. get_vendor_integration_status reports which connectors exist and what was last imported for a project. audit_vendor_project lets an agent run the full Schema Audit itself — hand it a fresh INFORMATION_SCHEMA extract, inline or by URL for large estates, and it gets back the coverage, drift, and conformance findings with machine-readable codes and counts. That turns an agent from a consumer of stale documentation into an active checker: "does this extract still conform to governed meaning?" is one tool call with a numeric answer.

The permission boundary is part of the design. The public MCP endpoint serves read-only tools at Viewer role; write operations such as import_vendor_project live on a separate admin endpoint and require real project membership at the appropriate role. An agent can look up anything, verify anything, and propose anything — but changing governed meaning still passes through humans holding the right permissions. Grounding without gatekeeping would just relocate the risk.

The same question, before and after

Before: "What's in EVENTS.PAYLOAD?" produces a paragraph of confident speculation based on the column name and whatever sample rows the agent could see.

After: the agent consults the governed model and answers with facts — the column's native type is VARIANT, its governed status is explicitly ungoverned inner schema, flagged by the audit as a semi-structured-column warning — and it says so, instead of inventing a structure. An honest "this is not governed yet, and here is the finding that says so" is worth more than a fluent guess, because it's actionable: it tells the team exactly where grounding is missing.

That's the general pattern. Agents don't need our data model to be perfect; they need to know precisely which parts are governed, which are approximate (the model records its own lossiness, down to NUMBER(38,2) being carried as a Double with the native string preserved), and which are blank. Precise semantics, honestly bounded, beat comprehensive-sounding structure every time.

Agents as governance participants

The end state isn't just agents consuming governance — it's agents helping maintain it. An agent in your CI pipeline can run the audit on every schema change and explain the findings on the pull request. An agent in a chat window can answer "what breaks if we drop this column?" from governed lineage instead of tribal memory. The governed model gives them all the same thing it gives your team: a shared, inspectable account of what the warehouse means — so the answer to "how do I join orders to customers?" is finally a lookup, not a guess.

Connection details, tool names, and the extraction queries are in the CoreModels Snowflake quickstart in our docs — pointing an MCP-capable agent at a governed project takes a few minutes.