---
title: "Give your agent the governed meaning of status"
slug: "agent-grounding"
type: recipe
locale: en-US
canonical: "https://www.coremodels.io/recipe/dbt/agent-grounding"
updatedAt: "2026-09-28T17:17:50+02:00"
---

# Give your agent the governed meaning of `status`

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.

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

1. Import the manifest; each accepted_values list becomes a governed vocabulary.
2. Fill the three columns agents get wrong — meaningNote, commonMistake, doNotUseFor — on the 20 columns that matter.
3. Connect your assistant to the read-only endpoint and replay a question it used to get wrong.

## Articles

- [The Fourth Option for a Column Named status](https://www.coremodels.io/connector/dbt/h5-agents)
- [Grounding an Agent in Your dbt Project: What It Reads, and What Changes](https://www.coremodels.io/connector/dbt/t6-agent-grounding)