Skip to content

Expedition 2026: What Snowflake announced, and what to check before you build

Snowflake Expedition 2026 announcements grouped by practical impact, with source-reported release statuses and checks before adoption.

Snowflake Expedition 2026 banner with a blue mountain illustration and the headline: What Snowflake announced, and what to check before you build.

Snowflake Expedition 2026 gives data teams a practical question: which capabilities address a problem worth solving now, and which belong on the evaluation list? Release status, operating limits and ownership matter when you make that choice.

This post sorts the announcements into three groups, shows what each one changes for a data team, and lists what to check before you build on any of it. Expedition is the successor to Snowflake BUILD. The event announcement gives 3 to 5 November for the Americas and 4 to 6 November for other global regions.

Release status uses three labels:

  • GA: generally available.
  • PuPr: public preview.
  • PrPr: private preview.

This roundup uses official announcements and documentation reviewed on 5 November 2026. It includes updates presented at Expedition as well as capabilities released earlier. Status labels apply only to the named capability; “soon” means a planned preview. Items without sufficient supporting evidence are omitted. Availability can differ by interface and region, so check the requirements for your account.

Three groups, one direction

The announcements fall into three groups.

  1. Agents that work on governed data. Recurring work, governed tool access, business context and spend controls are the central themes.
  2. A more real-time, open data foundation. Streaming, transformations and serving form a connected architecture, alongside integrations for Iceberg, SAP, Workday and Salesforce.
  3. Platform plumbing for apps and admin. The announcements cover agent access to apps, clustering automation and cost administration.

I would evaluate the first group carefully because it combines agent actions, permissions and business meaning. A useful pilot should test all three together.

AI: agents with governance and spend limits

Snowflake frames the AI story as Ground, Act and Compound in its AI roll-up post. The CoCo and CoWork press release reports more than 5,800 accounts using CoWork and more than 9,100 using CoCo. These figures measure average weekly account usage over the final four weeks of the quarter ended 31 July 2026, rather than November adoption.

The items that matter most for practitioners:

  • Cortex AI Gateway: inference, observability and cost management (GA). The 3 November release note confirms these capabilities. Gateway requests are traced; clients can export additional OpenTelemetry traces. Do not assume that traffic bypassing the Gateway or every internal agent step is captured. The cost management documentation distinguishes shared team budgets, which notify or invoke custom procedures, from per-user quotas, which block usage within minutes. These controls are not guaranteed exact spending ceilings. Define the user identities and team tags before relying on attribution. Snowflake first announced the Gateway in July.
  • Cortex AI Gateway: Tools (PuPr). The governance announcement describes policy checks using the end user’s identity before routed MCP tool calls execute. Check which connections actually pass through that control.
  • Dynamic Model Routing. The CoCo announcement describes Auto-efficient selecting among approved models. Official sources disagree on preview status, so this roundup assigns no availability label. Snowflake reports up to 3x greater token efficiency on an internal dbt workload at comparable quality in its routing explanation. That is a vendor benchmark, not an independently reproduced result or a general cost-saving guarantee. Measure quality, latency and cost on your own prompts.
  • Agent Abuse Detection and Agent Trace Intelligence (PrPr). The security press release describes abuse detection across agent trajectories. The governance announcement describes Trace Intelligence finding loops and failing tools. Cortex AI Guardrails is a separate public-preview capability; detection, diagnosis and runtime prevention should be evaluated separately.
  • CoCo Automations (GA in Snowsight and CLI; PuPr in Desktop, according to the AI announcement). Scheduled work needs an owner, a budget and a reviewable run history. The distinction between interfaces explains why a generic Preview label should not be applied to every automation.
  • Cloud Agents (GA according to the AI announcement). Long-running agents in managed containers. The CoCo post also describes native Git operations; the separate GitHub integration has its own preview status. The Cloud Agents docs describe the setup.
  • Pipeline Builder (PuPr). A visual canvas for notebooks, tasks and SQL, built conversationally with CoCo. Check what the canvas generates. Make the generated SQL part of the review and debugging workflow. See the Pipeline Builder docs.
  • Cortex Training (PuPr). Snowflake manages GPU infrastructure for post-training open-weight models, including Qwen, DeepSeek and Gemma families. The documentation specifies enablement and commercial AWS availability. Snowflake’s training benchmark reports up to 61% lower cost for tested LoRA supervised fine-tuning workloads, using H200 throughput and competitor prices from 22 October 2026. This has not been independently reproduced for this article and should not be extended to every model or training method.
  • Agents for Shared Data (PuPr according to the AI announcement, rather than the infographic’s GA label). Can generate a Cortex Agent and semantic view from eligible shares or listings, subject to feature access, supported objects and required privileges. Review generated definitions before relying on answers about unfamiliar data. See the developer guide.

