Cortex Sense reference (Private Preview)¶

This topic is the full reference for Cortex Sense. To build your first context, see Get started with Cortex Sense.

The sections in this topic:

• How Cortex Sense works
• Where you can use Cortex Sense
• What Cortex Sense can ingest
• Best practices
• Improving Cortex Sense
• Keeping context fresh
• Access control and RBAC
• Costs
• Region and cloud availability
• Private preview program
• Turning off the feature

How Cortex Sense works¶

Cortex Sense is a grounded context runtime for unmodeled data. It reads the signals your business already produces — such as query history, semantic views, dbt models, dashboards, table metadata, tags, and everything in Horizon Context — and assembles them into a working model of your business that Cortex Agents use to answer questions accurately.

Cortex Sense ingests only metadata and usage patterns, not your actual data rows. It complements semantic views: semantic views remain the highest-precision path for domains you curate, while Cortex Sense covers the rest — the long tail of tables no one has modeled and questions that span domains. When a semantic view exists, the agent uses it. When one doesn’t, Cortex Sense fills the gap. Context lookups only occur when explicitly invoked — standard SQL queries and dashboards run unchanged.

Where you can use Cortex Sense¶

You can use Cortex Sense context in two places:

CoCo : A serving skill is how you query a context in CoCo. Generate one from the Activate tab of the /sense page, then distribute it. Everyone who installs it also needs USAGE on the context object; see Access control and RBAC.

Cortex Agents : Agents answer using the same context. This includes CoWork, which runs on Cortex Agents. Ask the cortex-sense skill to create an agent for a context, or to add a context to an agent you already have. In CoCo CLI 1.1.94 and later you can also do this from the Activate tab of the /sense page; see Step 4.

The context is the same in both places. To use it outside of Snowflake, Snowflake recommends the Cortex Agents MCP.

What Cortex Sense can ingest¶

The metadata Cortex Sense reads includes table definitions, query shapes, and documentation.

Preferred connectors¶

These are the sources Snowflake has dedicated connectors and parsing logic for. Connecting them gives Cortex Sense its richest, most reliable context:

Streamlit apps : Source files are read to learn how your dashboards query the data — the tables, filters, and joins behind each view.

dbt projects : Crawled for grain, primary keys, lineage, and transformation logic.

Knowledge base files on a stage : Parsed as articles or documents. Text and Markdown are supported today, and PDF, Word, Excel, and PowerPoint are coming soon. If you’re interested in support for other formats, contact your account team.

BI tools through Horizon Context : Cortex Sense reads semantic models, dashboards, and lineage from Power BI, Tableau, and Sigma. This helps agents understand how your team queries data and what business logic is embedded in your BI layer.

Non-Snowflake connectors¶

Cortex Sense can ingest schema metadata from external data warehouses through Horizon Context, including:

• Amazon Redshift
• Databricks (Unity Catalog)
• Google BigQuery
• Oracle
• PostgreSQL
• MySQL

For these sources, Cortex Sense pulls table schemas, column definitions, and data types, so agents know what data exists and how it’s structured, and can query external warehouses when needed.

Snowflake sources¶

Cortex Sense also automatically parses the signals already in your account, each with source-specific logic:

Semantic views : Read directly and treated as authoritative definitions.

Query history : Mined from real dashboard executions to learn common query patterns. Query text and metadata are retained within the Cortex Sense context until you delete Cortex Sense objects.

Table and column signals : Capture how objects are used and which ones matter most.

Business Ontology : Ontology domains relevant to your use case, with their registered sources, approved terms, and relationships. Business Ontology is integrated with Cortex Sense.

Other sources¶

For everything else, anything you can represent as text — Markdown or plain text — is useful, even if there’s no dedicated connector for it yet.

Best practices¶

Cortex Sense is only as good as the context it can ingest. That context doesn’t have to be your gold layer — it can mine noisy query history — but the higher the quality, the better it responds without manual tuning.

Snowflake recommends indexing context that covers both how to query your data (BI tools) and how your business operates (documentation, wikis). What you choose to include is one of your biggest levers on quality.

