# Snowflake CoWork: What Architects Need to Know Before Their Teams Start Using It > Source: > Published: 2026-07-08 02:28:05+00:00 Last week my analyst asked CoWork: “What was our net revenue retention for Q4, excluding the APAC trial accounts?” Four seconds. Accurate. SQL visible for audit. Nobody thought twice. Then our security review board asked me *how* it worked. Not what it did — how. That’s when I realized most people on my team, including senior engineers, think of CoWork as a chatbot that translates English to SQL. It isn’t. There’s a multi-layer agent architecture underneath, and understanding it changes how you design agents, govern access, and debug wrong answers. This is the first article in a five-part series on Snowflake CoWork (formerly Snowflake Intelligence, rebranded and repositioned at Summit 2026 as a governed agent for business users). Everything that follows — building agents, MCP integration, governance at scale, production monitoring — depends on what’s actually executing when a user types a question. I need to be direct because the positioning creates confusion. Here’s a simple example. Imagine you ask a human data analyst: “Why did churn spike in March?” That analyst doesn’t just write one query. They think about which tables matter, whether to check the CRM notes or just the revenue data, whether the answer needs a chart. Then they run multiple queries, cross-reference, and come back with a synthesized answer. CoWork does something structurally similar. When you ask a question, a Cortex Agent backed by an LLM receives the query plus conversation history. It has access to configured tools — Cortex Analyst for structured data (via semantic views), Cortex Search for unstructured/vector retrieval, and custom tool functions (UDFs and stored procedures). The agent reasons about *which* tools to call, *what parameters* to pass, and *whether the combined result* actually answers your question. The official documentation describes the flow as: The distinction matters operationally. When a CoWork response is wrong, the failure could live in any of these layers. Misunderstood question? That’s layer 3. Wrong tool selected? Also layer 3. Bad SQL generated? That’s Cortex Analyst inside layer 4. Metric defined incorrectly? That’s your semantic view — not CoWork at all. *Disclaimer: Snowflake doesn’t publish exact internal execution architecture. This is my observational framework from six months across 140 users — not official documentation.* I split the official four-step flow into six layers because it helps me pinpoint failures faster: **Layer 1 — Interface:** CoWork UI, iOS app (Preview, Open), or API accepts the query. Multi-turn context is maintained here. **Layer 2 — Agent Orchestration:** The Cortex Agent receives query + conversation context. Orchestration instructions (which you configure) shape routing behavior. **Layer 3 — Tool Selection:** The agent evaluates available tools. My Q4 NRR question hits Cortex Analyst because “net revenue retention” maps to a defined metric in the semantic view. **Layer 4 — Tool Execution:** Cortex Analyst generates SQL against the semantic view definition. It doesn’t see raw tables — it sees curated metrics, dimensions, and relationships. **Layer 5 — Snowflake Execution:** Generated SQL runs under the user’s role. Standard access controls apply — object grants, row access policies, masking policies. The user also needs SELECT on underlying tables referenced by the semantic view. **Layer 6 — Response Synthesis:** Results return to the agent. It evaluates whether the answer satisfies original intent, formats the response, optionally includes the SQL. The critical insight: Layers 2, 3, and 6 are where the LLM reasons. Layers 4–5 are deterministic execution. “AI hallucination” concerns are constrained to the reasoning layers — actual data access is always governed SQL against real tables. I’ve deployed three text-to-SQL tools over two years. Same failure mode every time: syntactically valid SQL that’s semantically wrong. Correct column names, wrong join logic. Valid aggregation, wrong filter scope. CoWork sidesteps this with the semantic view abstraction. Cortex Analyst doesn’t guess what “net revenue retention” means from column names — the semantic view declares the formula explicitly. “APAC trial accounts” isn’t an ambiguous filter; it’s a named dimension value. I’ve observed the agent reject its initial SQL and re-query with adjusted parameters. Whether this is explicit self-correction or LLM iterative reasoning is unclear from outside — but practically, the results are better than single-shot generation. **Deep Research** (Preview, Open) extends this further. For complex questions like “Why has forecast accuracy been declining?” it decomposes the problem into parallel sub-investigations, runs them across structured and unstructured data, and produces a cited report. Investigations can take up to 10 minutes. I’ve found it genuinely useful for multi-source questions where my standard agents struggle. Our security team’s question: “If CoWork can query anything, how do we prevent it from surfacing data users shouldn’t see?” The answer is straightforward: **CoWork initializes the session with the user’s default role and default warehouse.** Users can switch roles within the session, but the initial state is what matters for most users who never think to change it. From the official docs: “All of the queries from Snowflake CoWork use the user’s credentials. All role-based access control and data-masking policies associated with the user automatically apply to all interactions and conversations.” Object grants, row access policies, column masking — they all apply exactly as they would for a direct query. CoWork doesn’t have elevated service account privileges. It *is* the user. This holds across all interfaces — web UI (ai.snowflake.com), iOS app, private connectivity endpoints, and the API. For **Artifacts** (now GA as of June 17, 2026), RBAC scopes per viewer. A shared artifact re-runs the underlying query under the recipient’s credentials and role. Two users with different roles see different results from the same artifact. This model is solid for enterprise deployment. But it shifts the entire burden to getting default roles configured correctly — which brings me to the audit queries. Because CoWork initializes with DEFAULT_ROLE (not whatever role you’re using in Snowsight), you must verify three things before rollout: Users missing a default role or warehouse: ``` SELECT name, login_name, default_role, default_warehouse, CASE WHEN default_role IS NULL AND default_warehouse IS NULL THEN 'CRITICAL: Both missing - PUBLIC role + no compute' WHEN default_role IS NULL THEN 'HIGH: No default role - will use PUBLIC in CoWork' WHEN default_warehouse IS NULL THEN 'MEDIUM: No warehouse - agent queries will fail silently' END AS severity, created_on, last_success_loginFROM snowflake.account_usage.usersWHERE deleted_on IS NULL AND (default_role IS NULL OR default_warehouse IS NULL)ORDER BY CASE WHEN default_role IS NULL AND default_warehouse IS NULL THEN 1 WHEN default_role IS NULL THEN 2 ELSE 3 END, last_success_login DESC NULLS LAST; ``` Users whose default_role is set but NOT granted (silent PUBLIC fallback): ``` SELECT u.name AS user_name, u.login_name, u.default_role, 'WARNING: default_role NOT granted - falls back to PUBLIC' AS grant_statusFROM snowflake.account_usage.users uLEFT JOIN snowflake.account_usage.grants_to_users g ON u.name = g.grantee_name AND u.default_role = g.role AND g.deleted_on IS NULLWHERE u.deleted_on IS NULL AND u.default_role IS NOT NULL AND g.role IS NULL; ``` Roles that lack USAGE on their assigned warehouse: ``` SELECT u.name AS user_name, u.default_role, u.default_warehouse, 'WARNING: No USAGE on warehouse for default_role' AS warehouse_accessFROM snowflake.account_usage.users uLEFT JOIN snowflake.account_usage.grants_to_roles p ON p.grantee_name = u.default_role AND p.name = u.default_warehouse AND p.privilege_type IN ('USAGE', 'OPERATE', 'OWNERSHIP') AND p.deleted_on IS NULLWHERE u.deleted_on IS NULL AND u.default_role IS NOT NULL AND u.default_warehouse IS NOT NULL AND p.privilege_type IS NULL; ``` To fix individual users: ``` ALTER USER SET DEFAULT_ROLE = ;ALTER USER SET DEFAULT_WAREHOUSE = ; ``` Feature statuses as of June 20, 2026, verified against official docs: ``` | Feature | Verified Status | Notes || ------------------------- | ------------------------- | --------------------------------------------------------------- || CoWork (core) | GA — Nov 2025 | Production-ready conversational workspace || Artifacts | GA — June 17, 2026 | Live, shareable references with RBAC per viewer || Deep Research | Preview — Open | Multi-step investigation and synthesis mode || iOS Mobile App | Preview — Open | Available on the App Store || MCP Connectors | Available | Connectors for Jira, Salesforce, Slack, Google Drive, and Gmail || Cortex Sense | Keynote announcement only | Not yet documented publicly; claims remain unverifiable || Multi-agent orchestration | Announced | Not separately documented as a standalone capability || Natoma acquisition | Announced | Strengthens enterprise MCP governance and connector management | ``` I’m deliberately separating “documented and available” from “announced at keynote.” The foundation you can build on today is CoWork + semantic views + MCP connectors. Everything else, plan for but don’t depend on. **The surprise:** CoWork’s multi-turn context is more capable than I assumed. I spent weeks writing overly detailed single-turn prompts when I could have let users iterate naturally. The agent retains context and refines tool usage across turns. **The limitation:** The agent’s reasoning is a black box for debugging. You can see the generated SQL (good) but not *why* it chose Cortex Analyst over Cortex Search, or why it picked specific parameters. The monitoring tab in Snowsight shows traces with timing per step — use it. **My recommendation:** Before deploying CoWork to any team, spend your time on semantic view definitions, not prompt engineering. CoWork is only as good as the semantic model it queries. A poorly defined semantic view produces confident wrong answers — and because those answers come with SQL that *looks* correct, users won’t question them. CoWork is a governed agent system with a clear separation between LLM reasoning and deterministic data execution. That separation is what makes enterprise deployment viable — hallucination risk is contained to the reasoning layer while data access stays fully governed under the user’s own role. The practical prerequisite for everything else in this series: get your semantic views right, get your default roles audited, and understand which layer to investigate when something goes wrong. Next: Article 2 — Building the semantic foundation that makes CoWork actually useful. 👏 Give it a clap if it added value 🔗 Share it with your team ➕ Follow for more 📘 Medium: [@SnowflakeChronicles](https://medium.com/@snowflakechronicles) 🔗 LinkedIn: [satishkumar-snowflake](https://medium.com/@snowflakechronicles) See you in the next one! 👋 *This article represents the author’s personal views and experience, not those of any employer.* #Snowflake #DataEngineering #CortexAI #DataArchitecture #AIGovernance [Snowflake CoWork: What Architects Need to Know Before Their Teams Start Using It](https://pub.towardsai.net/snowflake-cowork-what-architects-need-to-know-before-their-teams-start-using-it-6b355e52e4f0) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.