Reusable workflows and business-user tools

The AI announcements also change how teams reuse work and where business users encounter it.

  • CoCo Memory (PuPr) and Skills & Plugins Sharing (GA). Snowflake distinguishes personal, project-scoped memory from workflows shared with a team in its CoCo announcement. Treat these differently: a remembered preference should not silently become an organisation-wide rule. Assign someone to review shared skills and maintain their versions.
  • CoCo Desktop (GA). Snowflake announced Desktop general availability in its July AI Pulse. Individual capabilities have their own statuses: Desktop Automations remain public preview in the Expedition announcement.
  • CoWork Profiles and Snowflake Dashboards (PuPr). Profiles route questions to the appropriate agents; dashboards give users a shared starting point for follow-up analysis. See the CoWork explanation and availability summary. For a business team, the question is which definitions, agents and permissions sit behind that experience.
  • CoCo for Microsoft Excel and Google Sheets (preview). The 3 November release note describes querying Snowflake, using accessible semantic views and reviewing spreadsheet changes. This deserves attention from finance and operations teams. Query-time controls do not replace decisions about who may receive the resulting workbook.
  • Spreadsheet refresh. The Google Sheets documentation describes manual intelligent refresh using saved queries and an accept-or-reject preview. Google Sheets does not support refresh when the spreadsheet opens or Excel’s CORTEX cell functions. Agree on how readers can identify when results were last refreshed.
  • Mobile access. The CoCo and CoWork release describes a unified mobile experience. The AI announcement specifically lists CoCo on iOS as GA and Android as public preview. Do not extend those labels to every CoWork mobile capability.

Shared data and governed execution

  • AI Data Package and Agentic Marketplace Discovery (PuPr). The AI announcement describes packaged data with semantic views and conversational discovery. Easier discovery makes it more important to check licensing, provenance and whether a supplied metric means what your organisation expects.
  • Cortex Sandboxes (PrPr). The governance announcement describes controlled environments for agent code execution under the user’s permissions. Evaluate code execution separately from model and tool access: each needs appropriate limits and an audit trail.

The AI announcement also describes CoCo and CoWork Bots (private preview soon), Analytical Search (public preview) for document analysis, and the Mora team joining Snowflake. The Cortex Agent SDK supports Python and TypeScript, but the reviewed official sources disagree on its availability status; no status is assigned here.

Who should look at this first: teams that already run agents in production and need cost and identity controls. If you have not put an agent in front of users yet, use these controls as evaluation criteria for a limited pilot; readiness depends on your use case and operating requirements.

Data foundations: real-time, open and zero-copy

Snowflake describes a connected stack for streaming, transformation and serving. Its real-time analytics post reports a three-second median (P50) data-readiness latency across Snowpipe Streaming, streaming transformations and Interactive Analytics in internal testing on 20 October 2026. The result is published vendor evidence, not an independently reproduced benchmark or a latency guarantee. The components have different release statuses.

