Snowflake Cortex Explained: AI Functions, Analyst, Search & Cortex Code

What is Snowflake Cortex

Snowflake Cortex is not one feature — it's the umbrella name for everything AI-related that Snowflake ships natively inside the platform. That matters more than it sounds: before Cortex, "adding AI to your data" usually meant exporting rows to a separate service, waiting on an API, and hoping nothing sensitive leaked in transit. Cortex flips that. The model runs where the data already lives, governed by the same roles and masking policies you already have.

Four pieces make up the suite, and they solve different problems:

• Cortex AI functions — SQL functions that call a large language model row by row, usable in any SELECT.
• Cortex Analyst — converts a natural-language business question into SQL, for dashboards and chat-style BI.
• Cortex Search — retrieves relevant passages from unstructured text (PDFs, tickets, wikis) using hybrid semantic + keyword search.
• Cortex Code (CoCo) — an AI coding agent embedded in Snowsight that writes, explains, and fixes SQL.

The rest of this article walks through each one with runnable SQL, then covers what a SQL learner should actually do with them.

Cortex AI functions: AI you call from SQL

This is the piece that surprises people who haven't looked at Cortex closely: these are ordinary SQL functions. No API keys, no separate SDK, no leaving your worksheet. You call them in a SELECT exactly like you'd call UPPER() or DATEDIFF(), except the "computation" is an LLM inference.

-- Free-text generation on a column
SELECT ticket_id,
       AI_COMPLETE('llama3.1-70b', 'Write a one-sentence customer-facing summary of: ' || description) AS summary
FROM support_tickets;

-- Classify text into your own categories -- no training required
SELECT review_id,
       AI_CLASSIFY(review_text, ['billing', 'bug', 'feature request', 'praise']) AS category
FROM product_reviews;

-- Sentiment, translation, and row-level filtering with an LLM predicate
SELECT review_id, AI_SENTIMENT(review_text) AS sentiment
FROM product_reviews
WHERE AI_FILTER(PROMPT('Does this review mention a competitor product? {0}', review_text));

-- Summarize an entire column across thousands of rows in one call --
-- not limited by a single model's context window
SELECT AI_AGG(review_text, 'Summarize the top 3 recurring complaints in these reviews.') AS theme_summary
FROM product_reviews
WHERE review_date >= DATEADD(month, -1, CURRENT_DATE());

Beyond text, there's a function for nearly every common AI task: AI_EXTRACT pulls structured fields out of unstructured text or a document, AI_EMBED generates vector embeddings for similarity search, AI_PARSE_DOCUMENT runs OCR/layout extraction on PDFs and images, AI_TRANSCRIBE converts audio to text, and AI_TRANSLATE and AI_REDACT handle translation and PII removal respectively. Each one is a plain SQL function — the skill you already have (writing a correct SELECT, filtering the right rows, joining the right tables) is exactly what makes these usable at scale instead of one-row-at-a-time in a notebook.

Cortex Analyst: plain English in, SQL out

Cortex Analyst targets a different audience: people who need answers from your structured tables but don't write SQL themselves. It converts a natural-language question into a SQL query and runs it, but — critically — it doesn't do this by guessing at your schema. It relies on a semantic model, a YAML file you (the SQL-literate person) write, that maps business language to actual tables, columns, joins, and calculated metrics.

# A trimmed semantic model — this is what Cortex Analyst reads
tables:
  - name: orders
    description: "One row per customer order"
    dimensions:
      - name: order_status
        synonyms: ["status", "order state"]
    measures:
      - name: total_revenue
        expr: "SUM(order_amount)"
        synonyms: ["sales", "revenue"]

Ask "what was our revenue by order status last month" against this model, and Cortex Analyst generates the equivalent GROUP BY order_status query with the correct date filter and SUM expression — because the semantic model told it exactly where "revenue" and "status" live. Skip the semantic model, or leave it thin, and accuracy drops fast: the LLM starts guessing at column names instead of looking them up. It's exposed as a REST API too, which is why you'll see it embedded in Streamlit apps, Slack bots, and Teams integrations rather than only inside Snowsight.

Cortex Search: semantic search over documents

