A year ago, I wrote about getting a BigQuery warehouse ready for AI ( Easy ways to prepare your BigQuery warehouse for AI) , but didn't look properly into Knowledge Catalog (known as Dataplex at the time). We decided to go back and look through Google's Knowledge Catalog properly: what's actually in there, how it works and what it relates to.
What Knowledge Catalog is
Knowledge Catalog is Google's metadata layer for BigQuery data (and a few other sources). It sits alongside your tables rather than inside them, holding things like glossary definitions, AI-generated table descriptions and data quality results, separate from the tables themselves. You can browse it directly in the Google Cloud console, and an AI agent can reach it too, in the ways this post gets into.
It matters for AI accuracy because an agent answering a question about your data draws on more than the tables alone. What it can see, and how much it can be trusted, depends on what's been set up in Knowledge Catalog as well as in BigQuery itself.
The glossary turned out to be the only content in Knowledge Catalog you actually write yourself. Two other things feed an agent too, but as automatic by-products rather than anything authored, more on that further down. The glossary's also, by Google's own ranking, third on the list of what actually makes an agent accurate.
The order Google puts them in
- Table and column descriptions. These live in BigQuery, not in the catalog. You can also clearly define these descriptions in Dataform. This is the single biggest lever, and it isn't a Knowledge Catalog job at all.
- Verified queries. A known question paired with known SQL, run deterministically whenever a prompt matches it. You author these in the agent itself.
- Glossaries. Vocabulary, so the model can work out what the words in a question actually mean.
- Agent instructions. Plain language rules and defaults for how that specific agent should behave.
Setting up a business glossary on its own won't make an AI agent accurate. The honest version is: descriptions on your tables first, deterministic SQL for the questions you already know people will ask, then vocabulary for the words your team actually uses.
Two things that feed an agent as a by-product
Two sections of Knowledge Catalog I'd otherwise have parked turn out to feed an agent as a side effect, without anyone setting them up for that purpose.
A profile scan is a job you run in Knowledge Catalog, on a schedule or on demand, that reads a table's actual values and works out statistics: common values, null counts, distinct values and how the data's spread out. Those results feed the model directly, and it's also how an agent learns that a status column only ever holds four values, one of them misspelt.
Data insights has Gemini read a table and write descriptions, sample queries and a relationship graph.
Data insights has one trap worth flagging before anyone relies on it. Generating a description doesn't put it on the table by itself, with either generate button. That step happens on the same Insights tab: click "View column descriptions" under the generated table description, then "Save to details" for the table and "Save to schema" for each column. Those two buttons are the ones that matter for AI, because they write into the actual BigQuery table and column metadata, the field every route into that data reads, Gemini in BigQuery included.
"Generate and publish" does something else. It writes the same generated text into Knowledge Catalog instead, alongside the sample queries and relationship graph, none of which have anywhere to live in BigQuery at all. An agent arriving through Knowledge Catalog's own MCP server (Model Context Protocol, covered later in this post) can see all of that. Gemini in BigQuery and an AI on a plain BigQuery connection can't, since neither one ever queries Knowledge Catalog directly.
Worth remembering too: an AI-written description is a first draft, not a finished one. A confidently wrong column description does more damage than a blank one, because the agent reading it has no way to doubt it.
Meaning gets defined in three different places
| Place | What you define there | Scope |
| BigQuery | Table and column descriptions, the views themselves | Everyone, everywhere |
| Knowledge Catalog | Glossary terms, published insights, profile and quality results | Org-wide, served to agents |
| The data agent | Knowledge sources, per-agent descriptions, verified queries, instructions | That agent only |
The real gap in a BigQuery-only setup is that nowhere in BigQuery or Knowledge Catalog can you say "revenue means this calculation" and have it enforced. A glossary term for revenue still just says what the word means. It has no field for which table, which column, or whether to sum or average it, so an AI reading it still has to work out the actual SQL itself, every time. A verified query is different: it's the real SQL, already written and checked, run exactly as-is whenever a prompt matches that question. That's why Google ranks verified queries above glossaries. They only cover the specific questions someone thought to write one for though, not every way a person might ask about revenue.
The layer missing from most diagrams
There's a fourth place that never makes it onto a diagram like the one above, and it's usually the easiest one to fix: a well built view.
A view is just a saved query that BigQuery treats like a table. Build one that already joins the right tables, filters out the rows nobody wants and makes it clear what one row actually means, and you've done a lot of an AI's work for it before it even asks a question. It doesn't have to guess which tables join together or which rows to leave out. It just queries the view and inherits all of that.
Without a well built view, an AI has to work all of that out itself, from raw tables and whatever descriptions happen to exist, and that's where mistakes creep in. Nobody thinks of good view design as an AI readiness task. It's just normal data modelling. But it's quietly doing the same job as a glossary or a verified query.
Business context is three different requests
"Describe what our business does, our aims and our KPIs" is three separate requests. They belong in three different places.
What the business does is mostly wasted on a data agent. Telling it "we're a marketing analytics agency" doesn't help it answer "what was our revenue last month" any better. KPIs aren't context at all, they're definitions in disguise: "monthly revenue" needs an actual calculation attached to it (which table, which column, summed or averaged over what period), so it belongs in the glossary and in verified queries. What you're actually interested in is a preference rather than a fact: the tone an agent should use, or which caveats it should always add. That belongs in agent instructions, where duplication isn't really a problem, because a finance agent and a marketing agent should differ from each other anyway.
Underneath that sits a genuine trade-off. Anything in agent instructions is in the prompt every single time, guaranteed, but duplicated across every agent you set up. Anything in Knowledge Catalog is retrieved only when an agent pulls context for a specific data asset, and the catalog is organised around tables rather than around your company, so a mission statement placed there has nothing to attach to and may never come back. You're trading a guarantee for reuse.
The fix is to attach shared context to the data it's actually about, and that only works well if the warehouse itself is organised for it. Clearly scoped, clearly named datasets, rather than one dataset holding everything, are what make a dataset description worth writing in the first place. A dataset description that says what the data is for and what not to do with it is org-wide, travels with the data through every connection and gets pulled whenever an agent touches anything in that dataset. It's the most underused field in the whole setup.
What a glossary can't hold
A glossary term is a dictionary entry. It has no field for how a metric is calculated, what one row means, which tables join on what key, whether to sum or average or which rows to always exclude, and those five things are exactly what make an answer right or wrong.
Google's own answer to that gap lives in two places, and neither of them is the catalog itself. One is attaching a document straight to a single agent's own context, the "knowledge sources" row in the table above, simple to set up but scoped to that one agent only. The other is the Open Knowledge Format (OKF), announced on 12 June 2026: a folder of markdown files, each with a small block of structured information at the top, meant to be kept wherever you already keep files, a Git repo included, with no runtime and no vendor lock-in.
OKF doesn't reach Knowledge Catalog by itself though. Something has to push it there. Google's own reference tooling reads the markdown files from wherever they're kept and writes each one into Knowledge Catalog as an entry, with the file's content landing in the same free-text field a person could otherwise type a description into by hand. Whatever that structured block specifies beyond that, whether it's verified, when it goes stale, where its numbers come from, gets stored alongside it as its own structured record.
That's the actual trade-off. A document attached to one agent needs no extra step and works the moment you set it up. An OKF bundle needs someone to run that push, whether by hand or on a schedule, but once it has, the content is searchable across the whole catalog rather than sitting inside a single agent's configuration.
Two routes an AI can take to reach all of this
Which of the above an AI actually sees depends on where that AI sits.
Inside Google's own conversational analytics or a BigQuery data agent, all four layers, descriptions, verified queries, glossaries and instructions, are things you set up directly inside that product, inside the GCP console.
Outside GCP, Claude included, there are two separate connections worth knowing about, because each one sees a different half of the picture.
A BigQuery connection gives an external AI the tables, plus whatever metadata BigQuery itself holds: table and column descriptions, dataset and table labels in full and the SQL behind every view. That last one is a genuinely free win. Because a view's definition travels with the connection, an AI reading a view sees the business logic behind it whether or not anyone ever wrote a description for it. What doesn't come through a BigQuery connection: glossary terms, any profile and quality result, and aspects, structured metadata records such as an overview or a data quality summary, which Knowledge Catalog attaches to a table or column but BigQuery itself has no field to store.
Knowledge Catalog also has its own remote MCP server, and it's now generally available. Google's own documentation names Claude as a supported client, alongside Gemini CLI, ChatGPT and custom applications, and recommends giving an agent its own identity so its access can be controlled and audited separately from a person's.
That server gives an agent, not a person, two tools to call while it's working out an answer. search_entries finds the relevant tables or columns for a question. lookup_context is the one that matters more, called on whatever search_entries found: give it up to ten resources and it returns a single formatted block covering the full schema with field descriptions, null ratios, distinct counts and sample values, data quality status, which fields people actually read, filter and sort on, detected joins between tables and sample SQL queries. That's a richer payload than a BigQuery connection gives at any price: the profiling stats, the detected joins and the real usage patterns aren't things BigQuery alone holds, and it makes the case for running profile scans concrete, because that call gets better every time you run one.
Search results also include those attached aspects, invisible in BigQuery, Dataform and Looker Studio, but not invisible to an agent coming in this way.
One thing I couldn't confirm after three attempts: whether glossary terms reach an agent through this route at all. They're not in Google's documented list of what lookup_context returns, and search_entries doesn't document glossary terms as a searchable entry type. It may well work and simply be undocumented.
Where I'd actually start
Descriptions on your tables first, because that's the one lever every route into your data uses, whether it's a Google agent, a BigQuery connection or the catalog's own MCP server. Verified queries next, for the handful of questions you already know people will ask. Data insights can give you a head start there: treat its generated sample queries as a first draft, not a finished one, and have someone with SQL knowledge check each one before it becomes a verified query, correcting anything that isn't pulling the right thing. A glossary after that, scoped to the terms your team genuinely disagrees on, plus the ones your team agrees on but the data never states, such as which system holds an hour and what column it's actually called. And lastly get your datasets organised and descriptions for them updated.
Then decide, on purpose, whether you want AI reaching your data through Google's own agents, through a BigQuery connection, through Knowledge Catalog's MCP server or some mix of the three. Each one sees a different slice of what you've written down, so it's worth knowing which slice you're relying on before you tell a client their data is AI-ready.
If you'd like to find out a bit more about the knowledge catalog then check out my other post detailing all the section What's actually in Google's Knowledge Catalog
