← All visual guides AI

What Cortex is and how I use it

The parts of Snowflake Cortex I actually reach for, and how a RAG app fits together without moving data out.

7 min read

Cortex AI, inside Snowflake LLMs, search and text-to-SQL that run where the data already lives Your data tables · docs · PDFs tickets · call notes Snowflake Cortex LLM functions COMPLETE · SUMMARIZE TRANSLATE · SENTIMENT CLASSIFY · EXTRACT Cortex Search hybrid vector + keyword the "R" in RAG auto-refreshes with data Cortex Analyst question → SQL guided by a semantic model you define Document AI pull fields out of invoices, forms, scans into columns Cortex Agents plan → Search or Analyst → run tools → answer with citations one API for chat apps, Slack bots, Snowflake Intelligence Call it from ▸ plain SQL ▸ Python / Snowpark ▸ REST API ▸ Streamlit apps ▸ Snowflake Intelligence Models hosted in-platform Anthropic · OpenAI · Meta · Mistral no keys, no egress, billed in credits Data never leaves the governance boundary RBAC, masking policies, row access and lineage apply to AI calls too sketch 01 · snowflake, drawn out
Click the sketch to open it full size

When a customer asks me to help “add AI” to their Snowflake data, the first hour is usually spent undoing a plan that involves exporting tables to a vector database, running an embedding job somewhere else, and putting an API in front of it. Somewhere in that plan the row-level security they spent two years on quietly stops applying.

Cortex is the set of Snowflake features that let you skip that. The models run inside the account, the data stays where it is, and the same roles and policies apply. This is the drawing I do on the whiteboard, and what I say while I draw it.

LLM functions

The simplest piece. SQL functions that call a hosted model. No API keys, nothing leaves the account, billed in credits like everything else.

SELECT
  ticket_id,
  SNOWFLAKE.CORTEX.SENTIMENT(body)                                   AS sentiment,
  SNOWFLAKE.CORTEX.SUMMARIZE(body)                                   AS summary,
  SNOWFLAKE.CORTEX.CLASSIFY_TEXT(body, ['billing','bug','feature'])  AS bucket
FROM support.tickets
WHERE created_at > DATEADD(day, -7, CURRENT_DATE);

For open-ended prompts there is AI_COMPLETE, which takes a model name and a prompt and can return structured JSON if you give it a response format. Which models are available depends on your region. Anthropic, OpenAI, Meta and Mistral models are in the catalog, and cross-region inference is a setting you turn on if the one you want is not local.

The thing I point out is that because these are functions, they compose with normal SQL. You can run them in a task, join the output, put a masking policy on the result column. That is most of the value.

A managed search index over a text column. You point it at a table, it handles embeddings, keyword indexing and refresh as the data changes.

CREATE CORTEX SEARCH SERVICE support.ticket_search
  ON body
  ATTRIBUTES product, region
  WAREHOUSE = cortex_wh
  TARGET_LAG = '1 hour'
AS SELECT ticket_id, body, product, region FROM support.tickets;

Two things it does that you would otherwise build yourself:

  • Hybrid ranking. Vector similarity plus keyword match plus a reranker. Vector-only search is poor at exact product names and error codes, and hybrid fixes most of that.
  • Filters that go through the role. The ATTRIBUTES columns become filters, and the service runs as a role, so row access policies still apply.

Cortex Analyst

Search is for documents. Analyst is for questions like “what was churn in EMEA last quarter”. It turns a question into SQL, but only against a semantic model you write: a YAML file listing the tables, the measures, the synonyms, and some verified queries.

The semantic model is where the work is. Without one you get plausible-looking SQL that is wrong. With a tight one it is accurate enough to put in front of someone who will act on the answer. I tell customers to budget real time for it.

Document AI

Invoices, forms, contracts, scanned claims. You define the fields you want, correct a handful of examples, and then extract at scale with a SQL call. The output is a table, so it feeds everything else here.

Cortex Agents

An agent takes a message, decides whether to call Search or Analyst or both, runs them, and answers with citations. It is a REST API, so the same agent can sit behind a Slack bot, a Streamlit app, or Snowflake Intelligence, the built-in chat UI.

How the pieces fit for a support copilot

  1. Tickets and product docs are already in tables.
  2. One Search service on the docs, one on the tickets.
  3. A semantic model over the ticket metrics table, for Analyst.
  4. An agent with those three tools.
  5. Call the agent from Streamlit in Snowflake, or from your own front end over REST.

Nothing left the account. The role decides what the agent can see. It shows up on the same bill.

Where it goes wrong

  • Skipping the semantic model. Analyst is only as good as the YAML.
  • Treating Search like a bare vector store. The attributes and filters are where the accuracy comes from.
  • No cost guardrails. LLM functions are metered by tokens. Put the workload on its own warehouse with a resource monitor and check CORTEX_FUNCTIONS_USAGE_HISTORY after the first week.
  • Region surprises. Find out before the demo whether the model you want is available where the account lives.

Model names and regional availability change every few months. The shape does not: functions for transforming text, Search for retrieval, Analyst for metrics, Agents to tie them together, all inside the account.