# Snowflake Summit 26 AI context brief A portable summary of the Snowflake Summit 26 signals most relevant to AI applications, governed data products, semantic context, agents, and workflow surfaces. This brief is intentionally tool-neutral. It can be read by a person, pasted into an AI assistant, added to a repository, attached to a Copilot/Cursor/Claude/Codex conversation, or used as background material for planning and discussion. ## Executive takeaway Snowflake Summit 26 pointed to a practical architecture shift: more of the AI application stack can be composed inside Snowflake instead of built as separate infrastructure. The useful strategic question is: ```text Which parts of an AI/data product should be domain-specific capability, and which parts should be composed from Snowflake-native primitives? ``` Snowflake showed or described capabilities across: - Snowflake Intelligence / CoWork as business-user work surfaces. - Cortex Agents for planning, routing, and tool use. - Cortex Analyst and Semantic Views for governed structured-data questions. - Cortex Search for unstructured retrieval. - Horizon Context for shared business context used by people, apps, and agents. - Semantic View generation, enrichment, and certification patterns. - Ontology-on-Snowflake and knowledge-graph patterns. - Cortex AI Functions and AI Function Studio for governed AI behavior, evals, and optimization. - Snowflake Postgres and Snowpark Container Services for app/workflow surfaces near governed data. - DCM Projects and Dynamic Tables for lifecycle-managed data products. - AtScale XMLA endpoint for Power BI and Excel consumption of Snowflake Semantic Views. - Cost-governance primitives around AI usage. Many capabilities are preview, private preview, or still emerging. Treat them as product-direction signals, not production guarantees. ## What changed Snowflake is trying to govern more than data storage and SQL execution. The platform direction points toward governing: - fresh data pipelines, - semantic definitions, - business context, - AI functions, - document intelligence, - agent routing, - workflow actions, - app state, - approvals, - cost and telemetry, - audit traces. That matters because enterprise AI failures often come from context and governance gaps rather than model quality alone: conflicting metric definitions, weak lineage, inconsistent security propagation, no cost visibility, and unclear action boundaries. ## Reference architecture signal ```text Operational data, documents, and app state -> Dynamic Tables + DCM Projects for fresh governed pipelines -> Semantic Views for governed metrics, dimensions, and business fields -> Ontology metadata / knowledge graph for entity relationships and reasoning paths -> Horizon Context for packaging shared meaning for users, apps, and agents -> Cortex Analyst over structured data -> Cortex Search over documents and unstructured data -> Cortex AI Functions for extraction, classification, summarization, parsing, document intelligence -> Cortex Agents for routing, tool use, and orchestration -> Snowflake Intelligence / CoWork or other app surfaces for users -> Snowflake Postgres + SPCS for review queues, exceptions, approvals, and workflow state -> BI, spreadsheet, native app, or product UI consumption surfaces -> trace, evals, cost, and approval logs as first-class product artifacts ``` The emerging pattern is governed business context plus explainable answers plus narrow, auditable workflow actions. ## Capability map ### Snowflake Intelligence / CoWork + Cortex Agents Potential role: - Natural-language user interface. - Agent orchestration and tool routing. - Business-user work surface. - Route to actions, automations, artifacts, and approvals. Open questions: - Can agents expose a usable trace of tools, data sources, semantic views, and reasoning path? - Can they call external tools or SPCS apps with approval and audit? - How much of the plan is inspectable versus hidden? - What is the pricing model for multi-step agent flows? - Is this production-grade trusted work, or only demo-level chat? ### Semantic Views / Horizon Context Potential role: - Governed contract for metrics, dimensions, entities, and business-friendly fields. - Shared context consumed by Cortex Analyst, agents, BI tools, Excel, Power BI, and apps. - Guardrail against ad hoc SQL interpretation. Open questions: - Who owns and certifies generated semantic views? - How are conflicting definitions resolved? - Can semantic view changes be versioned, reviewed, tested, promoted, and rolled back? - Does identity, RBAC, row access, and masking propagate through every consumer? - How does Horizon Context package context for agents and apps? ### Ontology / knowledge graph on Snowflake Potential role: - Relationship-aware reasoning across entities, obligations, documents, transactions, users, approvals, and exceptions. - Graph paths and relationship explanations for answer traces. - A structured layer for concepts that are not just metrics. Open questions: - What belongs in semantic views versus ontology metadata? - How does an agent know when to use metric semantics versus relationship reasoning? - Can the trace show both the semantic definition and the ontology path? - Can ontology definitions be lifecycle-managed like code? ### Cortex Search / Cortex Analyst / Cortex AI Functions Potential role: - Cortex Analyst: structured-data question answering through Semantic Views. - Cortex Search: unstructured retrieval over documents and text. - AI Functions: extraction, classification, summarization, parsing, sentiment, transcription, and document intelligence. - AI Function Studio: eval and optimization workflow for production AI functions. Open questions: - Which tools are callable by Cortex Agents in the target environment? - Can results include citations, confidence, and bounding boxes where appropriate? - Can eval sets, candidate functions, approvals, diffs, version history, and rollback be managed seriously? - What is the cost per useful answer or completed workflow? ### Snowflake Postgres + SPCS apps Potential role: - Internal apps and proofs of concept near governed Snowflake data. - Review queues, exception workbenches, approval/comment capture, trace review, semantic-view QA. - App state written to Postgres and then analyzable or usable by Snowflake AI workflows. Open questions: - Is Snowflake Postgres available enough for the target environment? - How mature is SPCS-to-Postgres networking? - How are app users, service roles, secrets, and agent tools permissioned and audited? - When should the app be Snowflake-native versus external? ### Microsoft / Fabric / Power BI / Excel boundary Likely boundary to evaluate: - Snowflake as governed data, semantic, and agent-context source. - Power BI and Excel as familiar consumption surfaces where they remain best. - Snowflake-native apps or product UI where keeping semantics, context, AI, and workflow state together matters more. Decision criteria: - User experience. - Security passthrough. - Semantic consistency. - Cost. - Governance. - Operational support. - Avoiding duplicated meaning layers. ## Trust trace pattern A useful AI answer or action should be reviewable. A possible trace shape: ```yaml answer_id: question: answer_summary: confidence: semantic_context: semantic_views_used: - name: metrics: [] dimensions: [] filters: [] definitions_applied: - term: definition: ontology_context: graph_entities: - id: type: relationships_traversed: - from: relationship: to: data_sources: tables_or_views: - name: purpose: documents: - name: citation: agents_and_tools: - agent_or_tool: action: inputs: outputs: checks: row_access_policy_applied: masking_policy_applied: human_approval_required: reviewer_notes: cost_and_latency: warehouse_credits: ai_tokens_or_credits: latency_ms: open_issues: - ``` Minimum useful trace elements: - original question, - final answer, - semantic views or definitions used, - tables, views, documents, or apps touched, - agent and tool calls, - citations and confidence if available, - cost and latency if measurable, - explicit unknowns. ## Practical evaluation dimensions When applying these Summit signals to a real product or workflow, the important dimensions are: - whether Snowflake capabilities are available in the relevant account and region, - whether preview features are mature enough for the intended use, - whether semantic definitions can be governed and reused across tools, - whether identity, row access, masking, and audit behavior propagate end to end, - whether the user surface belongs in Snowflake, BI/spreadsheets, a custom app, or an existing product UI, - whether cost per useful answer or completed workflow is measurable and acceptable, - whether answer traces are understandable to reviewers, operators, and business users, - whether the custom layer is real domain/product differentiation or just rebuilt plumbing. ## Warnings and assumptions - Summit demos are not production proof. - Preview capabilities may be unavailable, incomplete, or materially different in production. - Agentic workflows can become expensive if they fan out into many AI calls. - Semantic Views, Horizon Context, ontology/knowledge graph, Cortex Search, Cortex Analyst, and Cortex Agents may not be as integrated in practice as they look in conference narrative. - Existing enterprise tools may remain the better user surface even if Snowflake is the better governed context source. - Generic platform work is risky unless it directly serves a narrow user need, trust requirement, or domain workflow.