In the last two weeks, Snowflake, Databricks, and Microsoft all announced AI agent products that depend on the same thing: governed business definitions hosted in a semantic layer. Snowflake’s Project SnowWork runs autonomous workflows on “governed metrics and shared business definitions” inside Cortex. Databricks’ Genie Code uses Unity Catalog as its source of business semantics. Microsoft expanded Fabric IQ to expose its business ontology via Model Context Protocol to any AI agent from any vendor.
The convergence is striking. Three competing platforms, each with different architectures and different market positions, arriving at the same conclusion: agents that operate on raw tables and column names without understanding business meaning will hallucinate and erode any value they are meant to create. The solution is a semantic layer that defines what metrics mean, how entities relate, and what rules apply. The platforms will host it, govern it, and serve it to agents.
The part none of them address is where the definitions come from.
What each platform built
Microsoft’s move is the most architecturally distinct. Fabric IQ introduces an Ontology item: a machine-readable vocabulary of business entities, properties, relationships, and constraints, bound to real data in OneLake. You define that “Customer” means an entity with an active contractual relationship and at least one transaction in the trailing 12 months. You bind that definition to lakehouse tables, Eventhouse streams, or Power BI semantic models. Then any MCP-compliant agent, whether it is Copilot, Claude, a LangChain agent, or something built in-house, can query those definitions. Microsoft is the first major platform to decouple the semantic layer from its own consumption tools. Teams already on Power BI can bootstrap the ontology directly from existing semantic models, which eliminates the cold start.
Snowflake’s approach keeps governance inside Cortex. Project SnowWork promises autonomous multi-step workflows for business users, with pre-built persona-specific profiles for finance, sales, and marketing. The underlying bet is the same: the agent’s quality depends on the definitions in the governed layer. SnowWork does not create those definitions. It consumes them.
Databricks’ Genie Code is an autonomous agent that builds pipelines, debugs failures, and ships dashboards. Its integration with Unity Catalog means it can reference business semantics and governance metadata during execution. Like the other two, it assumes Unity Catalog contains validated, reconciled definitions. The documentation says Genie Code “understands business semantics.” What it understands is whatever you put in Unity Catalog.
All three platforms have built sophisticated infrastructure for hosting, governing, and serving business context. The container is ready. The transport is ready. The contents are not.
The definition lifecycle
Getting a metric definition into a semantic layer that agents can query is a multi-step process. Most organizations have not done it, not because the steps are mysterious, but because each one is labor-intensive and there is no established playbook.
The first challenge is knowing what definitions you have. Somewhere in your organization, one analyst defines “churn” as no activity in 90 days. Another defines it as no purchase in 60 days. Both queries run. Both produce results. Both feed downstream reports. These definitions exist. They are just not declared anywhere central. They live in the work your analysts do every day, distributed across teams and tools, undocumented and unreconciled.
The second challenge is reconciliation. Once you surface the definitions, you have to determine which ones conflict. In a mature analytics organization, it is common to find competing definitions for any core metric. “Revenue” calculated before vs. after returns. “Active customer” based on last login vs. last purchase vs. last contract renewal. The technical work is identifying where definitions diverge. The organizational work is getting stakeholders to agree on which version is canonical. This is the step most organizations skip, not because they do not know it matters, but because it is expensive and politically uncomfortable. It means telling a VP that their team’s number has been wrong.
There’s actually another option, which is to get used to the idea that there are multiple definitions for the same thing and that that’s acceptable. But it hits a similar trap: who decides when to use which definition, and if you feed multiple competing, almost-the-same definitions to an AI, how can your non-technical user be comfortable with what it’s chosen? These are people and behavioral challenges.
The third challenge is publication. Once a definition is agreed upon, it needs to be packaged for the platform that will host it. For Fabric IQ, that means defining an entity type with properties, constraints, and data bindings. For Snowflake, it means populating Cortex semantic definitions. For Databricks, it means registering the definition in Unity Catalog. Each platform has its own format. The definition itself is the same. The packaging differs. Microsoft’s Power BI bootstrap path is well designed here: if you already have semantic models that accurately represent your business, you can import them directly. The key phrase is “accurately represent.”
The fourth challenge is maintenance. A semantic layer that is correct on day one and wrong on day 90 is worse than no semantic layer at all. It creates false confidence. Definitions drift for specific, predictable reasons. A team quietly redefines a metric to include a new signal. An upstream schema change breaks a join pattern. A regulatory change modifies how a calculation must work but the update only reaches some of the teams. Microsoft’s own documentation is explicit: upstream data changes require manual refresh before they are visible in the ontology. Without a mechanism that continuously compares what the semantic layer says against what the business is actually doing, the layer decays into another artifact that exists in parallel to how the organization actually works.
In a big enough organization that’s multiple FTEs to build, gather consensus, code, and maintain. And that’s reasonable. These platforms are betting that their agents can hit a semantic layer in order to produce consistent, trustworthy responses to tens, hundreds, or thousands of questions from employees who may or may not know how to code SQL. If you were going to hire a team of analysts to respond instantly to requests from around the business, you’d invest time, money, and staff to ensure they give consistent answers. Teams need management and governance, so should AI.
The implication is this: if you are investing in text-to-SQL AI and you are not budgeting resources for the construction and maintenance of this semantic layer, you are setting up for trouble.
Where we sit
Extraction, reconciliation, publication, maintenance. Four steps. Each one currently manual, intermittent, and dependent on institutional memory.
We are betting that business logic is best preserved in SQL, and we are building to extract it so it can be used by anyone and any AI. We believe solving this unlocks tremendous value for users of any of the three mentioned platforms. A Snowflake customer whose metric definitions have been found and reconciled can populate Cortex with confidence. A Databricks customer with validated business logic can trust what Genie Code produces. A Fabric customer with a well-maintained ontology can open it via MCP to every agent in the organization and know the answers will be consistent.
Organizations have the knowledge. We’re exposing it to them. Getting teams there 10x faster than doing it manually is what success looks like for us.
What comes next
There is a deeper version of this problem that we will address in a future post. “How do we define revenue?” is the simple case. A single concept, a bounded definition, a clean fit for a semantic layer entry.
But many of the questions that matter most in enterprise analytics are not single concepts. They are chains of dependent definitions that have to be resolved in a specific order before the final answer is even possible. What looks like one question to a business user may require six prerequisite concepts, each with its own extraction and reconciliation, sequenced correctly. That kind of complexity does not fit neatly into a semantic layer the way “revenue” or “churn” might, and it is far more common than most semantic layer strategies account for.
We will dig into that next.