Blog

HR consultant reviewing recruitment metrics and candidate profiles on documents at minimalist desk

CloudHive is bringing together experts from across the Snowflake community to share hands-on experience, technical insights and different perspectives from the field. In this latest article in the series, Anastasiia Stefanska, Snowflake Data Superhero and Tech Lead at TUI looks at one of this year’s hottest topics: semantic views in Snowflake, and two different ways of creating them using Semantic View Autopilot and CoCo.<h2>Intro</h2>Welcome to the world of semantics, one of this year's hottest topics. In this article we explore two ways of creating semantic views in Snowflake. We'll explore the peculiarities of semantic view creation and look at common pitfalls you can avoid with each method. Let’s begin by having a quick refresher on the basics of this technology.<h2>What is a semantic view in Snowflake?</h2>Semantic views are schema-level objects within Snowflake which store business context of the structured data in Snowflake: table descriptions, relationships between tables, metric definitions, and more. Think of it as a way to capture and store subject-matter knowledge. The main function of semantic views is to feed knowledge to Cortex Analyst, enabling it to generate more precise, context-relevant text-to-SQL.<h2>Where can I build a Semantic View in Snowflake?</h2>I promised you two ways of creating a semantic view, here they are:<ol><li>Create the semantic view in the Snowsight UI using the Autopilot experience, a no-code option for users who prefer a visual interface.</li><li>Use the CoCo /semantic_studio skill&nbsp; to create the semantic view in a conversational manner.</li></ol><h2>How to build a Semantic View in Snowflake UI?</h2>Let's proceed with an example of creating a semantic view in Snowsight. For this setup, we are going to use a star-schema dataset with the data from Terry Pratchett’s Discworld universe:<ul><li>Table DIM_BOOKS: BOOK_ID, TITLE, PUBLICATION_YEAR, SUB_SERIES</li><li>Table DIM_CHARACTERS: CHARACTER_ID, CHARACTER_NAME, SPECIES, PRIMARY_AFFILIATION</li><li>Table FACT_APPEARANCES: BOOK_ID, CHARACTER_ID, ROLE</li></ul> To access the Semantic View Autopilot in Snowflake, in the left panel menu select AI &amp; ML → Analyst → Create with Autopilot. The window that opens has four steps. In the first step, you'll see an option to provide context from external sources: query history, a Tableau or Power BI file, or OSI specs. If the data is broadly used in the organization, do not skip this option - especially if there are metrics or calculated fields defined in those entities, as you will get a free conversion from the existing reports/queries into the Snowflake semantic view. If the data is relatively new and there is no existing context to draw on, skip this step.Semantic View Autopilot Step 1: provide context from external resourcesMoving to step 2, name your semantic view and define what type of entity it is. Among the legacy options, you can create or upload a semantic model's YAML file (previous versions of semantic models in Snowflake were defined with this format). It is not recommended to use the legacy YAML file option, as it could limit your options downstream. At least one limitation is known to date: the ability to use Cortex Analyst with the Snowflake MCP server is limited to semantic views, not semantic models.The first option is Snowflake semantic view - use it to avoid legacy limitationsSteps 3 and 4 allow you to choose the entities (tables, views) for the semantic view and columns within them. An important setting, recommended by Snowflake and selected by default, is to include sample values. Note, however, that it makes most sense for categorical items and you may remove the values manually later for the items where examples of values are less valuable.Another setting included by default is “Add descriptions” - these also apply to parent tables/views, and not only columns. Descriptions are AI-generated and derived from the data. My recommendation is to review and fine-tune them before releasing the view.Semantic view allows you to choose a subset of columns from the tables/viewsAt this point, your semantic view is technically ready. It likely contains the following entities:<ul><li>Dimensions, time dimensions - attributes of the entities.</li><li>Facts - a field that can be aggregated.</li></ul> Also, if you benefited from step 1 - adding external context, you might have these already pre-filled:<ul><li>Named filters - saved SQL to filter the data by.</li><li>Metrics - saved SQL aggregation on column(s) of the parent table.</li></ul> In reality, however, this is just a bare minimum carcass of the semantic view, and now the main exercise begins: filling it in with the business context. In addition to the above, here are the entities which must be added to the view before it can be released:<ul><li>Synonyms</li><li>Relationships</li><li>Model-level/derived metrics</li><li>Verified queries</li><li>Custom instructions.</li></ul>Let’s tackle these one by one!<h2>How to add synonyms to the semantic view?</h2> Synonyms allow Cortex Analyst to understand users' requests better. As the main goal of semantic views is to convert human questions into accurate SQL, it is critical to know how a typical user addresses the data.In our data model, users may address the DIM_BOOKS column of SUB_SERIES as simply “Series”<h2>How to add relationships to the semantic views?</h2> Relationships are the primary-foreign key dependencies between the view components. In our case, we would like to have 2 relationships between the fact and dim tables, so we code them as follows:Relationships allow 3 types of JOIN: EQUI, ASOF and RANGE&lt;aside&gt; &nbsp;💡Relationships are a critical and dangerous part of data modeling for semantic views. For complex models, Snowflake allows more than one relationship path between tables - this is called a multi-path. Having multi-paths creates ambiguity for physical joins which in turn prevents the calculation of the metrics which rely on these joins. This is because for every model-level metric that relies on a combination of tables, only one relationship path must exist. See the next section for an additional example.&lt;/aside&gt;<h2>How can I define SQL in my semantic view?</h2> One of the main challenges for human analysts in the enterprise is consistently converting business logic to SQL. We have all been in a situation where two reports from the same data show a different value for the same named metric - and both are considered correct by the teams who created them. The devil is in the detail SQL logic of the reports. Below are the sections in semantic views which are a mini SQL reference of a glossary of business definitions:<ul><li>Named filters - a way to define a WHERE clause for commonly filtered items. - WITCHES_SERIES: SUB_SERIES = 'Witches'</li><li>Table-level metric - a calculation derived from a column of a logical table. - TOTAL_BOOKS: COUNT(DISTINCT BOOK_ID) - TOTAL_CHARACTERS: COUNT(DISTINCT CHARACTER_ID)</li><li>Model-level metric - a calculation which is derived from multiple metrics. - TOTAL_DISCWORLD_ENTITIES: DIM_BOOKS.TOTAL_BOOKS + DIM_CHARACTERS.TOTAL_CHARACTERS</li></ul> &lt;aside&gt; &nbsp;💡There's a shortcut for defining a metric that spans multiple tables: referencing a second table in the table-level metric. For example, if we want to count total CAREER_SPAN_YEARS of a character, we could use MAX(DIM_BOOKS.PUBLICATION_YEAR) - MIN(DIM_BOOKS.PUBLICATION_YEAR) on a FACT_APPEARANCES table. It only works if a metric on a table references columns from tables that are reachable via a relationship from that table.Use this method with caution, as it will not work if multi-paths exist between the tables. In our testing, this method gives a warning in the UI, which proved to be a false-positive in queries.&lt;/aside&gt;<ul><li>Verified query - a complex question that a user can ask about the data. -Which characters appear in the most books:</li></ul>SELECT dc.CHARACTER_NAME, COUNT(DISTINCT fa.BOOK_ID) AS book_count FROM FACT_APPEARANCES AS fa INNER JOIN DIM_CHARACTERS AS dc ON fa.CHARACTER_ID = dc.CHARACTER_ID GROUP BY dc.CHARACTER_NAME ORDER BY book_count DESCWe highly recommend that a subject matter expert with SQL knowledge fill in and maintain all of the above fields. Without them, the text-to-SQL conversion will be an educated guessing game. Snowflake recommends not more than 20 verified queries per model to avoid performance degradation.<h2>What shall I add to the custom instructions of the semantic view?</h2>Custom instructions allow you to guide the style of the SQL generated by Cortex Analyst. For example, if you notice that your text fields are not filtered properly based on capitalization, you can instruct the Analyst to always wrap the text fields in the WHERE clause in the UPPER() function on both sides.Custom instruction to ensure case-insensitive matching<h2>How do I add Cortex Search to semantic view?</h2> If your use case needs to match strings by meaning rather than exact text, you can wrap a column with Cortex Search to ensure semantic search over it. This ensures fuzzy logic matching and reduces the number of empty results. The Cortex Search service on the column must pre-exist and cannot be created in the same flow.Adding Cortex Search over Species column<h2>In which order do I create a semantic view?</h2> In the process of adding context to the semantic view, you might run out of ideas for what to add next. The rule of thumb is to follow the flow:<ol><li>First validate all the AI-generated content (check descriptions, add/remove sample values).</li><li>Proceed with adding new structures (synonyms, relationships, metrics, etc).</li><li>Proceed to the Suggestions tab. </li></ol>The reason for this particular order is that the Suggestions tab relies on existing context, and you want to make sure it uses only validated content. Review and accept/edit/dismiss the suggestions after updating the basic entities of the semantic views<h2>How can I create a semantic view with CoCo?</h2> At this point, you should have a really good understanding of the components of the semantic view and the Semantic View Autopilot flow in the Snowsight UI. Now, let's switch gears and do a similar exercise with CoCo. Setting the scene, we are going to use the special skill /semantic_studio&nbsp; for this. Calling the skill in the UI allows us to select the option to “Work with Semantic Views”.Task selector in CoCo after calling the /semantic_studio skillThe flow is similar to the Autopilot one: define the source tables, name the semantic view and its location:Creation flow of the Semantic View in CoCoAs a result of this process, we arrive at the same point as after the four Autopilot steps. The next proposed stage is again similar - to fill in the extra context:CoCo suggests to add descriptions, relationships, VQRs (verifies queries) and audit the resulting viewThese steps can be completed conversationally, so for the sake of conciseness, I'll show one example of an interaction here:CoCo curated creation of a verified query based on the user requirementsUpon filling in those details, as a result of using either method, you'll have a working semantic view. So what is next? Are we done? Not quite. Let's test them first!<h2>CoCo unique feature - Semantic View Auditor</h2> Once the view has been created by either method, we can use CoCo to audit the semantic view against Snowflake's best practices. Use the same skill as before, but this time ask it to audit the view we created.Call the auditor using the /semantic_studio CoCo skillIn addition to calling the auditor, you can also point CoCo to a particular part of the semantic view, which requires an extra test:Checking all the metrics work for the semantic view we have created<h2>How to create the semantic view with SQL?</h2>This method stands apart from the first two, as you can see it is a pure code-based approach without any guidance or steps. Useful applications of this method from my experience are centered around deployment automation and version control. If you already have the initial version and would like to get the full SQL for it, run SELECT GET_DDL('SEMANTIC VIEW', 'full_view_name') to get code like this:CREATE OR REPLACE SEMANTIC VIEW DISCWORLD_ANALYTICS &nbsp; TABLES ( &nbsp; &nbsp; PRATCHETT_DB.DISCWORLD.DIM_BOOKS&nbsp; &nbsp; &nbsp; &nbsp; PRIMARY KEY (BOOK_ID)&nbsp; &nbsp; &nbsp; &nbsp; COMMENT = 'Represents individual Discworld novels.', &nbsp; &nbsp; PRATCHETT_DB.DISCWORLD.DIM_CHARACTERS&nbsp; &nbsp; &nbsp; &nbsp; PRIMARY KEY (CHARACTER_ID)&nbsp; &nbsp; &nbsp; &nbsp; COMMENT = 'Represents unique named characters in the Discworld series.', &nbsp; &nbsp; PRATCHETT_DB.DISCWORLD.FACT_APPEARANCES&nbsp; &nbsp; &nbsp; &nbsp; COMMENT = 'Records individual character appearances in books. Grain: one row per character per book.' &nbsp; ) &nbsp; RELATIONSHIPS ( &nbsp; &nbsp; FACT_APPEARANCES_TO_DIM_BOOKS AS FACT_APPEARANCES(BOOK_ID) REFERENCES DIM_BOOKS(BOOK_ID), &nbsp; &nbsp; FACT_APPEARANCES_TO_DIM_CHARACTERS AS FACT_APPEARANCES(CHARACTER_ID) REFERENCES DIM_CHARACTERS(CHARACTER_ID) &nbsp; ) &nbsp; FACTS ( &nbsp; &nbsp; DIM_BOOKS.WITCHES_SERIES LABELS = (filter) AS SUB_SERIES = 'Witches'&nbsp; &nbsp; &nbsp; &nbsp; WITH SYNONYMS = ('Lancre witches','Witches chronicles')&nbsp; &nbsp; &nbsp; &nbsp; COMMENT = 'Only show books which belong to the Witches series' &nbsp; ) &nbsp; DIMENSIONS ( &nbsp; &nbsp; DIM_BOOKS.BOOK_ID AS BOOK_ID, &nbsp; &nbsp; DIM_BOOKS.PUBLICATION_YEAR AS PUBLICATION_YEAR, &nbsp; &nbsp; DIM_BOOKS.SUB_SERIES AS SUB_SERIES, &nbsp; &nbsp; DIM_BOOKS.TITLE AS TITLE, &nbsp; &nbsp; DIM_CHARACTERS.CHARACTER_ID AS CHARACTER_ID, &nbsp; &nbsp; DIM_CHARACTERS.CHARACTER_NAME AS CHARACTER_NAME&nbsp; &nbsp; &nbsp; &nbsp; SAMPLE_VALUES ('Death','Sam Vimes','Granny Weatherwax','Vetinari','Rincewind',...), &nbsp; &nbsp; DIM_CHARACTERS.PRIMARY_AFFILIATION AS PRIMARY_AFFILIATION, &nbsp; &nbsp; DIM_CHARACTERS.SPECIES AS SPECIES, &nbsp; &nbsp; FACT_APPEARANCES.BOOK_ID AS BOOK_ID, &nbsp; &nbsp; FACT_APPEARANCES.CHARACTER_ID AS CHARACTER_ID, &nbsp; &nbsp; FACT_APPEARANCES.ROLE AS ROLE &nbsp; ) &nbsp; METRICS ( &nbsp; &nbsp; TOTAL_DISCWORLD_ENTITIES AS DIM_BOOKS.TOTAL_BOOKS + DIM_CHARACTERS.TOTAL_CHARACTERS, &nbsp; &nbsp; DIM_BOOKS.TOTAL_BOOKS AS COUNT(*), &nbsp; &nbsp; DIM_CHARACTERS.TOTAL_CHARACTERS AS COUNT(*), &nbsp; &nbsp; FACT_APPEARANCES.APPEARANCE_COUNT AS COUNT(*), &nbsp; &nbsp; FACT_APPEARANCES.CAREER_SPAN_YEARS AS MAX(DIM_BOOKS.PUBLICATION_YEAR) - MIN(DIM_BOOKS.PUBLICATION_YEAR), &nbsp; &nbsp; FACT_APPEARANCES.CHARACTER_SERIES_COUNT AS COUNT(DISTINCT DIM_BOOKS.SUB_SERIES), &nbsp; &nbsp; FACT_APPEARANCES.MAJOR_ROLE_COUNT AS SUM(CASE WHEN ROLE = 'Major' THEN 1 ELSE 0 END) &nbsp; ) &nbsp; COMMENT = 'Literary analytics for Terry Pratchett''s Discworld series.' &nbsp; AI_SQL_GENERATION 'When filtering on text columns, always wrap in UPPER() and capitalize the comparison string.' &nbsp; AI_VERIFIED_QUERIES ( &nbsp; &nbsp; "Which characters appear in the most books?" AS ( &nbsp; &nbsp; &nbsp; QUESTION 'Which characters appear in the most books?' &nbsp; &nbsp; &nbsp; SQL '...' &nbsp; &nbsp; ), &nbsp; &nbsp; "In which books outside of Wyrd Sisters does character Granny Weatherwax appear?" AS ( &nbsp; &nbsp; &nbsp; QUESTION '...' &nbsp; &nbsp; &nbsp; SQL '...' &nbsp; &nbsp; ), &nbsp; &nbsp; "Show all books for each character outside of their primary series" AS ( &nbsp; &nbsp; &nbsp; QUESTION '...' &nbsp; &nbsp; &nbsp; SQL '...' &nbsp; &nbsp; ) &nbsp; );<h2>How much do Semantic Views cost?</h2> Semantic views are considered metadata and as such are free. There is no storage cost and no compute cost for the semantic view itself. There are two ways you can incur costs with semantic views:Querying semantic views directly incurs standard warehouse costs. The main cost is associated with Cortex Analyst, which relies on semantic views. The standalone Analyst API bills 67 credits per 1,000 messages, while Cortex Analyst invoked through Cortex Agents uses token-based AI Credits instead. I cover both in detail in the previous article.<h2>Conclusions</h2> Semantic views encapsulate the value of the business context. Regardless of which method you choose for creating it, the real added value still comes from the subject matter input you provide. Both the Autopilot and CoCo flows create a carcass - a vessel which can be filled with the valuable knowledge of the experts. The human remains in control during creation, but even more so at the fine-tuning step. It is critical to treat these semantic view creation flows as helpers to transfer human knowledge, and not replace it. I would recommend starting with the Semantic View Autopilot and polishing it with the CoCo auditor and metrics validation.