To benchmark against custom context solutions, compare time to build, table coverage, accuracy on eval questions, and ongoing maintenance effort.

Improving Cortex Sense¶

The first build is a baseline. Because the context is mined automatically, it can be confidently wrong in places, so you improve it over time in two ways: by answering its questions, and by giving it evals to measure itself against.

Addressing questions¶

Corrections collect in an inbox, where you approve or reject each one. Approved records are indexed by the next build. Review them on the Inbox tab of the /sense page; see Step 4. Once you settle a definition, it holds for future questions.

Creating evals¶

To make improvement measurable instead of anecdotal, give Cortex Sense a set of questions with known-good answers. It runs against them and uses each mismatch to correct itself:

> $cortex-sense run Cortex Sense evals

Ran 20 questions · 16 passed · 4 failed

 ✗ "top accounts by ARR this quarter"
   used calendar quarter; sales uses fiscal
 ✗ "pipeline excluding omitted deals"
   didn't apply the omitted-status filter
 + 2 more

Want me to fix these? I'll update the context and re-run.

> yes

Eval questions come from three places:

• Gold-standard benchmarks you provide
• Feedback from users as they work with the context
• Cortex Sense’s own suggestions for areas where its coverage is thin

Running evals regularly is the most reliable way to raise accuracy and catch regressions as your data changes.

Keeping context fresh¶

Cortex Sense is live context, not a one-time export. Your tables, dashboards, dbt models, and query patterns change constantly, and the context is designed to track those changes so agents keep answering against how your business works today rather than how it worked the day you built it.

To do that, Snowflake plans to refresh your context on a regular schedule. Refresh will run as a Snowflake-managed background task: it will re-read the sources in your scope, pick up new and changed objects, retire ones that have gone away, and preserve the corrections and definitions you’ve already confirmed. You won’t need to rebuild a domain to stay current.

Access control and RBAC¶

Cortex Sense builds on Snowflake’s existing RBAC, so there’s no new permission system to learn. What a role needs depends on what it’s doing: building a context requires the SNOWFLAKE.CORTEX_SENSE_BUILDER database role, while querying one requires only USAGE on the context object. Access to the underlying data is enforced separately.

Building a context¶

To build a context, a role needs the SNOWFLAKE.CORTEX_SENSE_BUILDER database role. ACCOUNTADMIN grants it:

GRANT DATABASE ROLE SNOWFLAKE.CORTEX_SENSE_BUILDER TO ROLE <role>;

This grant is enforced at the Snowflake service level, so only ACCOUNTADMIN can manage it. Grant it to a specific service account role to restrict usage to a single application.

The role that builds a context becomes its owner.

Querying a context¶

To query a context, a role needs one thing: USAGE on the context object. It does not need the SNOWFLAKE.CORTEX_SENSE_BUILDER database role — that’s only required to build one.

Each context is its own object, of type CORTEX SENSE, stored in the database and schema the builder supplied. A context built for a sales domain is named <database>.<schema>."sales". Quote the context name as shown. Context names are stored in the case they were created in, and without quotes the parser upper-cases them, so an unquoted sales resolves to SALES and fails.

A new context has just one grant on it: OWNERSHIP for the role that built it. Every other role needs USAGE before it can query. To grant it:

GRANT USAGE ON CORTEX SENSE <database>.<schema>."sales" TO ROLE <role>;

To see who has access:

SHOW GRANTS ON CORTEX SENSE <database>.<schema>."sales";

The output reports granted_on as CORTEX_CONTEXT. That’s the same object type: CORTEX SENSE is the keyword you write in SQL, and CORTEX_CONTEXT is how it’s reported back.

Only the owning role, or a role with ACCOUNTADMIN or SECURITYADMIN, can issue this grant. Ownership itself can be transferred with GRANT OWNERSHIP ON CORTEX SENSE, which is worth doing if a context was built under a role you don’t intend to keep. One grant covers everywhere the context is used, so it applies to both CoCo and Cortex Agents.

One context per role¶

Access to the data¶

Access to the data is enforced separately, at query time, by normal table-level RBAC. When an agent generates SQL, it runs under the user’s own role. Context access does not grant data access: a user may see that a table exists and how it’s structured, but if their role can’t read it, the query still fails.

