What you will be able to do
- Explain how a Cortex Agent answers questions that need both structured and unstructured data
- Describe how agent:run and threads keep conversation context across turns
- List the roles and runtime an application needs to call an agent
- Identify Snowflake Intelligence (Snowflake CoWork) as the ready-made chat experience and name the privileges on its account-level object
1.Cortex Agents: chat that orchestrates tools
A chat built directly on AI_COMPLETE can only use what you put in its prompt. A Cortex Agent can do more: it splits a request into subtasks, sends each one to a tool, checks the intermediate results, and then writes the answer. Snowflake runs the orchestration loop, runtime and sandbox for you. Data access is governed by your existing roles and privileges. For chat with data, the two key tools are Cortex Analyst for structured data and Cortex Search for unstructured data. How those services are built is covered in their own lessons. Here they matter only as tools the agent calls.
| Tool | What it contributes to an answer |
|---|---|
| Cortex Analyst | Generates SQL over structured data from natural language, using a semantic view |
| Cortex Search | Retrieves information from unstructured data, adjusting filters and result counts per query |
| Data to Chart | Generates visualizations from data returned by other tools |
| Custom tools | Stored procedures and UDFs for your own business logic |
| Web search | Real-time public internet information; must be enabled at the account level |
Building an agent takes five steps. You create the agent object (name, model, instructions), add tools, test it in the Snowsight playground, integrate it into your application, and then monitor and evaluate it. The integration step is the chat part. The application calls the agent:run REST API, and conversation context is kept in threads. This is the opposite of the COMPLETE pattern, where the client stores the history: here, threads keep context across turns with no state management on the client. To experiment before you create an agent object, you can call agent:run directly and send the agent configuration with every request.
Checkpoint 1 of 4· Put it in order
Put the Cortex Agents lifecycle steps in order
- 1.Add tools and the resources they need
- 2.Create an agent with its name, model and instructions
- 3.Test the agent in the Snowsight playground
- 4.Integrate it into your application through agent:run
- 5.Monitor, evaluate and iterate
The documentation describes a fixed five-step lifecycle. You define the agent, add tools, test, integrate through agent:run with threads, and then monitor and evaluate.
“Call the agent through the agent:run REST API, using threads to maintain conversation context.”Source: docs.snowflake.com
Sources1
2.Calling an agent from an app: roles, tokens and runtime
An agent needs more privileges than a plain AI function call. The caller's role needs the SNOWFLAKE.CORTEX_USER or SNOWFLAKE.CORTEX_AGENT_USER database role. It also needs privileges on the agent object and on every object the agent's tools use, such as semantic views, search services and warehouses. If the role lacks privileges on a tool, the request is rejected with a 4XX error. Session permissions come from the querying user's default role, and every request to the Cortex Agents API must include an authorization token. AI_FUNCTIONS_USER, which is enough for a simple AI_COMPLETE chat, does not give access to Cortex Agent.
The runtime matters too. Cortex Agents APIs cannot be called from a Streamlit in Snowflake app that uses a warehouse runtime. A SiS app that calls agents must use a container runtime instead. Cost is also more spread out than with a single function call. Orchestration is charged by tokens, Cortex Analyst per token, Cortex Search by index size and how long the index has existed, and custom tools by warehouse time. An orchestration budget on the agent limits what a single run can consume.
Checkpoint 2 of 4· Check yourself
A Streamlit in Snowflake app running on a warehouse runtime calls the Cortex Agents API and fails, even though the role has CORTEX_AGENT_USER and privileges on every tool. What fixes it?
The problem is the runtime, not the privileges. Agent APIs are not supported from SiS on a warehouse runtime, and the documented fix is a container runtime.
“To call Cortex Agents APIs from a SiS app, use a container runtime instead.”Source: docs.snowflake.com
Sources1
3.Snowflake Intelligence: the packaged chat-with-data experience
Some business units want chat with data for non-technical users without building or maintaining an app. Snowflake offers a ready-made agent experience for this. The exam calls it Snowflake Intelligence. The current documentation calls the product Snowflake CoWork, but its object and privilege still carry the old name: the default object is SNOWFLAKE_INTELLIGENCE_OBJECT_DEFAULT, and the privilege is CREATE SNOWFLAKE INTELLIGENCE. It is a ready-to-use agentic application. Users ask questions in natural language across structured and unstructured data, and data agents choose the tools, trace answers back to source data and queries, and build charts. It inherits Snowflake governance, including row access policies and column-level security.
The Snowflake Intelligence object is an account-level object that holds a list of agents. Administrators add or remove agents to give users a curated list. Snowsight creates the object automatically the first time someone changes the settings, and when created that way it is always named SNOWFLAKE_INTELLIGENCE_OBJECT_DEFAULT. You can also create it with SQL. CREATE SNOWFLAKE INTELLIGENCE on the account allows creating the object and is granted to ACCOUNTADMIN by default. USAGE on the object lets users view its list of agents and its configuration values. The retrieved documentation stops after USAGE, so this lesson cannot tell you which privilege lets a role change the object's agent list or settings. Check the access-control page for that.
CREATE SNOWFLAKE INTELLIGENCE SNOWFLAKE_INTELLIGENCE_OBJECT_DEFAULT;GRANT CREATE SNOWFLAKE INTELLIGENCE ON ACCOUNT TO ROLE <role_name>;Some features exist only in the packaged experience. User memory, for example, applies only to conversations in the app, not to direct calls through the Cortex Agent API. Deep Research splits an open-ended question into parallel sub-investigations and produces a cited report. Use the standard chat for quick lookups and follow-up questions.
Checkpoint 3 of 4· Match them up
Match each privilege or object to what it controls
Tap a term, then the definition that fits it.
The object is account-level and contains a curated list of agents. Creating it is a separate account privilege, held by ACCOUNTADMIN by default, and USAGE lets users see what the object contains.
“CREATE SNOWFLAKE INTELLIGENCE on the account: Privilege that allows creating a Snowflake CoWork object. This privilege is granted to ACCOUNTADMIN by default.”Source: docs.snowflake.com
Checkpoint 4 of 4· Exam question
A semantic model used by a chat-with-data app references a fact table that the calling role cannot query. Cortex Analyst returns generated SQL, but running it fails for the end user. What should be corrected?
Correct answer: C — Grant SELECT on the referenced fact table to the user's role
- A. Changing the file's ownership affects who can modify the semantic model definition, not whether the querying role can select from the underlying table at execution time.
- B. Swapping which Cortex role is granted changes access to the Analyst feature itself, but it does not grant table-level SELECT rights on the fact table.
- C. Cortex Analyst only writes the SQL; the calling role still needs its own SELECT privilege on every table the generated query touches, so this closes the gap directly.
- D. The model allowlist governs which LLMs a role can invoke, not which tables a role can query, so it has no effect on this failure.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.A Streamlit in Snowflake app can call the Cortex Agents API from any runtime, as long as the role has the right privileges.Why is that wrong?
Agent APIs are not supported from a SiS app on a warehouse runtime. Use a container runtime.
Covered in Calling an agent from an app: roles, tokens and runtime
2.The AI_FUNCTIONS_USER database role is enough to run an agent-based chat.Why is that wrong?
AI_FUNCTIONS_USER covers scalar AI functions only and excludes Cortex Agent. Calling an agent needs CORTEX_USER or CORTEX_AGENT_USER plus object privileges.
Covered in Calling an agent from an app: roles, tokens and runtime
3.Snowflake Intelligence user memory also carries over to applications that call the same agent through the Cortex Agent API.Why is that wrong?
User memory applies only inside the packaged app, not to direct API calls to agents.
Covered in Snowflake Intelligence: the packaged chat-with-data experience
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Minimal infrastructure: No orchestration loop, runtime, or sandbox to build or operate; Snowflake manages all of it.”
↩︎ Cortex Agents: chat that orchestrates tools“Stateful conversations: Threads that persist context across turns without client-side state management.”
↩︎ Cortex Agents: chat that orchestrates tools“you can call agent:run directly and pass the agent configuration with every request”
↩︎ Cortex Agents: chat that orchestrates tools“Generates SQL queries over your structured data from natural language, using a semantic view.”
↩︎ Cortex Agents: chat that orchestrates tools“Calling an agent requires the SNOWFLAKE.CORTEX_USER or SNOWFLAKE.CORTEX_AGENT_USER database role, privileges on the agent object”
↩︎ Calling an agent from an app: roles, tokens and runtime“Requests to the Cortex Agents API must include an authorization token.”
↩︎ Calling an agent from an app: roles, tokens and runtime“To limit what a single run consumes, set an orchestration budget on the agent.”
↩︎ Calling an agent from an app: roles, tokens and runtime“Cortex Agents APIs are not supported from within a Streamlit in Snowflake (SiS) application using a warehouse runtime.”
↩︎ Exam trap 1“Questions whose answers combine SQL results over semantic views with retrieval from documents and other unstructured sources.”
↩︎ Prediction“Call the agent through the agent:run REST API, using threads to maintain conversation context.”
↩︎ Checkpoint“To call Cortex Agents APIs from a SiS app, use a container runtime instead.”
↩︎ Checkpoint - 2.
“Snowflake CoWork is a ready-to-use agentic application with an intuitive, conversational interface that helps business users discover and act on deep insights.”
↩︎ Snowflake Intelligence: the packaged chat-with-data experience“Automatically inherits and respects all existing Snowflake data governance controls, including row-access policies and column-level security.”
↩︎ Snowflake Intelligence: the packaged chat-with-data experience“User memory applies only to interactions in Snowflake CoWork, not to direct calls to agents through the Cortex Agent API.”
↩︎ Exam trap 3 - 3.https://docs.snowflake.com/en/user-guide/snowflake-cortex/snowflake-cowork/deploy-agentsOfficial docs
“The Snowflake CoWork object is an account-level object that contains a list of agents.”
↩︎ Snowflake Intelligence: the packaged chat-with-data experience“When created using the UI, the Snowflake CoWork object is named SNOWFLAKE_INTELLIGENCE_OBJECT_DEFAULT.”
↩︎ Snowflake Intelligence: the packaged chat-with-data experience“Privilege that allows users to view the list of agents added to the Snowflake CoWork object and see configuration values.”
↩︎ Snowflake Intelligence: the packaged chat-with-data experience“CREATE SNOWFLAKE INTELLIGENCE on the account: Privilege that allows creating a Snowflake CoWork object. This privilege is granted to ACCOUNTADMIN by default.”
↩︎ Checkpoint
Also cited
“without granting access to Cortex services such as Cortex Agent, Cortex Analyst, Cortex Fine-tuning, or Cortex Search.”
↩︎ Exam trap 2