Semantic View Creation Guide: Autopilot or CoCo, or both?

Diverse healthcare professionals and recruiters collaborating in modern glass office during career placement consultation meeting

<h2>Intro</h2>CloudHive is bringing together experts from across the Snowflake community to share hands-on experience, technical insights and different perspectives from the field.In the latest article in our practitioner series, we take a closer look at Cortex Agent in practice - where it works well, where it can fall short and what teams should understand before building it into real-world workflows.<a data-mce-href="https://cloudhive.ai/blog/snowflake-cowork-3-new-features-every-analyst-should-know" href="https://cloudhive.ai/blog/snowflake-cowork-3-new-features-every-analyst-should-know" target="_blank" rel="noopener" data-mce-selected="inline-boundary">In a previous article</a>, we looked at the wider Cortex portfolio, including Cortex Analyst and Cortex Search as two of the main building blocks behind Cortex Agent.The series brings together practitioners from across the Snowflake ecosystem to share practical perspectives on architecture, engineering and AI on the platform.<h2>What is Cortex Agent?</h2>Cortex Agent is a Snowflake-native platform for creating agents, integrated with its other components, so you don't have to worry about connecting the pieces together. Snowflake takes care of the infrastructure as well as the logic of the agent when it comes to the underlying orchestration loop, runtime, build, and operations. While Snowflake manages all of these, you remain in control of the agent settings such as orchestration instructions and response instructions, as well as tools, skills, model selection, and more. The goal of Cortex Agent is to give you a ready-to-use platform into which you can plug your agent logic and your structured and unstructured data, then work with the resulting agent as your analytical companion. I'm going to share five tips and tricks that worked for me when setting up Cortex Agents. Without further ado, let's go.<figure id="figure-h6u2ucw0fmsmxvric"><img id="h6u2ucw0fmsmxvric" src="https://cdn.durable.co/blocks/dUK2ptnzsSbbopkDFT1TEKFpGZIYNuCWC4tM1IZDVAqaN10tuxMtxU2y2dElr6lg.png" alt="Configuration page of Cortex Agent" title="Configuration page of Cortex Agent" class="object-cover bg-gray-100 rounded-2xl md:rounded-3xl lg:rounded-4xl" style="aspect-ratio: 1/1; object-position: center center;" data-corners="default" data-aspect="1:1" data-caption="Configuration page of Cortex Agent" data-positionx="undefined" data-positiony="undefined" data-fullwidth="false" data-mce-src="https://cdn.durable.co/blocks/dUK2ptnzsSbbopkDFT1TEKFpGZIYNuCWC4tM1IZDVAqaN10tuxMtxU2y2dElr6lg.png" data-mce-style="aspect-ratio: 1/1; object-position: center center;"><figcaption class="body-normal text-gray-500 mt-2">Configuration page of Cortex Agent</figcaption></figure><h2>How does Cortex Agent work?</h2>Before we begin, let’s look under the hood of the orchestration, because it will be important for the first few tips. It is important to differentiate this implicit orchestration layer from the explicit orchestration instructions (the similar naming can be confusing). Behind the scenes, a Cortex Agent runs on a loop with three steps.<ol><li>Planning: the agent interprets the question, splits it into parts, and chooses which tools to use.</li><li>Tool use: the agent applies the chosen tool to answer the question, or part of it. This can be Cortex Analyst, Cortex Search, a custom tool such as a UDF or stored procedure, a web search, an MCP server, or a skill.</li><li>Reflection: the agent reviews the results it got back and judges whether to retry or respond with what it has.</li></ol><h2>Tip 1: You can't control the loop directly, but you can rein it in</h2>This loop brings us to the first caveat and the first tip: the above three steps aren't something you can directly control. There's no setting in Snowflake that lets you, for example, set how many loops run within a single request.The best approach I've found is to limit the number of loops through the agent's orchestration instructions. The agent loop itself remains something of a black box, but this one plain-language instruction “do not use more than X loops to get the answer”, placed in the orchestration instructions, lets you cap how many tools the agent plans to use. If you want to reduce this further, the next tip will help even more.<h2>Tip 2: Limits you can actually set to control the agent</h2> Another way to control the agent's response is to set explicit limits. Within the Agent Budget Configuration setting, you can set two limits directly:● &nbsp; &nbsp; &nbsp;Time Limit (seconds)● &nbsp; &nbsp; &nbsp;Token Limit <figure id="figure-bl0pj0oyfdmsmxx6fy" class=""><img id="bl0pj0oyfdmsmxx6fy" src="https://cdn.durable.co/blocks/15mgb2gsFxmm0icBxyHOnOyWlkGrZ3DjorZG27t5izPQ4ypTxDJ6EWU5BAwfTR5z.png" alt="Default recommended settings for Time and Token Limits in Cortex Agent" title="Default recommended settings for Time and Token Limits in Cortex Agent" class="object-cover bg-gray-100 rounded-2xl md:rounded-3xl lg:rounded-4xl" style="aspect-ratio: 16/9; object-position: center center;" data-corners="default" data-aspect="16:9" data-caption="Default recommended settings for Time and Token Limits in Cortex Agent" data-positionx="null" data-positiony="null" data-fullwidth="false" data-mce-src="https://cdn.durable.co/blocks/15mgb2gsFxmm0icBxyHOnOyWlkGrZ3DjorZG27t5izPQ4ypTxDJ6EWU5BAwfTR5z.png" data-mce-style="aspect-ratio: 16/9; object-position: center center;"><figcaption class="body-normal text-gray-500 mt-2">Default recommended settings for Time and Token Limits in Cortex Agent</figcaption></figure>Both limits apply on a per-response basis. Snowflake recommends at least 5 minutes as a default for best results, but depending on the complexity of your agent, simpler workflows may work fine with a lower limit. In my tests, however, setting the time limit to the minimum value of 1 second does not cause the agent to generate a response immediately, but it does significantly speed things up. My assumption from observing the behavior change is that the agent has a minimum thinking path it goes through, which reduces to a relatively naive approach with the strict limit. But in simple workflows it can be rather useful, so I encourage you to experiment with it.Also worth noting: token limits are only applicable at the orchestration level and do not include tool tokens. Similarly, in my tests, setting a token limit to the minimum value makes the agent invoke all steps explicitly and output all results of its thought process instead of conducting internal orchestration. In both cases, setting the parameter to a higher value results in longer but deeper thinking.<h2>Tip 3: Tell the agent explicitly which tool to use for which task</h2>Probably the most universal tip in this article: what can you do to improve the accuracy of the agent's response? An AI is only as good as the data feeding it, of course, but improving the data itself is a separate conversation we won't get into here.What's worth continuing to iterate on are the instructions you give the agent, specifically the orchestration instructions, which control how the agent selects tools and what sequence of actions it takes. The goal of these instructions is to make sure the agent knows which tool is right for which task.Say you have an agent that handles both structured and unstructured data. You want Cortex Analyst selected for structured-data questions and Cortex Search selected for unstructured-data questions, based on the type of question asked. You can teach the agent to predict which tool to use by writing this explicitly into the orchestration instructions, so it doesn't spend effort guessing which tool is most useful each time.&lt;aside&gt; &nbsp;💡As a rule of thumb: questions with a qualitative component should be answered by Cortex Search (for example, "What is our return policy?" or "How do we handle returns?"). Questions with a quantitative element, such as "How many returns did we have last quarter?", are better suited to Cortex Analyst.&lt;/aside&gt;Don't be shy about making this explicit in your agent's instructions. Include example questions and word markers that identify tools (“Sales” → Analyst, “Policy” → Search, etc.). Routing questions to the right tool is the single most useful thing you can put in your orchestration instructions: it reduces the time the agent spends selecting a tool and increases the accuracy of its behavior.<figure id="figure-zn9aztlgepmsmxz5y9"><img id="zn9aztlgepmsmxz5y9" src="https://cdn.durable.co/blocks/13Z6xoFvld0Bnax9kMqsP9bR1vbqDTeqHFYgU61DpFWmwA1K6tZrkAWyKCLzwHcM.png" alt="Orchestration instructions snippet for tool selection" title="Orchestration instructions snippet for tool selection" class="object-cover bg-gray-100 rounded-2xl md:rounded-3xl lg:rounded-4xl" style="aspect-ratio: 16/9; object-position: center center;" data-corners="default" data-aspect="16:9" data-caption="Orchestration instructions snippet for tool selection" data-positionx="undefined" data-positiony="undefined" data-fullwidth="false" data-mce-src="https://cdn.durable.co/blocks/13Z6xoFvld0Bnax9kMqsP9bR1vbqDTeqHFYgU61DpFWmwA1K6tZrkAWyKCLzwHcM.png" data-mce-style="aspect-ratio: 16/9; object-position: center center;"><figcaption class="body-normal text-gray-500 mt-2">Orchestration instructions snippet for tool selection</figcaption></figure><h2>Tip 4: Cut to the point and kill the kindness</h2>It might sound brutal, but the best thing you can teach your agent to do is to say “No.” In the world of LLM sycophancy, it is not a given that an agent can admit its own limits. If there's one thing worth putting in your response instructions, it's this: let the agent be explicit, and push back against the model's default tendency toward sycophancy. That's the headline example. More broadly, one of the most important things is to set the scope of questions the agent can and cannot answer, as well as explicitly include the boundaries for topics and actions it can assist with. Snowflake's own recommendation is to prefix all boundaries with the word “never” to exclude probabilistic interpretation of them and enforce the deterministic approach. So, if your agent is set up to work on datasets and provide insights about the data, some of the response instructions can be:● &nbsp; &nbsp; &nbsp;Never offer to draft an email to the customer● &nbsp; &nbsp; &nbsp;Never forecast sales data● &nbsp; &nbsp; &nbsp;Never invent data, always use only existing data● &nbsp; &nbsp; &nbsp;Never predict deal outcomes based on the dataAs a second part of this tip, I would recommend setting up a template for both the response format and contents, which would ensure repeatable behavior from the agent and reduce non-deterministic output. It is a general best practice to lead with a direct, short answer, and later expand with the details. In terms of formatting, I recommend you stick to your company's reporting guidelines. Don't forget citations: ask the agent to include references to all data, as this greatly increases trust (and reduces the risk of it inventing answers). One last word: since we all know LLMs are big fans of emojis, if you plan to have any, I recommend including them explicitly in the instructions, as this creates a recognizable pattern with repeated use.<figure id="figure-ulc6dtqzsmsmxzr1d"><img id="ulc6dtqzsmsmxzr1d" src="https://cdn.durable.co/blocks/11yUSpLBFJrXJEmohJMb2rI2u54BQJ1pTY7LOyIct9ibWjrGlM4k1NISpLmjLO64.png" alt="My demo Sales Agent getting emoji in the response instructions" title="My demo Sales Agent getting emoji in the response instructions" class="object-cover bg-gray-100 rounded-2xl md:rounded-3xl lg:rounded-4xl" style="aspect-ratio: 16/9; object-position: center center;" data-corners="default" data-aspect="16:9" data-caption="My demo Sales Agent getting emoji in the response instructions" data-positionx="undefined" data-positiony="undefined" data-fullwidth="false" data-mce-src="https://cdn.durable.co/blocks/11yUSpLBFJrXJEmohJMb2rI2u54BQJ1pTY7LOyIct9ibWjrGlM4k1NISpLmjLO64.png" data-mce-style="aspect-ratio: 16/9; object-position: center center;"><figcaption class="body-normal text-gray-500 mt-2">My demo Sales Agent getting emoji in the response instructions</figcaption></figure><h2>Tip 5: Determinism vs. Highest Quality Outcome</h2>This one was not obvious to me: when I started building Cortex Agents, it was generally recommended to pin the orchestration model of the agent to increase reproducibility. Yet, for some time now, Snowflake's official documentation has recommended selecting the “auto” model in production agents to achieve the best quality of answers. Some of the other Snowflake resources reference pinning the model for agents’ evaluations, which, if you think about it, makes a lot of sense. A word of caution: if the pinned model becomes unavailable (deprecated in Snowflake), Cortex Agent will start failing. And of course, if your model is set to “auto,” the cost of tokens will be subject to Snowflake's selection.<figure id="figure-bndt01of3msmy275o"><img id="bndt01of3msmy275o" src="https://cdn.durable.co/blocks/fBLGBGhTgCKblQEkjZL7taq8yjkztS80uNP5dbBOoP826URewNMdjWnkvjNZKKgu.png" alt="Model selection dropdown in the Cortex Agent Configuration setting" title="Model selection dropdown in the Cortex Agent Configuration setting" class="object-cover bg-gray-100 rounded-2xl md:rounded-3xl lg:rounded-4xl" style="aspect-ratio: 16/9; object-position: center center;" data-corners="default" data-aspect="16:9" data-caption="Model selection dropdown in the Cortex Agent Configuration setting" data-positionx="undefined" data-positiony="undefined" data-fullwidth="false" data-mce-src="https://cdn.durable.co/blocks/fBLGBGhTgCKblQEkjZL7taq8yjkztS80uNP5dbBOoP826URewNMdjWnkvjNZKKgu.png" data-mce-style="aspect-ratio: 16/9; object-position: center center;"><figcaption class="body-normal text-gray-500 mt-2">Model selection dropdown in the Cortex Agent Configuration setting</figcaption></figure><h2>Bonus: How to monitor the costs of Cortex Agent?</h2>Cortex Agent incurs costs on multiple levels: orchestration of the agent itself is charged per million tokens according to the consumption table. But bear in mind that each tool of the agent will incur its own costs. I prepared an example cost breakdown in an earlier article. Now let's look at cost control. Since Cortex Agent is a shared resource, it can be monitored using a shared resource budget:CALL AGENT_DEMO_DB.DEMO.AGENT_BUDGET!ADD_SHARED_RESOURCE('CORTEX AGENT',(SELECT SYSTEM$REFERENCE('CORTEX AGENT', 'AGENT_DEMO_DB.DEMO.SALES_ASSISTANT')));The mechanics of the shared resource budget have been reviewed in detail in my previous article about Snowflake CoWork.<h2>Conclusions</h2>Cortex Agents offer a flexible approach to setting up and maintaining serverless AI services in Snowflake. With default RBAC and Snowflake-native access to all the data and other Cortex services, it is the most intuitive way to bring your data under the AI umbrella. I hope these tips and tricks help you turn your agent from just good to great, and reduce the iterations you'll spend on settings, since I've already gone through them for you.