Where Cortex Analyst handles rows and columns, Cortex Search handles paragraphs and pages. It builds a hybrid search index — combining vector similarity with traditional keyword matching — over a text column, so questions like "what's our refund policy for enterprise accounts" return the actual relevant passage from a policy document instead of forcing a full-text LIKE '%refund%' scan.

CREATE OR REPLACE CORTEX SEARCH SERVICE support_docs_search
  ON chunk_text
  ATTRIBUTES doc_title, doc_url
  WAREHOUSE = search_wh
  TARGET_LAG = '1 hour'
  AS (
    SELECT chunk_text, doc_title, doc_url
    FROM parsed_support_documents
  );

This is the piece most relevant if you're building a retrieval-augmented (RAG) chatbot on top of internal documentation — it's the retrieval half, typically paired with AI_COMPLETE to generate the final natural-language answer from the retrieved passages.

Cortex Code (CoCo): the AI agent inside Snowsight

Cortex Code — Snowflake's own docs shorten it to CoCo — is the newest piece, and the one closest to a pair-programmer for SQL. It sits as a chat panel inside Snowsight and, unlike the AI functions above, isn't something you call from a query — it's an agent that plans and executes multi-step tasks on your behalf.

In practice, CoCo can:

• Write and modify SQL from a plain-English description, showing a diff of the proposed change before you accept it.
• Explain existing queries and point out what a failed statement actually got wrong, with a suggested fix.
• Find objects by description — "the table with last quarter's churn numbers" — instead of requiring the exact table name.
• Answer operational questions about who has access to what, current warehouse credit consumption, and relevant Snowflake documentation.
• Work across Worksheets, Notebooks, and dbt projects inside the same interface, keeping conversation context between steps.

Access requires the SNOWFLAKE.COPILOT_USER role plus SNOWFLAKE.CORTEX_USER or SNOWFLAKE.CORTEX_AGENT_USER — worth checking with your account admin before assuming it's available, since it isn't switched on by default for every role.

How to start using Cortex today

You don't need a production project to try this. A Snowflake trial account includes free credits, which is enough to run every example above:

1. Confirm your role has Cortex access. Run SHOW GRANTS TO ROLE your_role and check for CORTEX_USER; ask an account admin to grant it if it's missing.
2. Start with a single AI function on a small table. AI_CLASSIFY or AI_SENTIMENT on a handful of rows is the cheapest way to see real output and get a feel for token cost before scaling up.
3. Only then build a semantic model for Cortex Analyst — it's the highest-effort piece of the suite, so it pays to already understand the underlying tables well through plain SQL first.
4. Open the CoCo panel in Snowsight and ask it to explain a query you already wrote. Comparing its explanation against what you know the query does is a fast way to build trust in — or catch a mistake from — the agent.

Do you still need to know SQL

Yes, more than ever — just for a different reason than before. Cortex doesn't remove SQL from the picture; it changes what SQL knowledge buys you. Every AI function is invoked from a SELECT, so writing correct joins and filters still determines whether you're running the LLM against the right 500 rows or an accidental 5 million. Cortex Analyst's entire accuracy ceiling is set by how well someone who understands the schema wrote the semantic model — a bad mapping produces confidently wrong SQL that a non-SQL user has no way to catch. And CoCo's SQL suggestions still need a human who can read the diff and recognize when the generated query is subtly wrong, not just syntactically valid.

In short: Cortex removes the need to hand-write boilerplate. It does not remove the need to understand what correct output looks like — that's still a SQL skill.

Common mistakes

• Running an AI function over an entire unfiltered table. Every row is a separate model call billed by tokens — filter first, then apply the AI function, the same discipline as any expensive join.
• Treating Cortex Analyst's output as always correct. A thin or outdated semantic model produces SQL that runs without error but references the wrong metric — always spot-check against a query you'd write by hand.
• Confusing Cortex Analyst with Cortex Search. One queries structured tables; the other retrieves passages from documents. Pointing a structured-data question at Search (or vice versa) gives a technically-answered but practically useless result.
• Not pinning a model version in AI_COMPLETE calls used in production pipelines — output can shift subtly as Snowflake updates default models, which matters if downstream logic depends on exact phrasing.
• Granting CoCo write access without a review habit. Treat its suggested SQL changes the same way you'd treat a pull request — read the diff before accepting it, especially for anything beyond a SELECT.