The five I would look at first; the status labels below remain source-reported:

  • Snowpipe Streaming (GA). Up to 20 GB/s per table, with data queryable in seconds and flat per-GB pricing. Elastic Channels let many producers share one channel. Assess client compatibility and ingestion architecture before estimating the effort. Per-GB ingestion pricing does not cover the entire storage and serving cost. See the product page and the Elastic Channels post.
  • Interactive Analytics (GA). Subsecond, high-concurrency serving on the same tables, including zero-copy on standard, dynamic and Iceberg tables. This can remove a separate serving copy for suitable workloads; test query performance and feature fit. See the product page.
  • Horizon IRC for external Iceberg. The 29 October release note confirms GA external-engine access with Snowflake RBAC. Access to externally managed tables with Snowflake data-protection policies remains preview. Horizon telemetry covers interactions through Horizon; do not assume it captures unrelated direct storage access.
  • Zero-Copy Parquet. The data-engineering announcement describes exposing existing Parquet files as Iceberg without rewriting source data. No availability label is assigned here because the reviewed announcement does not establish one. This is separate from Parquet Direct.
  • Open Data Sharing with Apache Polaris (GA). Share live, read-only Iceberg data with authenticated Iceberg REST Catalog-compatible clients. Validate the engine version and required policy support. This is the portability answer if you want to read Snowflake-shared data from another engine. See the open format sharing docs.

The rest of the data foundation list, with source-reported statuses:

  • Datastream: private preview, with public preview planned, according to the real-time announcement.
  • Streaming Transformations (PrPr): SQL transformations during ingestion, described in the real-time announcement.
  • Openflow Data Connectivity Proxy (GA): on-premises connectivity, described in the data-engineering announcement. Individual connectors and Openflow generations have separate availability requirements.
  • Snowpark Connect (GA) and Next-Gen File Reader (PrPr): distinguish the established Spark execution capability from the preview reader in the data-engineering announcement.
  • SAP Business Data Cloud, Workday Data Cloud and Salesforce zero-copy integrations (GA): listed in the data-engineering announcement. Check the supported direction and prerequisites for each connector.
  • Iceberg time travel and tags: the implementation documentation and release note label these preview, while the Expedition blog calls them GA. This roundup does not assign a settled availability label; check the SQL or Spark path and version you intend to use.
  • Snowpark Connect with Spark 4.0 and Iceberg v3 (PrPr): the data-engineering announcement describes this extension. The preview label does not apply to every existing Spark-Iceberg operation.
  • Hybrid Tables: Snowflake reports workload-dependent performance improvements in the data-engineering announcement. Google Cloud support is preview; AWS and Azure commercial support remains GA.
  • Snowflake Postgres data mirroring (GA): replication into Snowflake; the reverse direction is public preview soon, according to the data-engineering announcement.
  • dbt Projects, DCM Projects and Dynamic Tables in dbt (GA): core capabilities listed in the data-engineering announcement. Extensions have separate statuses.

Observe integrations (PrPr). The governance announcement describes Observe ingestion through Snowpipe Streaming and Snowflake Data Share into Observe. The latter exposes data already held in Snowflake as zero-copy Observe datasets. This sharing direction is different from querying Observe data from Snowflake.

These capabilities can reduce duplicated data and integration work when they fit the architecture. Open formats alone do not guarantee lower total cost or complete lineage. Keep ownership and access visibility explicit, including when another engine reads the same data.

Platform: apps, admin and tuning

The platform announcements describe agent access to apps, administration changes and tuning capabilities. The statuses below are source-reported; verify availability and operating limits before adopting them.

  • Snowflake App Runtime. Build a React or Next.js app from a prompt and deploy it inside your account, with SSO, RBAC and audit logging. The reviewed documentation describes commercial-cloud availability, excluding trial accounts and government regions; no explicit GA milestone is asserted here. See the App Runtime docs.
  • Native Apps with App Runtime front ends and Postgres access (public preview soon). The AI announcement describes planned full-stack front ends and access to Snowflake Postgres. Verify the implementation requirements when the preview becomes available.
  • Streamlit: talk to your app, sharing and embedding (GA). Side-by-side CoCo chat about app data. Share with individual users, or embed in portals such as Salesforce without a Snowflake login. Embedding supports a service-user model for viewers without Snowflake accounts and a viewer-identity model for provisioned users. Your backend obtains a short-lived embed URL; Snowflake role permissions still apply. Choose the model based on whether viewers need different data access. Read the sharing and embedding docs.
  • Organisation administration. The governance announcement describes central administration of organisation users, groups and third-party domain rules.
  • Optima Clustering: automatic key selection (GA). The governance announcement says Snowflake selects clustering keys from query history and updates them as patterns change. Good for teams that never got around to clustering. Check the cost on tables where a human chose the key carefully.
  • Serverless and Workspaces for App Runtime (public preview soon in the AI announcement). Snowflake describes planned scale-to-zero compute and wake-up in seconds, plus building and deploying inside Snowsight. Treat the startup timing as a vendor description, not a guaranteed latency.

