Snowflake Cortex: How It Works and What It Needs

What is Snowflake Cortex? A quick overview.

Snowflake Cortex is a managed service from Snowflake. First launched in 2023 with a few AI SQL functions and a hosted model catalog, it has since expanded to include vector search, advanced document AI, and agentic reasoning. It integrates with Snowflake’s governance and access control model, inheriting RBAC, masking, and row-level security.

Cortex has many components — AI functions, Search, Analyst, and Agents — and all of them primarily depend on the context needed to answer queries accurately and efficiently. LLM-powered applications like Cortex have moved past prompts. What they now require is context — and understanding what context engineering means in practice is the first step, which comes from many places and in many forms, all of which make up the Snowflake context layer.

What are the key Snowflake Cortex services?

Snowflake’s AI and ML features are split into two broad categories: Snowflake Cortex and Snowflake ML. Snowflake Cortex is built around LLMs and agentic use cases, and can be viewed in two separate groups:

• Cortex AI Services: Include services like Cortex Analyst, Cortex Search, and Cortex Agents that automate multi-step tasks, invoke tools, and use a host of other techniques.
• Cortex AI Functions: Include direct functions for LLM completions, plus AI SQL functions for classification, similarity, document parsing, transcription, summarization, sentiment analysis, and translation.
• Supporting capabilities: Include Cortex Code, a hosted model catalog, Cortex Guard, Cortex Fine-tuning, Cortex AI Observability, and Snowflake’s own MCP server.

All of these services are based on the same foundation within Snowflake that enables hosted LLMs, native Snowflake data, AI governance, and serverless compute.

How does Snowflake Cortex actually work?

Snowflake Cortex is primarily a serverless compute service that runs hosted LLMs like Llama, Mistral, Gemini, Arctic, Claude, and GPT on Snowflake-managed GPUs. All Cortex services run within Snowflake-managed infrastructure, the data remains within Snowflake, and the same access control and governance model applies.

When you invoke Cortex from SQL, Python, or REST, your request goes through the following cycle:

1. Snowflake checks whether you have the correct permissions to use Cortex and access the requested data assets.
2. Access control policies, row-level security, column masking, and object tags are applied to the relevant data assets.
3. Cortex resolves the context from all the metadata available in Semantic Views, Cortex Search services, tools, and agent instructions, along with the actual prompt.
4. The hosted LLM generates the completion, and the response is returned to the caller.

The most important predictor of a good response is the context. While Snowflake captures context at many levels — technical metadata, tags, classifications, and data quality metrics — it is not readily consolidated into a format LLMs can consume. What you really need is all of that consolidated, fully governed, and available for Cortex Search, Agents, and Analyst to use: a context layer for Snowflake Cortex.

What are the key challenges in building a context layer?

The challenges in building a context layer are the same as the challenges in building a metadata layer. Some of these challenges include:

• Siloed and scattered context: Most enterprises have no integration layer that pulls context from data sources, documentation, orchestration tools, and semantic models into a single queryable surface. Cortex agents work with partial, inconsistent information as a result.
• Stale context: Without automated pipelines that detect and propagate changes, ownership updates, metric redefinitions, and governance policy changes never reach the context layer. Stale context is functionally the same as no context.
• Context designed for humans, not agents: Most existing documentation, wikis, and BI metadata was built for human consumption. Snowflake Cortex has an agentic design that supports agent-to-agent communication, which requires machine-readable, API-accessible context.
• Missing or broken metadata: Lineage, governance, quality, ownership, and usage metadata are foundational to any context layer. Gaps in any one of these degrade agent output quality and reliability.

Snowflake alone won’t be able to tackle these challenges. What you need is an enterprise-wide context layer that feeds into Snowflake Cortex.

How Atlan becomes the context layer for Snowflake Cortex

Atlan is built to bring context to the enterprise. It connects with data sources, documentation, orchestration tools, and semantic models across your stack, then consolidates that context into a single layer that Snowflake Cortex can query at runtime. The foundation is a Context Lakehouse pattern: an open, Iceberg-native knowledge architecture designed for machine-speed access.

Here’s what this looks like in practice:

