Most data teams sit on two very different kinds of knowledge. One lives in tables a warehouse can query. The other is buried in support tickets, contracts, and PDFs that no SQL statement will ever touch. Snowflake’s Cortex Agents exist to answer the questions that need both.
Cortex Agents entered public preview at Snowflake Summit in June 2025, launching alongside Snowflake Intelligence. Since then they have become the piece of the platform most likely to show up in a customer’s architecture diagram, and the one most often misunderstood.
What Snowflake Cortex Agents actually are
A Cortex Agent is a managed, server-side service. You hand it a natural-language question, it decides which tools it needs, runs them, and returns an answer with citations pointing back to the specific rows and documents it used.
The important word is managed. You are not wiring together orchestration graphs or hosting your own planning layer. You define the agent’s tools and instructions; Snowflake handles tool selection, retries, and the final synthesis step. Everything executes inside your account, so every query the agent issues runs under the same role-based access controls, masking policies, and row access policies that already govern your human users.
Three components do the heavy lifting
- Cortex Analyst handles structured questions. It turns natural language into SQL against a semantic view you define, rather than guessing at raw table schemas.
- Cortex Search handles unstructured retrieval, combining vector similarity with keyword matching across the documents you index.
- The orchestration layer picks a model, plans the steps, decides when it needs both Analyst and Search, and assembles the response.
You can also attach custom tools, including calls to external APIs or your own stored procedures, so an agent can take action rather than just report.
Cortex Agents vs Snowflake Intelligence
These two get conflated constantly. Snowflake Intelligence is the end-user product: a web interface where a finance analyst types a question and gets a cited answer. Cortex Agents is the engine underneath, exposed as a REST API plus SQL and Python interfaces.
If you want out-of-the-box chat for business users, Intelligence is the path of least resistance. If you need to embed an agent inside your own application or chain it into an existing workflow, you want the Cortex Agents API directly. Plenty of large deployments end up doing both.
How an agent answers a genuinely messy question
Take something a sales operations lead might actually ask: which enterprise accounts in EMEA renewed late last quarter, and what did they complain about in support tickets?
No single table answers that. The agent decomposes it. Cortex Analyst queries revenue and opportunity tables through the semantic view to find late renewals. Cortex Search retrieves the relevant ticket threads and call transcripts. The planner then combines both result sets and writes a response listing the accounts, the renewal dates, and the recurring themes from the tickets, with citations back to specific records.
That last part matters more than it sounds. Citations are what turn a plausible-sounding answer into something an analyst can verify in thirty seconds. If you have ever built this pipeline by hand, the amount of glue code involved in getting from question to cited answer is exactly the pain this removes.
Governance is the real differentiator
Any vendor can point a language model at a database. The harder problem is doing it without leaking salary data to someone in the wrong role.
Because Cortex Agents run inside Snowflake, they inherit your security model instead of bolting a new one on top. A user asking a question gets answers built from rows they are permitted to see. Masked columns stay masked. If policy says a regional manager only sees EMEA, the agent cannot reason its way around that, because the SQL it generates executes as that user.
Two habits are worth building early. Log and review agent queries the way you review dashboard usage, because an agent with broad tool access can generate a lot of expensive SQL very quickly. And treat your semantic layer as a product rather than a side project. The quality of any text-to-SQL agent is downstream of how well your metrics and joins are defined, a point that keeps resurfacing in the long-running argument about semantic layers in BI.
What it takes to ship one
- Model your data first. Build semantic views with clear metric definitions and a set of verified queries covering the questions you expect.
- Index your documents. Create a Cortex Search service over the PDFs, tickets, or transcripts the agent should read.
- Write the agent spec. Tools, instructions, and a description that tells the planner when to reach for each one.
- Test against real questions. Pull the last 100 questions your analysts asked and score the answers. Expect to fix the semantic view far more than the prompt.
- Expose it. Publish through Snowflake Intelligence for internal users, or call the REST API from your application.
The cost picture
Cortex Agents are credit-based. You pay for model tokens, plus the compute behind Analyst queries and Search retrieval. Simple single-source questions are cheap. A question that triggers four Analyst calls and two search queries, re-planned because the first attempt returned nothing useful, is not.
Budget for iteration, not just production traffic. Tuning prompts and semantic views on real workloads is where most early spend lands, and cross-region inference settings can shift the bill further.
Use cases that hold up
The patterns that work in practice share one trait: the answer requires pulling from more than one place.
- Revenue teams reconciling bookings against contract terms buried in PDFs.
- Support leaders correlating ticket volume with product release dates.
- Supply chain analysts checking shipment exceptions against supplier emails.
- Sales reps prepping for a call by combining account history with recent escalations.
Where a single dashboard already answers the question, agentifying it usually just adds latency and cost for no gain.
Where it still falls short
Joins spanning a dozen loosely modelled tables remain unreliable, and no amount of prompt engineering rescues a semantic layer nobody maintains. Latency on multi-tool questions runs into tens of seconds, which is fine for research and painful for anything interactive. Feature parity across cloud regions is not guaranteed either.
There is a human factor too. Agents change the shape of the question people ask. Instead of show me renewals by region, they ask why EMEA churn is up. That shift is genuinely useful, but it puts far more weight on the underlying data model than most organisations are currently ready for.
Where this fits in Snowflake’s bigger bet
Cortex Agents are not an isolated feature. They sit on top of a stack Snowflake has been assembling for two years: AISQL functions, Document AI, semantic views, and a growing pile of infrastructure commitments, including the multibillion-dollar AWS agreement securing AI chip capacity that underpins much of this compute.
One thing Cortex Agents do not solve for you is memory across sessions. An agent answers the question in front of it; remembering that a user prefers EMEA-level rollups, or that last week’s answer was wrong, is still your problem. Other domains are wrestling with the same gap, as this piece on why AI coding assistants need a persistent memory layer lays out.
Pick one question and build backwards
The teams getting value from Cortex Agents today did not start with a platform strategy. They started with a single question that was expensive to answer manually, built the semantic view and search service needed to answer it, and measured whether the agent got it right.
Tool definitions, eval sets, and cost dashboards all follow from that loop. If your first agent answers one real question correctly and cheaply, you will learn more in a week than a quarter of architectural debate would give you. If it does not, you will know exactly which part of your data model to fix next.