This blog post is AI-Assisted Content: Written by humans with a helping hand.
An AI agent connected to Snowflake will answer almost any question put to it. Whether that answer is grounded in something real, or in whatever data the agent could reach with the least friction, is a separate question, and for most organizations today it hasn’t been asked. Some call this a context layer problem, others a semantic layer problem. The boundary between the two isn’t clearly defined across the industry, but what matters is the underlying gap, not the label attached to it.
A Wire Built for Lightbulbs, Asked to Run a Factory
Think of how infrastructure typically evolves: A system is designed and validated for one specific purpose, and its safety and governance practices are calibrated accordingly. Thomas Edison’s Pearl Street Station, switched on in 1882, is a useful reference point here. It was the first commercial power plant, built for exactly one purpose: Replacing gas lighting. Within roughly fifteen years, the same electrical infrastructure was expected to power elevators, streetcars and factory motors, uses it was never designed or governed for. The lighting-era safety practices no longer matched the risk profile of the system, and it took a unified electrical code, published in 1897, to close that gap.
Snowflake is going through a comparable transition, on a much shorter timeline. It was designed, sold and governed as a data warehouse: A system for storing and querying data, with RBAC and masking calibrated to the risk of a report reaching the wrong person. Cortex Agents, CoWork, CoCo and App Runtime extend that same platform into something that takes action: Writing, triggering, deploying. In most organizations, the governance model hasn’t been recalibrated to match.
What a Context Layer Actually Is, and Why Agents Fail Without One
A context layer is the layer of a data platform that attaches meaning to a value: What it represents, where it originated, how current it is and whether it can be trusted at the point of use. This is a different job than a data catalog does, which documents structure, not trustworthiness.
Consider what happens without one. An agent tasked with drafting a renewal email retrieves a customer’s record: Contract status active, no flags. It generates a confident, positive email. What the agent cannot determine is that the record synced from the CRM eighteen hours earlier, before a service outage generated three support tickets. The underlying data was accurate at the time it was captured. Nothing attached to the record indicated that it might now be outdated, or where to check.
A person performing the same task usually has a mitigating habit built in: Checking a record that looks unusually quiet before sending, hearing about the outage from a colleague, cross-referencing a second system. An agent producing a single, confident output has no equivalent check. This is the actual risk agents introduce, not a higher error rate, but the fact that an incorrect output and a correct one become indistinguishable.
The Most Common Gap: External System Metadata Isn’t Flowing Into Snowflake
Synchronizing data from ERPs, CRMs and other operational systems into Snowflake is a solved technical problem. What doesn’t transfer along with that data is the metadata that defined its meaning in the system it came from.
This gap tends to appear in two recurring patterns we see constantly:
- Data synchronizes at the schema level. The business meaning behind it usually doesn’t. Modern connectors replicate table and column structure reliably, a CRM like Salesforce or an ERP running on a system like Azure SQL lands in Snowflake with its tables, columns and data types intact. What doesn’t come along is the business-semantic layer sitting on top of that structure: Field ownership, why a value is calculated the way it is, which records get manually overridden and by whom. Salesforce’s own field descriptions and validation rules, for instance, aren’t part of what a standard sync replicates. An agent querying the synchronized table sees populated columns. It has no way to know what any of those values are actually supposed to represent.
- BI logic was never stored in the warehouse to begin with. A large share of metric definitions exist exclusively inside BI tools, a Tableau calculated field or a Power BI model, encoding a business rule that someone translated into a formula years ago and never documented anywhere else. The warehouse holds the raw values. The BI tool holds the definition. An agent querying the warehouse directly only ever gets the former.
Both patterns produce the same outcome: The data is present, the definition behind it isn’t, and an agent has no mechanism for distinguishing a value it can trust from one it’s inferring.
What a Horizon Context Implementation Actually Involves
Horizon Context is Snowflake’s own implementation of the context layer described above: The native feature set for attaching metadata, lineage and business definitions to data directly inside the platform, rather than maintaining that layer in a separate tool. Closing this gap is mostly a build, not a purchase.
Four components do most of the work, and each one matters specifically because of what an agent doesn’t do that a person does without thinking about it:
- Metadata connectors. When a person can’t locate a definition, they usually ask a colleague, and an incorrect assumption gets caught before it propagates. When an agent can’t locate a definition, it generates one implicitly and presents it as fact. Metadata connectors pull schema, ownership and freshness signals in from the source system, wherever it is, giving the agent a reference point instead of a gap to fill.
- Lineage, calculated to the column level where it’s worth the effort. A person modifying a shared definition usually knows, or asks, who depends on it downstream. An agent has no equivalent mechanism, and neither does the person modifying a field. Column-level lineage turns “is this change safe” from a question answered after the fact into one answered before deployment.
- AI-generated documentation, reviewed before it’s trusted. Horizon Context can generate table and column descriptions from schema and usage patterns, which closes a large documentation gap quickly. It also introduces a specific risk: An incorrect, AI-generated definition, unreviewed by anyone who’d actually know it’s wrong, can be treated as ground truth by the next AI system that reads it. Every AI-generated definition should be routed through the data owner before it’s published.
- BI tool integration into the same context layer. When two people get conflicting numbers from two different tools, the discrepancy usually gets noticed and escalated. When two agents, or one agent queried twice, produce conflicting numbers, there’s no equivalent flag. Integrating Tableau and Power BI’s calculated fields into the same context layer, or at minimum documenting the mapping between the two, is what prevents that divergence from going undetected.
How to Know If You’re Ready
A short self-check, worth running honestly before an agent goes anywhere near production:
- Can you trace a KPI a business user sees on a dashboard back to its source tables and transformation logic, without asking someone who “just knows”?
- Is there a documented owner for each of your top metrics, or does the real definition live in a Slack thread or a calculated field someone wrote three years ago?
- Do you know which of your data lives outside Snowflake, and how stale it gets between syncs?
- If you renamed or dropped a column tomorrow, could you say with confidence everything downstream that breaks?
- Has your team ever gotten two different numbers for the same metric out of two different tools, and did anyone find out why?
- Would an AI-generated definition of your ten most-used metrics survive a review by the person who actually owns that data?
If more than one or two of these make you pause, that’s not a failure. It’s simply where most Snowflake environments actually are right now. The point of asking is to know it before an agent finds out for you.
Where This Goes Next
A Context Readiness Assessment is being developed specifically to evaluate the six questions above, and the gaps behind them, within your own environment rather than in the abstract. If you want to know where you actually stand, that’s the place to start.
Resolving the metadata gap doesn’t complete the process on its own. It’s a prerequisite for the harder work that follows: Making sure every person and every agent operates from a consistent definition of what the underlying context represents. Whether that follow-on work gets labeled semantic layer work, context layer work or something else entirely is secondary to solving it. What’s outlined here is the foundational piece. The rest doesn’t hold up without it.
