What you will be able to do
- Describe how a Cortex Agent plans, uses tools (including MCP connectors) and reflects, and where users interact with agents
- Identify the REST interfaces for Cortex Analyst, Cortex Search and Cortex Agents and what they require
- Use core Cortex Code CLI commands and slash commands, and write prompts for unattended runs
- Configure CORTEX_ENABLED_CROSS_REGION and weigh its residency, latency, availability and billing implications
1.Cortex Agents, MCP and the agent experiences
Cortex Agents is a fully managed platform for running AI agents inside Snowflake's governed environment. An agent is a reusable, schema-level object that bundles a model, tools and orchestration instructions. You steer it with natural-language instructions, which is where prompting matters most, and Snowflake recommends choosing auto for the model. An agent combines structured and unstructured data: Cortex Analyst semantic views for SQL and Cortex Search for documents. It can also use a Python code-execution sandbox, a Data to Chart tool, custom tools built from stored procedures and UDFs, packaged skills, web search, and MCP connectors to remote Model Context Protocol servers. These connectors let an agent discover and call tools hosted by providers such as Atlassian Jira or Salesforce. An agent with no tools can still chat, but it answers only from the model's general knowledge. Threads keep conversation state across turns, so your client application doesn't have to.
Checkpoint 1 of 5· Put it in order
Put the steps of an agent's reasoning loop in order for a single request
- 1.Plan: parse the request, disambiguate it, split it into subtasks and choose tools
- 2.Reflect and respond: evaluate tool results, then ask a clarifying question, call another tool or answer
- 3.Use tools: call Cortex Analyst, Cortex Search, code execution or other selected tools
Orchestration is a plan, use tools, reflect loop. The agent can repeat it as many times as needed within one request.
“The LLM-driven plan, use tools, reflect loop the agent runs to answer a request.”Source: docs.snowflake.com
Where users meet agents. Besides calling agents from your own applications through the REST API, users can work with them in Snowflake CoWork and Cortex Code. In CoWork, a natural-language question goes to the Cortex Agent API. An orchestrator LLM picks tools, runs them, and returns summaries, tables or charts. The exam guide lists Snowflake Intelligence, but none of the sources available for this lesson use that name. They document the agent chat experience as Snowflake CoWork, so check the current product documentation for how the two names relate.
2.REST APIs across Cortex
Every capability in this lesson can be reached over REST, which is how you embed them in your own applications. Cortex Analyst takes an API-first approach, and requests must include an authorization token. It supports multi-turn conversations when you pass the history in a messages array, where user turns hold text and analyst turns hold text plus SQL. Cortex Agents can be created in Snowsight, with SQL commands or through the REST API, and integrated through REST. A single request is a run through the agent:run API, which emits events showing the agent's reasoning and tool calls. When you create a Cortex Search Service, Snowflake provisions a low-latency endpoint for it, and you can call that endpoint directly:
curl --location https://<ACCOUNT_URL>/api/v2/databases/<DB_NAME>/schemas/<SCHEMA_NAME>/cortex-search-services/<SERVICE_NAME>:query \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--header "Authorization: Bearer $PAT" \
--data '{
"query": "<search_query>",
"columns": ["col1", "col2"],
"filter": <filter>,
"limit": <limit>
}'Checkpoint 2 of 5· Check yourself
A chat app built on the Cortex Analyst REST API must handle a follow-up such as "What about North America?" What does the client send?
Cortex Analyst rephrases follow-ups from the earlier turns you send it, so the client passes the full message history in chronological order.
“To use this feature, pass the conversation history in the messages field”Source: docs.snowflake.com
3.Snowflake Cortex Code (CoCo) and its CLI
Snowflake Cortex Code, called CoCo in the docs, is an AI agent for data engineering, analytics, ML and agent-building work. It understands Snowflake RBAC and schemas. It comes in three forms: in Snowsight, as a desktop IDE, and as a CLI started with cortex. The CLI runs in interactive mode by default, where it keeps a persistent session with context. Batch mode takes one prompt and exits. Connections are defined in ~/.snowflake/connections.toml.
| Command | What it does |
|---|---|
| cortex -c production | Start with specific connection |
| cortex -w /path/to/project | Start in specific directory |
| cortex --continue | Continue last session |
| -p, --print "<prompt>" | Pass specified prompt, print response, and exit |
| cortex exec "<prompt>" | Run a prompt and exit (non-interactive, for CI/CD) |
| cortex mcp list | List configured servers |
| cortex update | Update to latest version |
Inside an interactive session, slash commands control CoCo itself and are not sent to the model. Some examples are /model, /plan, /sql <query>, /mcp and /bypass. cortex mcp add registers MCP servers over stdio, sse or http. Be careful with bypass mode (--bypass / /bypass), which approves every tool call without asking you first. CoCo automations run without a person present, so the docs give prompt guidance for them: say the run is unattended, tell CoCo not to ask follow-up questions, name exact objects, and define the expected output and what to do on failure.
Checkpoint 3 of 5· Match them up
Match each interactive slash command to what it does
Tap a term, then the definition that fits it.
These come from the CLI's slash-command tables. They only work in interactive mode, not in batch mode or with cortex exec.
“Slash commands are special commands you type at the interactive prompt.”Source: docs.snowflake.com
4.Cross-region inference and CORTEX_ENABLED_CROSS_REGION
Many frontier models are not deployed in every region. For example, Cortex Agents' models run only through cross-region inference, and Cortex Analyst can be used outside its native regions only once cross-region inference is enabled. A single account-level parameter, CORTEX_ENABLED_CROSS_REGION, sets how far Snowflake may route inference requests. Stored data stays in your account's region. Only the prompt and response travel to the processing region, and only for the duration of processing; they are not persisted there.
| Type | Parameter value | Routing behavior |
|---|---|---|
| Global | ANY_REGION | Any Snowflake-supported region, across any cloud provider |
| Cloud-specific | AWS_GLOBAL, AZURE_GLOBAL, GCP_GLOBAL, or comma-separated combinations | Stays within a designated cloud provider |
| Regional | AWS_US, AWS_EU, AWS_APJ, AWS_JP, AWS_AU, AZURE_US, AZURE_EU, GCP_US, or comma-separated combinations | Stays within designated cloud provider regions |
| Disabled | DISABLED | Only your account's home region |
Checkpoint 4 of 5· Fill the gap
Which value restricts inference to the account's home region?
ALTER ACCOUNT SET CORTEX_ENABLED_CROSS_REGION = ' ? ';DISABLED gives the strictest data residency, but it limits you to the models and features deployed in your own region.
Source: docs.snowflake.comConsiderations. The parameter can only be set at the account level, only by ACCOUNTADMIN, and never by ORGADMIN. If you haven't set it, the default depends on the account. New organizations created after March 9, 2026 get ANY_REGION. Other commercial accounts inherit a same-cloud geography value such as AWS_US, so set it explicitly if you have residency requirements. Data in transit is always encrypted. It stays on the provider's private backbone within one cloud and uses mTLS over the public internet across clouds. Latency depends on provider infrastructure and network status, so test your workload. Cross-region inference for Cortex Search is not supported in every region. Government regions have their own boundaries: for example, FedRAMP High Plus and DoD regions never route requests to each other.
Checkpoint 5 of 5· Check yourself
Which statement about CORTEX_ENABLED_CROSS_REGION is correct?
The parameter is account-level only and ACCOUNTADMIN-only. Defaults vary by account: ANY_REGION for new organizations after March 9, 2026, and a same-cloud geography for other commercial accounts.
“Only the ACCOUNTADMIN role can modify this parameter using the ALTER ACCOUNT command. This parameter cannot be set by the ORGADMIN role.”Source: docs.snowflake.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Cross-region inference is off by default, so every account processes inference only in its home region until an admin enables it.Why is that wrong?
Accounts inherit a default when the parameter is unset. New organizations after March 9, 2026 get ANY_REGION, and other commercial accounts inherit a same-cloud geography value.
Covered in Cross-region inference and CORTEX_ENABLED_CROSS_REGION
2.An org-wide admin (ORGADMIN) or a per-user session setting can control cross-region routing.Why is that wrong?
The parameter can only be set at the account level, and only by ACCOUNTADMIN.
Covered in Cross-region inference and CORTEX_ENABLED_CROSS_REGION
3.Routing inference to another region incurs data egress charges and bills credits in the processing region.Why is that wrong?
Credits are billed in the requesting region, and cross-region inference has no egress charges.
Covered in Cross-region inference and CORTEX_ENABLED_CROSS_REGION
Practise it for real
Inspect and then deliberately set your account's cross-region inference boundary
1.As ACCOUNTADMIN, run SHOW PARAMETERS LIKE 'CORTEX_ENABLED_CROSS_REGION' IN ACCOUNT;
Why: An unset parameter inherits a default that depends on your account, so check what is actually in effect.
You should see: The value column shows the routing scope in effect, such as ANY_REGION or a same-cloud geography like AWS_US.
2.Run ALTER ACCOUNT SET CORTEX_ENABLED_CROSS_REGION = 'AWS_GLOBAL'; (or the regional value your residency policy requires)
Why: Setting the value explicitly records your residency decision instead of relying on an inherited default.
You should see: The statement succeeds under ACCOUNTADMIN. Under ORGADMIN or a lower role it is rejected.
3.Run the SHOW PARAMETERS statement again
Why: Confirms that the new routing boundary is in effect.
You should see: The value column now shows the value you set.
Stuck? Get a nudge
If your residency rules allow no routing at all, DISABLED is valid too, but expect fewer models and features.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“letting agents discover and invoke tools hosted by providers such as Atlassian Jira, Salesforce, or your own applications”
↩︎ Cortex Agents, MCP and the agent experiences“You guide its behavior with natural-language instructions, and you can choose the language model that powers it or let Snowflake select one automatically.”
↩︎ Cortex Agents, MCP and the agent experiences“In addition to calling agents from your own applications through the REST API, users can interact with them in Snowflake CoWork and Cortex Code.”
↩︎ Cortex Agents, MCP and the agent experiences“or through the REST API, then integrate it into your application using the REST API”
↩︎ REST APIs across Cortex“The LLM-driven plan, use tools, reflect loop the agent runs to answer a request.”
↩︎ Checkpoint - 2.
“When a user asks a question in Snowflake CoWork, Cortex Agents turn natural language into governed actions and answers.”
↩︎ Cortex Agents, MCP and the agent experiences - 3.
“Requests to the Cortex Analyst API must include an authorization token.”
↩︎ REST APIs across Cortex“If your Snowflake account is in a different cloud region, you can still use Cortex Analyst by leveraging Cross-region inference.”
↩︎ Cross-region inference and CORTEX_ENABLED_CROSS_REGION“To use this feature, pass the conversation history in the messages field”
↩︎ Checkpoint - 4.
“delivered through three experiences: in Snowsight, as a standalone desktop IDE, and as a command line interface (CLI)”
↩︎ Snowflake Cortex Code (CoCo) and its CLI - 5.
“Use exec to run CoCo CLI non-interactively, which is useful in continuous integration and continuous delivery (CI/CD) pipelines.”
↩︎ Snowflake Cortex Code (CoCo) and its CLI“Bypass mode approves every tool call without prompting you first.”
↩︎ Snowflake Cortex Code (CoCo) and its CLI“Slash commands are special commands you type at the interactive prompt.”
↩︎ Checkpoint - 6.
“State that the run is unattended and must complete autonomously.”
↩︎ Snowflake Cortex Code (CoCo) and its CLI - 7.
“You control the routing behavior through a single account-level parameter, CORTEX_ENABLED_CROSS_REGION”
↩︎ Cross-region inference and CORTEX_ENABLED_CROSS_REGION“Latency between regions depends on the cloud provider infrastructure and network status.”
↩︎ Cross-region inference and CORTEX_ENABLED_CROSS_REGION“Cross-region inference for Cortex Search is not supported in all regions.”
↩︎ Cross-region inference and CORTEX_ENABLED_CROSS_REGION“This provides the strictest data residency posture but limits the models and features available to those deployed in your region.”
↩︎ Cross-region inference and CORTEX_ENABLED_CROSS_REGION“Other commercial accounts in supported regions inherit a same-cloud geography value such as AWS_US or AZURE_EU.”
↩︎ Exam trap 1“The CORTEX_ENABLED_CROSS_REGION parameter can only be set at the account level, not at the user or session levels.”
↩︎ Exam trap 2“You do not incur data egress charges for cross-region inference.”
↩︎ Exam trap 3“Credits are consumed in your requesting region, regardless of where the request is processed.”
↩︎ Prediction“Only the ACCOUNTADMIN role can modify this parameter using the ALTER ACCOUNT command. This parameter cannot be set by the ORGADMIN role.”
↩︎ Checkpoint