5 minute read
A clinical researcher at a pharmaceutical company asks an internal agent: what is the optimal dosage of the API in the formulation of X, shown in clinical trials from the last five years, to effectively treat symptoms of Y?
In this context, API means active pharmaceutical ingredient, not an application programming interface. Get that wrong and the answer is not slightly off. It is nonsense delivered with confidence.
The business glossary is what closes that gap. Not as a reference document nobody opens, but as a governed source the agent reads at query time. Below is a pattern for cleaning up the glossary you already have using Cortex AI, and then keeping it clean.
Why do AI agents need a business glossary?
We already talk to systems in natural language, and as agents mature they are talking to each other the same way. Fluency takes more than grammar. In a business context, an AI system also has to know the business model, the concepts beneath it, and the words the company actually uses for them.
Break the researcher's question down by the knowledge the system must have:
| Knowledge type | In the researcher's question |
|---|---|
| General | Symptoms, drugs, dosage, treatment of diseases. |
| Domain | Formulation, clinical trials. |
| Proprietary | Drug X, the treatment pathway for disease Y. |
| Acronyms | API as active pharmaceutical ingredient. |
LLMs arrive already trained on the first category. The other three they do not get for free, so enterprises have to train or ground each one explicitly. None of this is top of mind for the business user asking the question, and it should not have to be. They expect the system to know the words they use every day.
What goes wrong with the glossary you already have?
Creating a business glossary is a non-trivial task, and the degree of rigor varies across enterprises: a spreadsheet on a shared drive, an intranet page, or a commercial data governance platform that provides glossary capability.
Creating it is not sufficient. Terminology moves. An acquisition closes and two glossaries collide, each with its own definition of “customer.” A new venture invents vocabulary the rest of the business has not caught up with. A commissioned system arrives carrying concepts and terms nobody agreed to. Maintaining a robust glossary usually means addressing the following:
| Challenge | Typical causes (not exhaustive) |
|---|---|
| Duplicates | Glossaries imported or derived from multiple sources. |
| Semantic similarity | More than one way to describe the same concept. |
| Semantic ambiguity | Incomplete descriptions, or descriptions lacking clarity. |
| Semantic conflict | Contradictory descriptions for the same concept. |
The goals here are semantic consistency and integrity. That means the glossary needs governance and stewardship. It needs to be mastered, exactly like enterprise data. From a solutioning standpoint, the work splits in two: a one-time cleanup to establish a baseline, then a continuous process to protect against semantic drift.
Where Cortex Sense fits
Cortex Sense was announced at Snowflake Summit 2026 and is in private preview, with no general availability date published. Snowflake has also signaled that a dedicated business glossary capability is coming to Horizon Context.
Note what Cortex Sense is for. It assembles context from signals already present in your account, including query history, object metadata, dashboard definitions, and semantic views, then serves the pieces that fit each question. Snowflake has been clear that curated definitions carry the most weight here, and that a semantic view is treated as an authoritative signal. That is the useful part to sit with. Retrieval quality follows from the quality of what there is to retrieve, and deciding which of two contradictory definitions of the same term is correct was never a retrieval problem to begin with.
Which is the argument for doing this work now rather than waiting. The cleaner the glossary when Cortex Sense and the Horizon Context glossary become generally available, the more both can do with it on day one. Establishing a baseline today is groundwork for those capabilities, not a substitute for them.
How do you clean up an existing glossary?
Since terms, their definitions, and acronyms rely heavily on natural language, solving this requires NLP and AI techniques. Figure 1 shows the steps involved in establishing a baseline glossary.
- Ingest into Snowflake. Land the glossary from its native platform in a staging table: term identifier, term, definition, synonym, acronym, domain, business owner, technical owner, source system, and ingestion timestamp. Follow your enterprise standards; this is a minimal set.
- Embed and cluster for duplicates and near-duplicates. Vectors handle nuances of phrasing and allow a degree of fuzzy matching that string comparison cannot. Use AI_EMBED, then VECTOR_COSINE_SIMILARITY with a configurable threshold, so the cutoff can be tuned and used to decide when human intervention is necessary.
- Perform pairwise matching. Generate recommendations such as exact duplicate, synonym, related but distinct, or false positive, including a proposed merged canonical definition where applicable. Using an LLM as a judge to resolve ambiguity is better than pure vector similarity.
- Ground acronyms in your own documents. Build a Cortex Search Service over internal documents so that acronyms and their expansions are grounded in your actual usage, rather than the model's general knowledge or the glossary in isolation.
- Put a steward in the loop. Surface every flagged cluster and acronym for a steward to accept, reject, override, or edit. Skip this step and you lose the institutional knowledge that is written down nowhere else.
Keeping the glossary from drifting again
The maintenance pipeline runs continuously so that integrity is maintained over time. All activity should be versioned so that an inadvertent error can be rolled back.
- Trigger on change. Whenever a term is added or modified, use a Stream on a staging table, or a scheduled Task if the glossary tool only provides periodic updates.
- Apply the same sequence. Embed, compare, then use an LLM as judge, exactly as in the cleanup pipeline but on one record rather than the whole corpus.
- Route on the threshold. The same configurable threshold determines whether a steward needs to intervene, or whether the change can be automatically accepted and published.
Embedding should also be performed periodically as a housekeeping task, say once every few months, to ensure nothing falls through the cracks during ongoing glossary operations.
Once a clean baseline and a robust maintenance process are in place, the glossary is available to create Semantic Views, which can itself be automated. Those views are what users and applications use to converse with the system in natural language.
What this approach does not solve
Two limits are worth stating plainly.
The bigger picture. As conversational and agentic systems proliferate, the business glossary is only one part of the picture. Knowledge graphs complement the glossary with relationships and context. A data catalog provides the inventory of data assets in the enterprise and the systems in which they reside. Glossary, graph, and catalog together are what a semantic layer needs. Alone, the glossary buys you a shared vocabulary and nothing past it. That is a start, not a semantic layer.
Organizational commitment. Glossary programs tend to die quietly. They get funded as a documentation exercise, the steward role becomes somebody's ten percent, and a year later the spreadsheet is stale again. The glossary is no longer a reference artifact. It is foundational infrastructure for an agentic enterprise, and it has to be resourced as one.
The glossary is at the heart of the agentic enterprise
If the Snowflake instance contains all enterprise data, housing the glossary within or near it makes a lot of sense. The terms sit beside the data they describe, under the same governance, readable by the same agents.
Agents will talk to your data, to your applications, and to each other. Every one of those exchanges runs on your vocabulary. If two systems disagree on what an active customer is, you will find out in a board deck. Start with the glossary you already have. Clean it once, then keep it clean.