Snowflake Cortex vs. External AI Agents: What Each Is Actually For

Short answer: Snowflake Cortex is for language over data that stays inside the warehouse. Summarize a column, classify tickets, extract entities, ask questions over your tables. External agents are for work that has to leave the warehouse: update a CRM, post to Slack, enrich a lead from a live API, open a support ticket. They solve different halves of the same problem, and most teams that use one seriously end up wanting both.

We build Cotera, an agent platform with a Snowflake Native App, so we have an obvious interest here. We are going to be straight about it anyway, because the "vs." framing is mostly wrong. We tell our own customers to use Cortex for a whole class of work.

What Cortex is genuinely good at

Cortex puts LLM functions directly in SQL, running inside Snowflake's security perimeter. That is a real advantage for a specific shape of work:

• Summarization and classification over columns you already have. SNOWFLAKE.CORTEX.COMPLETE over a million support ticket bodies is exactly what it is for.
• Entity extraction and text transformation. Pulling structured fields out of notes, translating text, sentiment on reviews.
• Semantic search and questions over your data. Cortex Search and Cortex Analyst let people ask questions over governed data without the data going anywhere.
• Governance by default. The data never leaves Snowflake. For regulated teams, that alone decides the question.

If your task is "apply language understanding to rows in my warehouse and store the answer in another column," use Cortex. You do not need an external agent for that, and adding one would be overkill.

Where Cortex stops

Cortex stops at the warehouse boundary, and most operational work does not.

Consider what happens after the classification. You scored 200 accounts as churn risks. Now someone needs to create CSM tasks in the CRM, post the top ten to a Slack channel, and pull fresh usage data from a product API that is not in the warehouse yet. That is three external systems, each with its own auth, rate limits, and failure modes.

This is the gap in practice:

None of these rows is a criticism of Cortex. It is a boundary. Snowflake drew it deliberately, and the governance benefits above come from that same boundary.

The pattern: use both from the same query

The setup we see work is a division of labor inside one SQL pipeline. Cortex handles the in-warehouse language step, and an external agent handles the step that acts on the result.

With the Cotera Native App installed from the Snowflake Marketplace, that looks like this:

WITH scored AS (
  -- Cortex: classify inside the warehouse
  SELECT
    ticket_id,
    customer_id,
    SNOWFLAKE.CORTEX.CLASSIFY_TEXT(
      ticket_body, ['billing', 'bug', 'feature_request', 'outage']
    ) AS category
  FROM support.open_tickets
  WHERE created_at > DATEADD('hour', -24, CURRENT_TIMESTAMP())
)
-- Cotera: act on the classification, outside the warehouse
SELECT
  ticket_id,
  category,
  cotera.agents.agent('<your agent id>', ticket_id || ': ' || category) AS routing_result
FROM scored
WHERE category:label::string = 'outage';

Cortex does the cheap, fast, in-perimeter classification over every ticket. The agent only fires for the rows that need action, and it does the multi-step work: look up the customer, check SLA status, page the on-call, post to the incident channel. Each half does the thing it is built for.

The agent side is a predefined agent, configured once in Cotera with its tools, permissions, and instructions. The SQL decides which rows get sent. It does not decide how the agent behaves. That separation is what makes the pattern reviewable: your data team can read the query, your ops team can read the agent definition, and neither has to trust a prompt buried in a stored procedure.

How to decide, quickly

Ask one question about the task: does the answer stay in the warehouse?

• Stays in: Cortex. Summaries, classifications, extractions, semantic search, natural-language questions over tables.
• Leaves: external agent. CRM writes, Slack posts, live API enrichment, ticket creation, anything with more than one step across more than one system.
• Both: split it like the query above. Classify in Cortex, act with the agent, write the results back to a table so the output becomes warehouse data like everything else.

A second question worth asking: who has to maintain the failure handling? A Cortex call inside Snowflake fails like SQL fails, visibly and retryably. An external API call fails like the internet fails: rate limits, expired tokens, half-finished work. If you build that path yourself with external access and UDFs, retries, backoff, and observability become your code to own. An agent runtime exists so it is not. We wrote more about that problem in Why Reliable AI Workflows Are Hard to Run From the Data Warehouse.

What about cost?

Cortex is priced on consumption, and for in-warehouse text operations it is usually the cheapest way to run them, since there is no data movement and no second platform. The place cost surprises people is not Cortex. It is what happens when teams try to do the acting part with brute force: one long-running agent chat that carries the whole history, or a per-row script with no batching. We benchmarked that failure mode directly. Two hundred agent tasks run serially cost 16 to 200 times more than the same tasks run as parallel jobs, and were less accurate. The data is in Serial vs. Parallel AI Agents: We Benchmarked 200 Tasks Both Ways.

The SQL calling pattern gets you the efficient shape for free: each row is an independent, parallel agent run with only the context that row needs.

FAQ

Is Cotera a replacement for Snowflake Cortex? No. Cortex handles language over data inside the warehouse. Cotera runs agents that act outside it. The pattern we recommend uses both in the same query.

Does my data leave Snowflake when I call an external agent? Only the columns your query passes to the agent call. You control that selection row by row, in SQL, subject to your existing warehouse permissions and row-level security.

Can Cortex call external APIs? Cortex functions operate over data in the warehouse. Snowflake offers external access for UDFs, but then retries, rate limits, auth, and observability across those calls are yours to build and maintain. That runtime is the part an agent platform provides.

When is Cortex clearly the right choice? When the task is language over data you already have and the result stays in Snowflake: summarization, classification, extraction, translation, semantic search. Especially when governance requires that data never leave the perimeter.

How do I try the combined pattern? Install the Cotera Native App from the Snowflake Marketplace, connect an API key, and call a predefined agent from a worksheet. The install guide takes about ten minutes end to end.

Try These Agents

Browse the full catalog on Solutions, or start with these:

• Company Growth Analyzer — Research company growth, traffic trends, and competitive landscape from a domain
• Lead Enricher & Qualifier — Qualify inbound leads from CRM and warehouse data with structured scoring
• Market Intelligence Agent — Monitor competitors, hiring patterns, and market moves across your target accounts