• Enterprise Data Graph: Atlan builds a unified metadata graph from structural metadata, granular lineage, governance decisions, and ownership signals across your entire data estate, giving Cortex agents a single traversable map of your data.
• Semantic View generation: Atlan’s Semantic View generation captures definitions of metrics from external systems like dbt and maps them to Snowflake semantics, so Cortex agents resolve terms like “revenue” or “churn” consistently regardless of where they originate.
• Context Engineering Studio: Context Engineering Studio allows you to design, test, and evaluate context models for specific agent use cases before deploying them to production. This helps prevent AI agent hallucination by validating context before it reaches production.
• Data quality and AI governance: Atlan’s data quality in LLMs and AI governance capabilities bake metadata into the context layer, giving Cortex agents visibility into whether a dataset is trusted, restricted, or flagged for review.
• MCP Server: Many of the aforementioned features are exposed through Atlan’s MCP server, allowing communication with Cortex Agents and other systems prior to inference and at inference time.

With these capabilities in place, Atlan gives Snowflake Cortex what it cannot build for itself: an enterprise-wide context layer that spans the full data stack.

Real stories from real customers building enterprise context layers

"Atlan captures Workday's shared language to be leveraged by AI via its MCP server. As part of Atlan's AI labs, we're co-building the semantic layer that AI needs."

Joe DosSantos, VP Enterprise Data & Analytics

Workday

Workday: Context as Culture

Watch Now

"Atlan is our context operating system to cover every type of context in every system including our operational systems. For the first time we have a single source of truth for context."

Sridher Arumugham, Chief Data Analytics Officer

DigiKey

DigiKey: Context Operating System

Watch Now

Moving forward with a sovereign context layer for Snowflake Cortex

Snowflake’s AI capabilities with Snowflake Cortex are quite advanced, especially with services like Cortex Analyst and Cortex Agents. All of these services need context — and that context needs to be up-to-date, cross-system, and organization-wide for inference to be effective.

Atlan is a platform built to fill this exact gap by providing an enterprise context layer that powers tools like Snowflake Cortex through a host of carefully designed features, including Context Engineering Studio, Semantic Views, Enterprise Data Graph, and Active Ontology.

Book a Demo

FAQs about context layer for Snowflake Cortex

1. What is Snowflake Cortex?

Cortex is a managed service offered by Snowflake — a collection of AI services that give you access to the power of LLMs without leaving the Snowflake infrastructure and security boundaries. Cortex comprises tools like Cortex Analyst, Cortex Agents, and Cortex Search, along with Cortex AI Functions, Cortex Code, and Cortex Guard.

2. Why does Snowflake Cortex need an external context layer?

Snowflake Cortex doesn’t have a built-in mechanism for managing context in complex, real-world, multi-step scenarios that services like Cortex Analyst and Cortex Agents might handle. Moreover, Snowflake doesn’t have the context for all the other systems in the enterprise data ecosystem. The Context Lakehouse in Atlan gathers and makes context available from across the organization to Snowflake Cortex.

3. What is the difference between Snowflake’s Semantic Views and a context layer?

Semantic Views in Snowflake provide a way to standardize the semantic definitions of metrics across multiple tools and systems, such as dbt and BI tools. A full context layer includes much more than the semantic layer — it contains memories, preferences, artifacts, and RAG systems. The context layer is much broader in scope than Semantic Views.

4. What is Context Engineering Studio, and how does it help Cortex Agents?

Context Engineering Studio allows you to optimize context for Cortex Agents by building and evaluating context and inference pipelines. Using Context Engineering Studio, you can create Context Repos, which help you work with data assets and see how specific inferences perform with specific context design. Once the context is deployed, Atlan’s MCP server delivers it to Cortex Agents at runtime.

5. How does the Atlan MCP server work with Snowflake Cortex?

Atlan’s MCP server is a general-purpose MCP that works with all metadata and context within Atlan and interacts with external tools to publish or consume context. Atlan’s MCP server and Snowflake’s official MCP server run side by side — agents query both through the standard protocol, getting Atlan’s enterprise-wide context alongside Snowflake’s native warehouse context in the same workflow.