The cool part: Snowflake is turning meaning and AI behavior into governed platform objects.

Snowflake wants the semantic layer to become the control plane.

The most important through-line was not any one demo. It was that Snowflake is trying to make business meaning durable and reusable across dashboards, spreadsheets, analytics chat, AI agents, and workflow automations. That matters because most enterprise AI failures are not model failures. They are context failures: conflicting definitions of revenue, inconsistent customer/entity relationships, security rules that do not propagate, and metrics that drift between tools.

AtScale + Power BI / Excel

The specific announcement worth knowing is the Snowflake Semantic Views XMLA Endpoint, powered by AtScale. The idea is that Power BI and Excel can connect live to Snowflake Semantic Views through familiar XMLA / Analysis Services style patterns. Power BI gets live access without recreating the model in Power BI first; Excel gets PivotTables, slicers, and CUBE-function style usage over governed Snowflake definitions.

Strategically, this is strong if Snowflake is the semantic source of truth and Microsoft tools are consumption surfaces. It is weaker if the enterprise expects Power BI semantic models to remain canonical. The critical question is whether AtScale is exposing the Snowflake model directly or creating a second semantic system that must be synchronized and governed separately.

For agentic data-product teams, semantic views should probably be treated as the metric and business-field contract: the layer that keeps natural-language questions from turning into ad hoc SQL interpretation. The open design issue is how that contract interacts with ontology metadata and knowledge-graph reasoning without creating two competing meaning systems.

Ontology-on-Snowflake is “meaning as configuration.”

The ontology demos were especially relevant because they showed an explicit stack for relationship-aware AI. The core pattern was: store generic graph facts once, define ontology metadata separately, generate views from the ontology, expose semantic models, then let Cortex Agents route across graph analytics, concrete facts, abstract ontology concepts, and governance metadata.

The related ontology-stack-builder Cortex Code skill appears to build this in phases: gather inputs, recommend an ontology, visualize and confirm, create the physical and view layers, ensure the base semantic layer, create ontology semantic views, create the Cortex Agent, and validate. The workflow is interesting because it has approval gates. It is not just “let the model make a schema.”

For tax technology, this maps cleanly to entity/investor/partnership relationship problems. You can imagine facts stored once, meaning configured in ontology metadata, and agents answering questions by traversing governed relationships rather than improvising over flattened tables.

The useful next design question is not “semantic views or ontology?” It is which questions require governed metric definitions, which require relationship reasoning, and how an answer trace can show both: the semantic view that defined the measure and the ontology/graph path that connected the entities.

AI Function Studio looked like CI/CD for AI behavior.

This was one of the coolest things I saw because it addresses a real enterprise problem: how do we improve AI functions without turning production into a prompt experiment? The demo pattern showed candidate variants, evaluation metrics, score/cost/throughput tradeoffs, and an approval step before applying an optimized function.

Public material indicates AI Function Studio is in Public Preview and can create, evaluate, optimize, and publish Cortex AI Functions. The optimization pattern appears to be Genetic-Pareto / Pareto-frontier style: generate candidate functions, evaluate them, compare quality and cost, preserve function signatures, and choose whether to promote the improved version.

Tax / BI use cases

• Legal-term extraction from partnership agreements.
• K-1 exception classification and reviewer triage.
• Document-to-common-data-model mapping.
• Reconciliation explanation generation.
• Quality/cost optimization for high-volume document processing.

The important caveat: it appears GEPA-like in spirit, similar to DSPy GEPA, but Snowflake has not confirmed that it literally uses DSPy.

AI functions are the production primitive under the agent story.

The June 3 session made the function layer much clearer. Cortex AI Functions are positioned as SQL-native AI over every major enterprise data type: text, documents, images, audio, video, and structured data. The visible function portfolio included custom AI functions, AI_COMPLETE, AI_CLASSIFY, AI_FILTER, AI_AGG, AI_EMBED, AI_EXTRACT, AI_SENTIMENT, AI_TRANSLATE, AI_TRANSCRIBE, and AI_PARSE_DOCUMENT.