Make No Mistake: What Works and What Does Not in Cortex Agent

Three diverse professionals reviewing job postings on tablet during collaborative hiring discussion

CloudHive is bringing together experts from across the Snowflake community to share hands-on experience, technical insights and different perspectives from the field. In this latest article in the series, Dan Greenberg, Snowflake Data Platform Owner at Verisk, looks at an important change in Snowflake’s 2026_06 Behavior Change Bundle and what it means for organizations using transient tables as part of their backup strategy.Snowflake’s upcoming 2026_06 Behavior Change Bundle includes a feature change that every organization using Snowflake Backups should be aware of:&nbsp;Transient tables including transient dynamic tables will no longer be supported by Snowflake Backups.&nbsp;I understand Snowflake’s reasoning. Transient tables are intended for transitory or reproducible data that does not require the same recovery protections as permanent tables. However, this change could have serious consequences for organizations that currently include transient tables in long-term or immutable backup strategies.&nbsp;The goal of this article is not to criticize the change. It is to make sure Snowflake customers are aware of it, understand the impact, and are prepared before it takes effect.&nbsp;Before the change, transient tables could be backed up individually or included in a schema- or database-level backup. After the change:&nbsp;<ul><li>Creating a backup set directly against a transient table will fail with an error.</li><li>&nbsp;Existing table-level backup sets targeting transient tables will fail when attempting to add another backup.&nbsp;</li><li>Most concerning, a schema &nbsp;or database level backup will still succeed but Snowflake will silently exclude all transient tables.&nbsp;</li></ul>Those excluded tables will not be available during a restore because they were never captured. Existing backups that already contain transient tables are unaffected and can still be restored.&nbsp;<h2>What is a transient table?&nbsp;</h2> A transient table behaves much like a permanent Snowflake table: it persists across sessions, remains available until explicitly dropped, and can be accessed by other authorized users.&nbsp;The key difference is data protection.&nbsp;Transient tables:&nbsp;<ul><li>Have a maximum Time Travel retention period of one day.&nbsp;</li><li>Do not receive Snowflake’s seven-day Fail-safe protection.&nbsp;</li><li>Typically cost less to maintain because they do not incur Fail-safe storage costs.&nbsp;</li><li>Are best suited for staging data, intermediate transformations, ETL work tables, caches, and other data that can be independently reproduced.&nbsp;</li></ul>That last point is critical: transient tables should generally contain data that can be recreated without relying on Snowflake recovery. &nbsp;&nbsp;“Transient” and “must be backed up” are not mutually exclusive.&nbsp;It is tempting to assume that if a table was created as transient, its data cannot have a business, legal, or regulatory retention requirement.&nbsp;In the real world, that is not always true.&nbsp;A table may have originally been made transient to reduce Fail-safe storage costs. Years later, it may contain data needed for an audit, litigation, regulatory recordkeeping, historical analysis, or cyber-recovery. Business requirements change, applications evolve, and tables often live much longer than their original designers expected. The decision to avoid Fail-safe is not necessarily the same as the decision to exclude data from an immutable, long-term backup.&nbsp; Organizations should therefore rethink their use of transient tables. If there is any reasonable possibility that the data will need to be backed up, restored, audited, or retained for several years, a permanent table may be the safer design.&nbsp;The conversion is not painless&nbsp;Unfortunately, there is no simple command such as:&nbsp; ALTER TABLE my_table SET PERMANENT&nbsp;Snowflake does not allow the transient property to be changed after a table is created. Converting a transient table to a permanent table requires creating a new permanent table, copying the data, preserving grants and metadata, validating dependent objects, and then renaming or replacing the original table.&nbsp;At enterprise scale, this can become a significant migration effort.&nbsp;There is also a real cost tradeoff. Permanent tables receive a seven-day Fail-safe period, and the historical data maintained during that period incurs additional storage charges. Organizations that adopted transient tables to control storage costs must balance those new Fail-safe costs against their backup and retention requirements.&nbsp;<h2>Why this feature change deserves immediate attention&nbsp;</h2> Many large Snowflake environments have backup scopes containing tens of thousands of transient tables.&nbsp;Imagine discovering several years from now during an audit, investigation, legal request, or regulatory inquiry that required historical data is unavailable because those tables stopped being included in backups.&nbsp;<ul><li>The backup jobs continued to report success.&nbsp;</li><li>No database or schema level backup failed.&nbsp;</li><li>No warning clearly identified the missing tables.&nbsp;</li><li>The data simply was not captured.&nbsp;</li></ul>That would be a catastrophe and it is exactly the type of risk that can arise when a seemingly small feature change is missed.&nbsp;Make sure you are ready&nbsp;Before the 2026_06 bundle becomes enabled by default:&nbsp;<ol><li>Inventory all transient and transient dynamic tables within existing backup scopes.</li><li>Identify tables subject to business, legal, regulatory, audit, or cyber-recovery requirements.</li><li>Confirm that supposedly reproducible data can actually be regenerated within an acceptable timeframe.</li><li>Convert tables requiring long-term backups to permanent tables.</li><li>Estimate the resulting Fail-safe storage costs before migrating at scale.</li><li>Enable and test the behavior change bundle in a non-production account.</li><li>Add monitoring that compares expected backup objects with the objects actually captured.&nbsp; </li></ol>Again, I understand why Snowflake is making this change. Transient tables were designed for data that does not need permanent-table recovery protections.&nbsp;Just make sure your organization is aware of the change and ready for it.&nbsp; Table type is no longer only a storage-cost decision. It is also part of your backup, recovery, and compliance architecture.&nbsp;Snowflake documentation: <a data-mce-href="https://docs.snowflake.com/en/release-notes/bcr-bundles/2026_06/bcr-2360" href="https://docs.snowflake.com/en/release-notes/bcr-bundles/2026_06/bcr-2360" target="_blank" rel="noopener">2026_06 backup behavior change</a> | <a data-mce-href="https://docs.snowflake.com/en/user-guide/tables-temp-transient" href="https://docs.snowflake.com/en/user-guide/tables-temp-transient" target="_blank" rel="noopener">Transient tables</a> <a data-mce-href="https://docs.snowflake.com/en/user-guide/backups" href="https://docs.snowflake.com/en/user-guide/backups" target="_blank" rel="noopener">| Backups and immutable storage&nbsp;</a><h3>Talk to CloudHive&nbsp;</h3>Reviewing your Snowflake backup strategy or assessing how the 2026_06 feature change could affect your environment? CloudHive works with organisations across Snowflake architecture, data protection and platform governance to help identify risks and prepare for changes before they reach production.&nbsp;If you’d like to discuss your backup scopes, transient table strategy or a related topic you would like us to cover in a future article, <a data-mce-href="https://cloudhive.ai/contact" href="https://cloudhive.ai/contact" target="_blank" rel="noopener">get in touch.&nbsp;</a>

