Third and final installment in this three-part series. In previous publications, we analyzed the limitations of data when it lacks context and the role played by elements such as the semantic model, ontology, data catalog, and the standards that underpin them.
In this last post we addressed how these capabilities enhance the value of AI copilots and agents, as well as the actions an organization can take to build a solid foundation that allows it to harness their full potential.
The factor that determines the real value of copilots and agents
Copilots and agents are only as good as the context they have access to. A copilot without context functions like a highly skilled consultant who must work without access to the organization's systems, processes, and internal knowledge: they can analyze and propose solutions, but they don't know which sources are official, which policies apply, or what exceptions should be considered. A copilot with context is more like someone who has received training, controlled access, and established operating procedures.
The difference is noticeable in four capabilities: understanding the question (mapping expressions like "good customers" or "high risk" to approved concepts), choosing appropriate sources, applying rules (respecting formulas, filters, and permissions), and explaining the result, not just providing it. This shifts the conversation from "what model do we use" to "what context do we give it and how do we govern it?" Without that context, the risk isn't that the AI won't answer; it's that it will answer the wrong question too well.
The first wave of conversational analytics focused on text-to-SQL: the user asks a question, and the system generates a query. This is valuable, but limited when used alone, because a contract of meaning (semantic models, ontologies, catalogs, and rules) must exist between natural language and SQL to prevent a syntactically correct query from responding to a misinterpretation. Furthermore, agents go beyond simply asking a question: they plan steps, request clarification when a question is ambiguous, and should choose the certified metric when multiple versions exist. The success metric shouldn't be just "the agent responded," but rather its accuracy, consistency with definitions, and source traceability.
Here another relevant concept emerges: MCP (Model Context Protocol), an open protocol that standardizes how AI applications connect to external systems. Its own documentation compares it to a USB-C port for AI applications. MCP resolves how to connect agents and tools in a standardized way, but connecting is not the same as understanding: an MCP server can expose a database or an API, and if what it exposes lacks semantic context, the agent will have access but not necessarily the necessary judgment. The powerful combination is MCP plus governed semantics: MCP as a technical interface, and the semantic model, ontology, and catalog telling the agent which metrics are official, what relationships exist, and which sources are certified.
Why does context change the usefulness of copilots and agents?
Without semantics, the agent improvises; with context, it operates with a contract of meaning, permissions, and validations.
From strategy to practice: building context with purpose
The difficult question isn't whether semantic context is desirable, but how to get started without creating an endless program. Two temptations must be resisted: modeling the entire enterprise before delivering value (which ends up in a fancy but underutilized repository), or addressing each use case in isolation (which delivers quickly but accumulates semantic debt). The sound approach combines business, architecture, and operations in four steps.
- Choose a domain with impact and ambiguity. Not the easiest one, but one where ambiguity generates real costs: customer, sales, risk, product. "Customer" is often a good starting point because it crosses many areas that, even using the same word, don't always mean the same thing. The deliverable of this step is not a complete ontology, but a prioritized semantic backlog: concepts, metrics, and critical rules, with assigned responsibilities and use cases.
- Transform metrics into semantic products. A critical metric is not just a formula: it's an asset with a name, definition, owner, version, granularity, calculation rules, and use cases. You can start with a minimal data sheet and then migrate it to the appropriate technology—a Semantic View in Snowflake, a Metric View in Databricks, a semantic model in Power BI—preventing the same metric from being defined, without governance, in multiple places simultaneously.
- Validate with SHACL, govern with a catalog, and deploy with a platform. Semantic validation means creating proofs about meaning: if an "active contract" should have a start date, a valid status, and an associated client, that can be verified. The catalog orchestrates which assets are official and which consumers depend on each one, and the entire set, models, ontologies, rules,should be treated as code: versioned, tested, and promoted across environments, just like any critical pipeline.
- Measure improvement in decision-making, not just in consultations. If the program is evaluated by the number of terms in the glossary, it incentivizes volume, not usefulness. It's advisable to measure things like reconciliation time between departments, the percentage of agent questions answered with certified sources, or the reduction of incidents due to interpretation, and close the loop: every agent error due to an unfamiliar synonym or an unformalized rule should feed back into the semantic model.
A reference architecture: roles and most frequent errors
All this capacity can be organized into six layers: sources (transactional systems, lakehouses, APIs), integration and preparation (ingestion, technical quality), the meaning layer (semantic models, ontologies, rules, and shapes), governance (catalog, lineage, permissions, certification), consumption interfaces (BI, copilots, agents), and evaluation (testing, benchmarks, impact metrics). The key is that these layers are not isolated compartments: the agent consumes semantic models and the catalog, validations feed into trust indicators, and user questions generate improvements in the definitions.
This capability cannot be developed or maintained autonomously; it requires a governance model with clearly defined responsibilities. This model involves the business owner responsible for each concept or metric, the Data Product Owner, the architecture, data governance, and security teams, as well as the AI teams, who use this context to build solutions and provide continuous feedback for their improvement and evolution. The semantic translator, data steward, analytics engineer, and ontologist are also increasingly relevant, converting business language into formal structures without losing nuance. Many semantic discussions are, at their core, power struggles ("who defines the customer?"), and technology doesn't resolve them on its own; it simply makes them visible.
The most frequent mistakes when building this capability are: confusing documentation with operational context (if the definition is not used in queries or agents, its impact is limited); starting too big, with a total corporate ontology instead of progressing by domains; delegating everything to the tool, when the platform implements but it is the organization that agrees what margin or customer means; forgetting exceptions; not versioning definitions; measuring adoption by the number of terms instead of by real friction reduction; and exposing agents with broad access before having clear limits, permissions, and traceability.
Context as a competitive advantage
Companies that truly want to leverage AI cannot simply accumulate data and connect models. They need to build context: so that people share a common language, so that metrics don't contradict each other, so that agents don't improvise rules, and so that government acts as a safeguard rather than a hindrance.
Roadmap for a real organization
An incremental approach avoids the “semantic big bang” and connects architecture with business outcomes.
Semantic models, ontologies, and catalogs are not isolated fads, but rather complementary pieces of the same puzzle: making meaning explicit. Standards like OWL, OWL 2 RL, SWRL, and SHACL provide ways to represent knowledge, inferences, and validations, and vendors like Snowflake, Databricks, and Microsoft are bringing this conversation into their products because the market has already understood that enterprise AI needs more than just prompts.
The good news is that you don't have to solve everything at once. You can start with a domain, some critical metrics, and a specific consumer experience, and gradually transform tribal knowledge into governed definitions, step by step, until the context ceases to be an abstract idea and becomes architecture. More data can feed more reports. More context can feed better decisions. That's the difference.