Document intelligence is the immediate enterprise wedge

The document slides showed AI_PARSE_DOCUMENT, AI_EXTRACT, and AI_COMPLETE turning document libraries in S3/GCS/Azure/Snowflake into structured extraction, enterprise search, research analytics, and agent interfaces. The key phrase: documents become governed data assets.

Horizon Context is the other half of the agent-control story.

If AI Function Studio governs behavior, Horizon Context is aimed at governing meaning. The slides framed semantic context as the shared layer that lets business users, customer apps, executives, and agents get consistent answers from the same enterprise understanding.

The most interesting product signal was Semantic View Autopilot. The photos suggest a workflow that starts from existing data, SQL, or usage context; recommends or generates semantic views; then routes them toward review, enrichment, and governed consumption. That is exactly where enterprises need help — not because writing YAML or SQL is hard, but because certifying meaning across teams is political and operationally messy.

Why BI233 cares

PE tax work has the same context problem: funds, LPs, entities, documents, obligations, jurisdictions, quality rules, exceptions, and reviewer logic need shared meaning before agents can safely help. Horizon Context and Semantic Views are the Snowflake-native vocabulary for that argument.

Cost governance is becoming part of AI architecture.

The AI Function session included a useful cost-governance frame: control cost before, during, and after AI queries. Before the query: token counting and cost estimation. During the query: incremental metering, low-latency budgets, and user quotas. After the query: account usage telemetry, per-role/per-tag attribution, and chargeback reporting.

This matters because agents can multiply AI calls. A single analyst asking a question is manageable; background automations calling multimodal functions across thousands of records can create surprise spend quickly. Production AI needs budgets, quotas, attribution, and auditability in the same way production data workloads need warehouses, monitors, and ownership.

This is one of the biggest adoption gates for agentic data-product teams. The demo path may work beautifully, but if every natural-language question fans out into multiple Cortex Agent steps, semantic queries, Cortex Search calls, AI function invocations, and app/tool actions, the team needs a cost model before broad rollout. Measure cost per useful answer and cost per completed workflow, not just credits consumed by isolated features.

Dynamic Tables plus DCM Projects are the pipeline substrate for agents.

The sign that said “Autonomous SQL Pipelines for AI Agents” was pointing at a practical issue: agents are only useful if the data they inspect is fresh, shaped, governed, and explainable. Dynamic Tables handle runtime refresh and dependency tracking. DCM Projects — Database Change Management Projects — are the lifecycle wrapper for database objects.

The agent angle is simple but important: an agent should not rely on hand-built, invisible ETL spaghetti. It should rely on data products whose definitions can be reviewed, tested, reviewed, promoted, and monitored. DCM Projects are Snowflake’s move toward making those definitions lifecycle-managed.

Snowflake Postgres + SPCS is the citizen-development part of the story.

AD212 made the practical app lane clearer: Snowflake Postgres stores operational state, SPCS runs the app/container/MCP server, Snowflake identity controls access, and zero-ETL/mirroring/pg_lake-style paths make app data analyzable without a custom pipeline. The provocative line was simple: build the app where the data already lives.

Example workflow pattern

A K-1 / fund-tax exception workbench: Postgres stores items, comments, assignees, status, and decisions; SPCS hosts the UI; Snowflake tables provide fund/entity/investor context; Cortex drafts summaries; MCP tools can propose updates while humans approve final state changes.

Another practical lane: use Snowflake-native apps for POCs that need real data but should not move that data out of the Snowflake boundary. Start with narrow internal workflows, not broad platforms: fund-to-corporate handoff, exception review, data-quality triage, semantic-view QA, or agent trace review.

pg_lake makes Postgres a lakehouse participant.