Snowflake’s 2026_06 Feature Change: Transient Tables Will Be Excluded from Backups

Modern consulting office with diverse professionals working on HR strategy, technology dashboards, and collaborative planning at various workstations

<h2>Intro</h2>CloudHive is bringing together experts from across the Snowflake community to share hands-on experience, technical insights and different perspectives from the field.In this latest article in the series, I’m taking a closer look at Snowflake CoWork and three features I think analysts should know about. In a <a data-mce-href="https://cloudhive.ai/blog/getting-started-with-snowflake-cortex" href="https://cloudhive.ai/blog/getting-started-with-snowflake-cortex" data-mce-selected="inline-boundary" target="_blank" rel="noopener">previous article</a>, I covered the wider Cortex portfolio, including Cortex Agent and the tools that sit behind it.&nbsp;CoWork, previously known as Snowflake Intelligence, can look like little more than a wrapper around Cortex Agent. In practice, there are a few features that make it worth treating as a product in its own right, particularly for analysts working directly in Snowflake.<h2>What is Snowflake CoWork?</h2> Snowflake CoWork started as an interface for conversational interactions with Snowflake data. If you’ve been on this ride for a while, you can probably recall its previous name: Snowflake Intelligence. The primary benefit for a long time has been a simple ChatGPT-like UI with access to Cortex Agents to generate insights on datasets connected through semantic search and text2SQL. With the development of the agents’ capabilities beyond producing SQL code and searching/summarizing text, CoWork evolved into a platform with a deep understanding of the data, as well as the extra ability to act on it. The current list of its features is juicy: skills, plugins and custom tools, extended thinking and more. So today, I pick my three favorite features as an analyst persona.<h2>What is Snowflake CoWork Deep Research?</h2> If I had to choose only one feature every analyst should try in Snowflake CoWork, it would be Deep Research. Deep Research is the ultimate helper for answering the why about your data. Don’t take my word for it; you should really try it. Throw a complex, non-trivial question about your data at CoWork and activate this feature behind the + icon in the message bar.<figure id="figure-lx0tds3f4cmrt99161" class=""><img id="lx0tds3f4cmrt99161" src="https://cdn.durable.co/blocks/0ADuFmHF5DyFihyitwowgQ2ltJTOkp7QyM6m76g7QtnA5W6SZEC3SGee4qLTISAv.png" alt="" title="" class="object-cover bg-gray-100 rounded-2xl md:rounded-3xl lg:rounded-4xl" style="aspect-ratio: 16/9; object-position: center center;" data-corners="default" data-aspect="16:9" data-caption="" data-positionx="undefined" data-positiony="undefined" data-fullwidth="false" data-mce-src="https://cdn.durable.co/blocks/0ADuFmHF5DyFihyitwowgQ2ltJTOkp7QyM6m76g7QtnA5W6SZEC3SGee4qLTISAv.png" data-mce-style="aspect-ratio: 16/9; object-position: center center;"></figure>Activate Deep Research Mode in Snowflake CoWork to investigate complex topicsBehind the scenes, Deep Research will decompose your question into a set of atomic questions it needs to answer and run these investigations in parallel using sub-agents. These questions can be answered by your structured or unstructured data, as well as external context. In the end, the results are combined into a single report with citations and references provided.<figure id="figure-t3qazve2ymrt9bpg5"><img id="t3qazve2ymrt9bpg5" src="https://cdn.durable.co/blocks/16NmQubnub8PK8ms1qXwQcDPWttmTEPYTVnWfJ1bVaBRFNvYeYmzuiW2phjKCHQz.png" alt="" title="" class="object-cover bg-gray-100 rounded-2xl md:rounded-3xl lg:rounded-4xl" style="aspect-ratio: 16/9; object-position: center center;" data-corners="default" data-aspect="16:9" data-caption="" data-positionx="undefined" data-positiony="undefined" data-fullwidth="false" data-mce-src="https://cdn.durable.co/blocks/16NmQubnub8PK8ms1qXwQcDPWttmTEPYTVnWfJ1bVaBRFNvYeYmzuiW2phjKCHQz.png" data-mce-style="aspect-ratio: 16/9; object-position: center center;"></figure>Deep Research spun two sub-agents to address a question from multiple anglesAs a starting point, such reports can support the broader research done by an analyst. Not only do they supply ample food for thought for curious minds, but they also offer extra options for further discovery. Among those options is our next hero of this article: Visualizations.<h2>How do Visualizations work in Snowflake CoWork?</h2> If you work with Snowflake CoWork, chances are high that a SQL query will fire to answer some of your questions. Based on the query type, CoWork determines whether the result can be shown as a chart and presents it in the output section. It supports most Vega-Lite chart types: bar, line, pie and scatter, plus area charts, heatmaps, box plots, dual-axis and layered charts, faceted small-multiples, error bars and text annotations. Geographic maps are the notable exception. CoWork defaults to the most likely candidate for an effective visualization. Each viz comes with an option to download it as a .png file, or the underlying table as .csv or .tsv.<figure id="figure-bt30qhd6momrt9c5wp" class=""><img id="bt30qhd6momrt9c5wp" src="https://cdn.durable.co/blocks/2dzOlhnUKkpnc7LhXPzU43Vy4QMD4Fj0tJVOpWjN9YipptU9Ntv4kYfxRnlR5mIj.png" alt="" title="" class="object-cover bg-gray-100 rounded-2xl md:rounded-3xl lg:rounded-4xl" style="aspect-ratio: 16/9; object-position: center center;" data-corners="default" data-aspect="16:9" data-caption="" data-positionx="undefined" data-positiony="undefined" data-fullwidth="false" data-mce-src="https://cdn.durable.co/blocks/2dzOlhnUKkpnc7LhXPzU43Vy4QMD4Fj0tJVOpWjN9YipptU9Ntv4kYfxRnlR5mIj.png" data-mce-style="aspect-ratio: 16/9; object-position: center center;"></figure>In-built visualization in the Deep Research output report supports the main story of the findingsBut what if I told you this is not even the best part? You can edit the chart inside the conversation, customize the type, change the axes, labels, calculations and colors. All within the same window of the CoWork UI! This feature is available for bar, line, pie, and scatter charts. For the other types of charts, simply ask Snowflake CoWork and it will edit the chart for you. And there is more to come: the ability to define customizations at the agent or semantic view level is in Preview at the moment of writing this article. With it, you can set the defaults for colors, formatting and fonts according to your preferences or brand guidelines. Moreover, another feature called “Visualization policies” lets you define conditional chart rules and is also in Preview. These previews set the direction for this area, and the analytical crowd that thrives on visuals has plenty to look forward to.<figure id="figure-zoq4w9gmsmrt9g2wq"><img id="zoq4w9gmsmrt9g2wq" src="https://cdn.durable.co/blocks/35RTTUpKyVzDUq2p23p3oYjTaoTccwAwwltqouo482gvyquFiXKj5zNakksvWJvp.png" alt="" title="" class="object-cover bg-gray-100 rounded-2xl md:rounded-3xl lg:rounded-4xl" style="aspect-ratio: 16/9; object-position: center center;" data-corners="default" data-aspect="16:9" data-caption="" data-positionx="undefined" data-positiony="undefined" data-fullwidth="false" data-mce-src="https://cdn.durable.co/blocks/35RTTUpKyVzDUq2p23p3oYjTaoTccwAwwltqouo482gvyquFiXKj5zNakksvWJvp.png" data-mce-style="aspect-ratio: 16/9; object-position: center center;"></figure>Customization options of the viz are available directly in the Snowflake CoWork UIAnd with this, I am sure you can imagine a day, coming sooner rather than later, when Deep Research reports or elements of CoWork chats, such as visualizations and tables, are shared across the organization as standalone entities, not just screenshots and printouts. What would you say if I told you that CoWork already has you covered? Enter stage: Artifacts.<h2>What are Snowflake CoWork Artifacts?</h2>Artifacts are persistent, live references to a chart or a table, aka no more screenshots and copy-pasting static data. Artifacts let you save the entities produced during Snowflake CoWork interactions and share them across your organization. But if you ask me, the best part is this: they are refreshable and follow the RBAC of the recipient. So unlike screenshots or exports, there is no risk of accidentally sharing sensitive data, and the data never leaves the Snowflake RBAC perimeter.<figure id="figure-e61xviq1t4mrt9emna"><img id="e61xviq1t4mrt9emna" src="https://cdn.durable.co/blocks/33uuSJxosOkCx4q38DNjh14VTH6bhDIK9ZYuFqIMWoEsChzfj6fvDCm3IujlAzys.png" alt="" title="" class="object-cover bg-gray-100 rounded-2xl md:rounded-3xl lg:rounded-4xl" style="aspect-ratio: 16/9; object-position: center center;" data-corners="default" data-aspect="16:9" data-caption="" data-positionx="null" data-positiony="null" data-fullwidth="false" data-mce-src="https://cdn.durable.co/blocks/33uuSJxosOkCx4q38DNjh14VTH6bhDIK9ZYuFqIMWoEsChzfj6fvDCm3IujlAzys.png" data-mce-style="aspect-ratio: 16/9; object-position: center center;"></figure>Currently supported artifacts include visualizations and tablesOne of my favorite features as an analyst is the option to refresh the data in the artifacts. This opens up a whole range of future use cases! Looking at Snowflake’s list of known limitations for artifacts, organizing items into folders and collections is not currently possible, but I’ve got my eyes on this one.<h2>How much does Snowflake CoWork cost?</h2> Snowflake CoWork is billed on an AI Credits basis per million tokens. For example, for Claude Sonnet 5 at the moment of writing this article, the Credit Consumption table quotes 1.30 AI Credits for input, 6.50 AI Credits for output, and an additional 1.625 AI Credits for cache write and 0.13 AI Credits for cache read. In addition to the agent itself, the underlying services and tools are included in the billing, which in turn may incur warehouse and storage costs. For the details of the costs for many tools from the Cortex suite, I recommend my previous article. The details are available in the SNOWFLAKE_INTELLIGENCE_USAGE_HISTORY view, which kept the old Snowflake Intelligence name through the rebrand. Or, for the CoCo fans out there, invoke the /cost-intelligence skill and enjoy!<figure id="figure-cp34bepdcgmrt9grx1"><img id="cp34bepdcgmrt9grx1" src="https://cdn.durable.co/blocks/2fVYeEQez0ZESI8Poia2NJc65XXnLTZXhJT0adDpfLn0iQUbgJjvmEYsoJs0oS1k.png" alt="" title="" class="object-cover bg-gray-100 rounded-2xl md:rounded-3xl lg:rounded-4xl" style="aspect-ratio: 16/9; object-position: center center;" data-corners="default" data-aspect="16:9" data-caption="" data-positionx="undefined" data-positiony="undefined" data-fullwidth="false" data-mce-src="https://cdn.durable.co/blocks/2fVYeEQez0ZESI8Poia2NJc65XXnLTZXhJT0adDpfLn0iQUbgJjvmEYsoJs0oS1k.png" data-mce-style="aspect-ratio: 16/9; object-position: center center;"></figure>CoCo is displaying the result of the cost breakdown for the CoWork demo agent<h2>How can I control Snowflake CoWork costs?</h2>A great option to control the Snowflake CoWork cost is to set up a resource budget at the account level, or a shared resource budget on a subset of users. Both methods use a tag-based approach: in the resource budget scenario, tags are applied to the CoWork object itself, while in the shared resource budget scenario the tags are applied to the users.Below is an example of setting up a resource budget. First, create a tag for tracking the budget:CREATE TAG IF NOT EXISTS COWORK_COST_CENTER &nbsp; ALLOWED_VALUES 'org-level' &nbsp; COMMENT = 'Tag for CoWork budget tracking'; &nbsp;Next, make sure the CoWork object is created in your account:CREATE SNOWFLAKE INTELLIGENCE SNOWFLAKE_INTELLIGENCE_OBJECT_DEFAULT; SHOW SNOWFLAKE INTELLIGENCES;After that, apply the tag to the CoWork object:ALTER SNOWFLAKE INTELLIGENCE SNOWFLAKE_INTELLIGENCE_OBJECT_DEFAULT SET TAG COWORK_COST_CENTER = 'org-level';Then, create a budget and attach the tag as its scope:CREATE SNOWFLAKE.CORE.BUDGET COWORK_BUDGET();CALL COWORK_BUDGET!SET_SPENDING_LIMIT(10);CALL COWORK_BUDGET!SET_RESOURCE_TAGS( &nbsp; [ &nbsp; &nbsp; [(SELECT SYSTEM$REFERENCE('TAG', &nbsp; &nbsp; &nbsp; &nbsp; 'AGENT_DEMO_DB.DEMO.COWORK_COST_CENTER', &nbsp; &nbsp; &nbsp; &nbsp; 'SESSION', &nbsp; &nbsp; &nbsp; &nbsp; 'applybudget')), &nbsp; &nbsp; &nbsp; &nbsp; 'org-level'] &nbsp; ], &nbsp; 'UNION');CALL COWORK_BUDGET!SET_NOTIFICATION_THRESHOLD(80);If you wish to revoke access to CoWork when the spending limit is reached, add a CUSTOM_ACTION:CREATE OR REPLACE PROCEDURE AGENT_DEMO_DB.DEMO.SP_REVOKE_SI_ACCESS( SI_NAME STRING, ROLE_NAME STRING ) RETURNS STRING LANGUAGE SQL AS BEGIN EXECUTE IMMEDIATE 'REVOKE ROLE SI_' || SI_NAME || '_ROLE FROM ROLE ' || ROLE_NAME; RETURN 'Access revoked for ' || SI_NAME; END;CALL COWORK_BUDGET!ADD_CUSTOM_ACTION( &nbsp; &nbsp;SYSTEM$REFERENCE('PROCEDURE', &nbsp; &nbsp; &nbsp;'AGENT_DEMO_DB.DEMO.SP_REVOKE_SI_ACCESS(STRING, STRING)'), &nbsp; &nbsp;ARRAY_CONSTRUCT('SNOWFLAKE_INTELLIGENCE_OBJECT_DEFAULT', 'ROLE_NAME'), &nbsp; &nbsp;'ACTUAL', &nbsp; &nbsp;100);Similarly, to reinstate access at the start of the next budget cycle, add another CUSTOM_ACTION:CREATE OR REPLACE PROCEDURE AGENT_DEMO_DB.DEMO.SP_REINSTATE_SI_ACCESS( SI_NAME STRING, ROLE_NAME STRING ) RETURNS STRING LANGUAGE SQL AS BEGIN EXECUTE IMMEDIATE 'GRANT ROLE SI_' || SI_NAME || '_ROLE TO ROLE ' || ROLE_NAME; RETURN 'Access reinstated for ' || SI_NAME; END;GRANT USAGE ON PROCEDURE AGENT_DEMO_DB.DEMO.SP_REINSTATE_SI_ACCESS(STRING, STRING) TO APPLICATION SNOWFLAKE;CALL COWORK_BUDGET!SET_CYCLE_START_ACTION( SYSTEM$REFERENCE('PROCEDURE', 'AGENT_DEMO_DB.DEMO.SP_REINSTATE_SI_ACCESS(STRING, STRING)'), ARRAY_CONSTRUCT('SNOWFLAKE_INTELLIGENCE_OBJECT_DEFAULT', 'ROLE_NAME') );<img id="xhyr2pxvogmrtdfb75" src="https://cdn.durable.co/blocks/fDPvHG40GzHB9Np8bXqJiSWlTWArEQSherLdc4wt7SGlWTYLi1XEJJIwjUPjwKo6.png" alt="" title="" class="object-cover bg-gray-100 rounded-2xl md:rounded-3xl lg:rounded-4xl" style="aspect-ratio: 1/1; object-position: undefined undefined;" data-corners="default" data-aspect="1:1" data-caption="" data-positionx="undefined" data-positiony="undefined" data-fullwidth="false" data-mce-src="https://cdn.durable.co/blocks/fDPvHG40GzHB9Np8bXqJiSWlTWArEQSherLdc4wt7SGlWTYLi1XEJJIwjUPjwKo6.png" data-mce-style="aspect-ratio: 1/1; object-position: undefined undefined;">Snowflake CoWork Resource Budget is set up and ready<h3>Conclusion</h3>Snowflake CoWork has undergone a transformation from “simply a UI for Cortex Agent” into a separate ecosystem of agentic features deeply embedded in your Snowflake data. To anyone working as an analyst and beyond, I highly recommend exploring its powerful capabilities as an aid in day-to-day work and a source of meaningful AI augmentation. Snowflake CoWork has an incredibly low barrier to entry, with rewarding results in a short time.

Snowflake CoWork – 3 New Features Every Analyst Should Know

Diverse recruitment team collaborating on hiring workflow strategy around whiteboard in modern open-plan office with natural lighting.

Getting Started with Snowflake Cortex

CloudHive

CloudHive is your North America and LATAM Snowflake-focused staffing partner.

We help accelerate Snowflake adoption and maximize the value of the Snowflake AI Data Cloud by delivering experienced, on-demand Snowflake contractors and specialized talent acquisition services.

Our exclusive focus on Snowflake gives us access to a deep network of certified contractors and professionals built through long-standing relationships, enabling us to deliver high-impact talent quickly and precisely.

Beyond contractors, we place experienced full-time hires across Data and AI Leadership, Technical Delivery, and Sales, ensuring organizations have the expertise to scale and succeed.

Switzer

Rufina

To offer you the best experience, this site uses cookies.

Blog

Semantic View Creation Guide: Autopilot or CoCo, or both?

Make No Mistake: What Works and What Does Not in Cortex A...

Snowflake’s 2026_06 Feature Change: Transient Tables Will...

Snowflake CoWork – 3 New Features Every Analyst Should Know

Getting Started with Snowflake Cortex