Stop Letting AI Agents Guess What Your dbt Columns Mean

Large language models are dangerously good at plausible schemas. Ask an agent to write a dbt model joining orders to customers and it will produce clean SQL against customer_id, confidently test status for values like active and cancelled, and cast order_total to a sensible numeric type. Every one of those choices is a guess dressed as knowledge. In your estate the key might be customer_key, the status taxonomy might include partially_refunded, and order_total might be governed as a decimal for a regulatory reason no manifest comment explains. The SQL parses. The guesswork ships.

This is the specific failure mode agents bring to data work: not incompetence, but ungrounded competence. And it is exactly the failure a governed dbt estate eliminates — because the fix for guessing is not a better prompt, it is a queryable source of truth.

Grounding: from "probably" to "is"

Once a dbt project is imported into CoreModels, everything an agent would otherwise infer becomes a fact it can look up. Models, seeds, snapshots and sources are governed types; columns are elements with data types; accepted_values tests are taxonomies; relationships tests are references; the dependency map is lineage. Each governed node also carries its vendor identity — the mapping back to the exact dbt resource, like model.jaffle_shop.orders — plus dbt-specific metadata such as the native warehouse type, the materialization and the contract flag.

The difference in agent behavior is not subtle. "What values can order_status take?" stops being a distribution over training data and becomes a read of a governed taxonomy. "What breaks if I retype this column?" becomes a lineage walk instead of a shrug. "Which models are public API surface?" becomes a metadata query. Grounded agents don't just answer more accurately — they can decline to invent, because the authoritative answer is one tool call away.

MCP: the consultation channel

Agents reach all of this over the Model Context Protocol. A CoreModels deployment serves an MCP endpoint — https://coremodels.example.com/mcp, secured with OAuth — that any MCP-capable client can connect to: Claude, Claude Code, IDE assistants, or your own agent framework. Modern clients handle the OAuth flow automatically; there is no API key to paste into an agent's context.

The read-only tools are the grounding surface. An agent typically starts with list_projects and get_project_summary to orient itself, then uses search_nodes and the schema-discovery tools for specifics. Two integration tools matter most for dbt work: get_vendor_integration_status, which reports which connectors exist and what state the project's last dbt import left behind, and audit_vendor_project, which lets an agent submit a fresh manifest and get back the full coverage, drift and conformance report. For manifests too large to inline, the agent passes URLs and the server fetches them — with strict guards on what it will fetch.

Deliberately, the public endpoint carries only read-only tools. Anything that writes — importing a vendor estate, creating nodes, reconciling two estates — lives on a separate admin endpoint and requires elevated project roles. An agent's OAuth token confers exactly the access its human has: the same role model that governs people governs agents, with no side door.

What an agent can actually do with this

Write against reality. Before generating a model, an agent consults the governed types: real column names, real data types, real references. The join key is whatever the governed reference says it is. The accepted_values test lists the taxonomy's actual values. This is retrieval-grounded code generation, with the schema itself as the retrieval corpus.

Audit before merging. An agent preparing a pull request can compile the manifest and call audit_vendor_project itself — the same read-only audit the CI gate runs. The response is built for machine consumption: an error count that serves as a hard fail signal, findings with stable codes like field-type-drift and contract-not-enforced, each naming its exact subject, alongside a human-readable report the agent can post for its reviewers. An agent that audits before it opens the PR catches its own drift instead of asking humans to.

Regenerate contracts after meaning changes. When a steward updates a governed definition, an agent can call generate_vendor_artifacts to produce the enforced dbt contracts file — per-column data types, not-null and unique tests, accepted values from taxonomies, relationships from references — and open a pull request with the diff. The agent does the mechanical propagation; humans review the meaning, as they should.

Explain the estate. The least glamorous win compounds daily: "what feeds this exposure?", "is this column tested anywhere?", "which models lack enforced contracts?" — answered from governed fact, by an assistant, in seconds.

Honesty is an agent feature too

A subtle point that becomes critical at machine speed: agents act on what tools return, so tools that overstate their knowledge produce agents that overstate theirs. Every surface here is explicit about uncertainty. Imports and audits return a lossiness ledger — an itemized account of anything approximated or dropped — as a first-class part of success, not buried in logs. Type approximations are declared, and the exact native type string is preserved in metadata rather than discarded. Findings carry severities and codes, not vibes. An agent reading these responses can distinguish "the governed model says X" from "the governed model approximated X, and here is what was lost" — which is precisely the distinction that keeps automated reasoning safe.

The era of agents writing analytics code is not coming; it is here, and it runs at the speed of whatever truth source you give it — including none. A governed dbt estate over MCP is how you make the truth cheaper for an agent to fetch than to fabricate. The dbt quickstart in the CoreModels docs covers the import, and connecting your agent is a one-line MCP configuration away.