Snowflake CoWork: What Architects Need to Know Before Their Teams Start Using It Snowflake CoWork, rebranded from Snowflake Intelligence at Summit 2026, is a governed agent for business users that uses a multi-layer architecture combining LLM reasoning with deterministic SQL execution. The system processes user queries through six layers—interface, agent orchestration, tool selection, tool execution, Snowflake execution, and response synthesis—where only the reasoning layers are susceptible to AI hallucination, while data access remains governed by standard Snowflake access controls. Understanding this architecture is critical for architects designing agents, governing access, and debugging incorrect answers. 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