The AI announcement also describes automatic MCP exposure for Streamlit in public preview. Before enabling agent access, verify the available controls, permissions and actions for each app. The announcement alone does not establish that every installed app is exposed by default.

The governance announcement lists organisation budgets, per-user AI quotas and tag-based anomaly detection as GA. Keep their purposes separate: monitoring a budget and blocking a user are different controls.

What it means for semantic layers

For semantic-layer work, the important distinction is between approved business meaning and metric execution. Business Ontology governs definitions and relationships, while Semantic Views retain the calculation logic. These are complementary capabilities, not a mandatory setup sequence.

Snowflake describes three complementary capabilities in its Business Ontology overview and engineering explanation:

  1. Cortex Sense (PuPr soon) infers context from query history, dashboards and dbt models, and can draft ontology entries.
  2. Business Ontology (private preview, public preview soon) records what a term means, who owns it, whether it is approved, and how concepts relate. Scoped variants, such as same-store sales per brand, are kept as separate approved definitions.
  3. Semantic Views execute the metric logic. The ontology links to a view's metric but leaves the calculation with the view's owner.

That split is the right one. Keep the definition, the owner and the approval in one place. Keep the calculation next to the data. Duplicated definitions can produce inconsistent answers unless authority and conflict handling are explicit. Snowflake’s engineering explanation describes agents asking users to disambiguate approved definitions.

For teams mapping Apache Ossie models to Snowflake, the ontology FAQ describes Ossie import and export for both Business Ontology and Semantic Views, plus RDF exchange for ontology concepts. Treat this as announced interoperability; test supported versions and round-trip fidelity with your own model.

Hierarchy terminology needs care. Business Ontology supports nested domains and typed relationships such as IS_A and HAS_PART. Those are not the same as a native dimensional drill path. The reviewed CREATE SEMANTIC VIEW syntax has no HIERARCHY clause.

Semantic Views also gained level-of-detail expressions in preview on 2 November, with FIXED, INCLUDE and EXCLUDE DIMENSIONS. These control calculation grain; they do not by themselves establish dimensional hierarchy behaviour. Revisit older parent-total calculations before carrying forward window-metric workarounds. Comments and synonyms can describe intended relationships, but they do not enforce a drill path. Test whether your model, converter and agent produce the required SQL rather than assuming that preserved metadata is used.

A governed ontology gives you shared definitions. It also gives someone the job of maintaining them. Without active stewardship, the glossary risks becoming stale. Decide the owner before you switch it on.

What to check before you build

  1. Check the status. Private-preview access may be restricted, and preview capabilities can change. GA status alone does not establish suitability for your production workload; assess support, limits, security and recovery requirements. Some official announcements and documentation disagree; where that remains unresolved, this post does not assign a settled status.
  2. Check your region and edition. Preview features and some GA features vary by region and edition. Read the docs for your account.
  3. Measure the vendor numbers on your data. Routing efficiency, cost savings and latency figures are measured on Snowflake's workloads, not yours.
  4. Decide the owner. For every agent, automation, ontology entry and external-engine table, name the person who answers when it misbehaves.
  5. Start with observability. Enable cost attribution and tracing before the pilot when possible. Later enablement still helps future operations; reconstructing earlier activity depends on the records retained.

Conclusion

Expedition announcements are a menu, not a shopping list. Pick the one you can own, measure and roll back first.

Sources and further reading

Official Snowflake links supplied with the announcement summary:

Press releases:


Transparency note: AI assisted with drafting, source research, the documentary claim audit and revisions. This overview cites primary announcements and documentation; it is not a hands-on test of the capabilities or an independent reproduction of vendor benchmarks.