Stop your agent guessing what status means
An LLM writing SQL against your warehouse has three bad options: guess from the column name, read the SQL, or ask a human. Give it a fourth.
Start with this recipe →No warehouse credential. No dbt Cloud token. Read-only.
For agents, no sign-in: /recipe/agent-grounding.json · /recipe/agent-grounding.md
Every text-to-SQL tool and coding agent pointed at your warehouse is inferring meaning from column names and whatever free text happens to be in a description. It cannot know that status has exactly five permitted values, that return_pending is a kind of return rather than a peer of it, that customer_id means the same thing here as cust_id does two models over, or that this column is the one bound to a public term the rest of the industry uses. So it guesses confidently, and a confident wrong answer about meaning is worse than no answer. This workspace makes the governed definitions readable by machines: an agent connects over MCP and can ask what a column means, which values are permitted and what each one is, what the column is bound to externally, and what else carries the same concept — and it gets the governed answer a human curated, not an inference. dbt's own agent surfaces expose dbt's contents; this exposes the meaning behind them.
What you do
- Import the manifest; each accepted_values list becomes a governed vocabulary.
- Fill the three columns agents get wrong, meaningNote, commonMistake, doNotUseFor, on the 20 columns that matter.
- Connect your assistant to the read-only endpoint and replay a question it used to get wrong.
Guides for this recipe
Strategy
Why the problem exists, and what changes once it is fixed.
Engineering
How it works: the import, the API, the MCP tools, the CI loop.