pg_lake is an open-source Snowflake/Crunchy Data lineage project that lets Postgres query and manage object-storage data with familiar SQL. It supports formats such as Parquet, CSV, JSON, and Iceberg-oriented tables; import/export through Postgres COPY; and patterns where Postgres can create/manage Iceberg tables that Snowflake can later read through catalog integration.

This is not Debezium-style row-level CDC. It is object-storage / file / Iceberg oriented. The strategic reason it matters is that many operational systems still live in Postgres, while analytics and AI workflows increasingly want open table formats and object storage. pg_lake helps bridge that world without making every Postgres workload pretend to be a full warehouse.

Interactive Tables are Snowflake’s low-latency serving story.

Interactive Tables and Interactive Warehouses are Snowflake’s attempt to serve low-latency, high-concurrency workloads without pushing teams into a separate serving database. This is relevant for live dashboards, embedded analytics, APIs, observability, and agent workloads that need fast structured-data access.

The mechanics matter: Interactive Tables require clustering, can be created via CTAS or auto-refresh with target lag, and are served by Interactive Warehouses. Standard warehouses still create/load/refresh; Interactive Warehouses serve fast concurrent SELECTs. Recent updates include auto-suspend/resume, Search Optimization support, manual scaling, storage lifecycle policies, and fallback warehouses for queries that exceed interactive-timeout expectations.

Snowflake Intelligence / CoWork is the move from analytics chat to work execution.

Snowflake Intelligence / CoWork is the business-user work surface in this story. The positioning is broader than asking questions over data: personal work agent, business-tool integrations, automations, artifacts, skills, and actions. The architecture mental model is: CoWork is the user-facing surface; Cortex Agents plan and orchestrate; Cortex Analyst handles structured data through Semantic Views; Cortex Search handles unstructured retrieval; Cortex Sense supplies context; MCP/Natoma connects tools; Agent Studio manages lifecycle and governance.

The hard part is not the chat UI. The hard part is action governance. Can CoWork safely read governed metrics, investigate root cause, draft an action, ask for approval, execute through Slack/Salesforce/Jira/etc., and leave a usable audit trail? If yes, Snowflake starts looking like a governed work execution platform. If no, it is another polished analytics assistant.

For our agentic-search pattern, the trace is not a nice-to-have. The answer needs to show what agents/tools ran, which tables or documents were touched, which semantic definitions were applied, and where confidence/citations came from. That is what turns “the AI said so” into something a reviewer or client team can trust.

Sigma FP&A use cases suggest BI is becoming app-building.

The Blackstone/Sigma FP&A signal was interesting because budgeting and forecasting are not just dashboards. They require writeback, versions, scenarios, approvals, workflow, and business-owned logic. If finance teams are building budgeting/forecasting apps in Sigma on Snowflake, Sigma is functioning as a business-user application layer — not merely a BI surface.

That is powerful if governed well. It is dangerous if every analyst-built workbook becomes a shadow finance application with unclear formula ownership, weak promotion process, and murky writeback controls. The question is not “can Sigma do planning?” The question is how a workbook becomes certified production infrastructure.

The fund-to-corporate handoff is a concrete place to test the Snowflake/Microsoft boundary. A Snowflake semantic view could feed Excel and Power BI through XMLA while also feeding a Snowflake-native visualization or app. If Snowflake’s own visualization/app layer is good enough, keeping data, semantics, and AI context together may be cleaner. If Power BI remains the better user surface, Snowflake can still be the governed semantic source instead of trying to replace every front end.

BI233 aged well — and agentic data-product teams may get smaller.

The PE tax relationship-data framing lines up very well with the Summit direction. So do the agentic data-product teams ideas around agentic search and trusted answer traces. The best version of enterprise AI here is not generic copilot usage. It is governed business context plus narrow agents tied to real operating workflows, with Snowflake potentially providing more of the substrate than expected.

A useful client-facing angle: “Generic copilots are not enough. Useful enterprise AI needs governed business context and narrow workflow agents with lifecycle controls.”