Cortex Sense also holds only metadata and usage patterns, never data rows, so no row-level data is exposed through the context itself.

The Cortex Sense schema¶

On first setup, CoCo asks which database and schema to create the context in, and creates the schema if it doesn’t already exist. There is no default location. The schema is owned by the role you used at setup time, and that role owns each context built into it. Granting access to the schema doesn’t grant access to the contexts inside it, which are granted individually as described above.

Costs¶

Cortex Sense costs come from three sources: the initial build, scheduled refreshes, and added input tokens at query time. The initial build is usually the largest cost and scales with scope: the more tables, metadata, and query history you include, the more it costs. In early previews, most customers spent fewer than 1,000 credits on the initial build, and small demo setups cost much less. These figures aren’t a guarantee, so if cost is a concern, start with a small scope and expand from there. Refreshes pick up upstream changes on a cadence the builder sets (weekly by default). They’re incremental rather than full rebuilds, so they typically cost much less than the initial build. Builds and refreshes are billed at the same rates as AI_COMPLETE, with no markup. Starting in public preview, these costs will appear as a separate Cortex Sense line item in your usage history.

When Cortex Agents or CoCo use a context, their usage is billed as usual. The added context can increase input tokens per request, but in practice it more than pays for itself through higher-quality answers and shorter sessions: agents and CoCo tend to reach the correct answer faster, with fewer follow-ups.

Cost monitoring¶

Builds and refreshes run as Snowflake-managed background tasks, and their credit consumption appears in CORTEX_AI_FUNCTIONS_USAGE_HISTORY. During private preview, you can’t designate a specific warehouse or set a credit cap.

• Cortex Agents and CoCo usage appears in CORTEX_AGENT_USAGE_HISTORY.
• CoWork usage appears in SNOWFLAKE_COWORK_USAGE_HISTORY, not in CORTEX_AGENT_USAGE_HISTORY.
• LLM usage appears in CORTEX_AI_FUNCTIONS_USAGE_HISTORY.

For the full set of usage views, see AI cost management and governance.

Region and cloud availability¶

Cortex Sense is available in every region where you have access to both the underlying LLMs and Cortex Search. If LLMs are unavailable in your region, inference is processed through Snowflake’s cross-region infrastructure. Whatever context you provide to Cortex Sense may be sent to the LLM for processing.

Private preview program¶

Feedback¶

Snowflake welcomes feedback through your account team on context accuracy, build performance, and coverage gaps. Participation does not obligate production enablement.

Testing in a dev environment¶

If you start in a dev environment before enabling in production, be aware that dev environments often lack the query history, dashboards, and business context available in production. Without production-like data, quality and coverage won’t reflect what you’d see in production.

Before promoting to production, consider validating scope accuracy, running evals on business questions, checking indexing costs in CORTEX_AI_FUNCTIONS_USAGE_HISTORY, and confirming you can turn the feature off again (see Turning off the feature).

What to expect at GA¶

Expected changes at GA may include formalized indexing costs (currently variable) and self-service enablement.

Turning off the feature¶

To take a single context away from a role, revoke its USAGE:

REVOKE USAGE ON CORTEX SENSE <database>.<schema>."sales" FROM ROLE <role>;

This is the narrowest option, and usually the one you want. Since USAGE is all a role needs to query, revoking it stops that role from querying. Any other context it was granted still works.

To stop a role from building new contexts, revoke the database role. This doesn’t affect querying. Repeat it for each role that has the grant:

REVOKE DATABASE ROLE SNOWFLAKE.CORTEX_SENSE_BUILDER FROM ROLE <role>;

Alternatively, you can contact Snowflake to disable the feature for the entire account at once. Disabling removes access to any context built in your account, and prevents scheduled refresh from running after release.

If you have already created Cortex Sense objects in your account, they will persist even if you disable the feature and will be available again if you re-enable it. You can delete those objects by asking CoCo:

> $cortex-sense delete my Cortex Sense objects

Disabling takes effect immediately. Deleting Cortex Sense objects through CoCo is asynchronous. Queries not using Cortex Sense are unaffected.