Moving Cortex Analyst into Cortex Agents is not a semantic rebuild—but it is a new execution boundary

Snowflake now recommends that Cortex Analyst users transition to Cortex Agents. The reassuring part is explicit: existing Analyst applications continue to work, the Analyst REST API remains available, and the migration does not require rebuilding the semantic layer. The risky part is less obvious: the same NL2SQL tool is moving inside a broader planning and tool-execution loop.

What carries over

Snowflake says Cortex Agents invokes Cortex Analyst as the tool for querying structured data. Existing semantic views carry over unchanged, and verified queries continue to apply because they are stored in those semantic views. For a team with substantial work invested in business definitions and curated SQL examples, that makes the transition an invocation change rather than a new modeling project. Snowflake’s transition notice also says existing applications and the standalone Analyst REST API remain available.

That continuity suggests a sensible first migration test: run the same question set against the existing Analyst endpoint and an Agent configured with the same semantic views. Compare generated SQL, returned rows, clarification behavior and abstentions. Do not treat “the semantic assets carried over” as proof that the end-to-end answers will be identical.

What changes around the SQL generator

Cortex Agents adds a managed orchestration loop that plans, calls tools, reflects on results and can repeat those steps within one request. It can combine Analyst with Cortex Search, code execution, charts, custom functions or procedures, skills, MCP connectors and web search. Threads can also preserve context across turns. Those capabilities are the reason to migrate—but they enlarge the system under test beyond SQL generation alone. Snowflake’s Cortex Agents documentation describes an agent as a schema-level object containing its model, tools, orchestration settings and instructions.

The permissions test matters especially. Snowflake says data access follows Snowflake privileges and each tool’s execution context. It also says a run can continue when the caller cannot use every configured tool, using only the tools that remain accessible. That is safer than granting access implicitly, but it creates a partial-capability state that applications should surface clearly rather than silently presenting as a complete answer.

A practical cutover gate

Before sending production traffic to the Agent endpoint, keep the semantic view and verified-query repository fixed, then test four things:

1. Parity: the Agent’s structured-data answers meet or beat the current Analyst baseline.
2. Routing: prompts intended for structured data actually invoke Analyst, especially when search or custom tools are also present.
3. Identity: each user receives only the tools and underlying data their role can access.
4. Degraded behavior: when one configured tool is inaccessible, the response identifies the missing capability instead of implying a complete result.

Snowflake’s notice removes the largest migration fear: teams do not need to throw away their semantic work. It does not remove the need for an acceptance test. The asset boundary stays stable; the execution boundary gets wider.