Is Business Intelligence Splitting?
A thesis has been circulating for the last two years: that business intelligence is splitting in two. On one side, a governed platform layer — a semantic layer, a catalog, a lakehouse — that holds the trusted definition of every metric. On the other, a thin, increasingly disposable consumer layer where people, and now agents, ask questions. The counter-argument is just as loud: that Microsoft Fabric, Databricks, and SAP Business Data Cloud are doing the opposite — re-consolidating storage, semantics, governance, and consumption into a single estate. Both stories are supported by real product moves. Architecture and buying teams keep being asked to pick a side, and the honest answer is that both are happening at once, on different axes. This essay separates those axes, weighs the evidence, and works through what it means for anyone building on SAP Datasphere, SAP Analytics Cloud, and Joule.
The question behind the question
When someone asks whether BI is splitting, they are rarely asking an architecture question. They are asking a buying question. Should we standardize on one vendor's full stack, or assemble best-of-breed pieces around an open semantic layer? Will the dashboard tool we license this year still matter in three? If agents become the primary interface, what exactly are we paying a BI vendor for? These are reasonable anxieties, and the market has not made them easier to resolve, because the vendors are sending contradictory signals on purpose.
It helps to be precise about what "BI" even means here, because the word covers at least three distinct things that are moving in different directions. There is the storage and compute layer — where the data physically sits and where queries execute. There is the semantic layer — where a metric like "net revenue" is defined once, with its joins, filters, and business rules, so that everyone gets the same number. And there is the consumption layer — dashboards, notebooks, embedded charts, natural-language interfaces, and increasingly autonomous agents. The "split" thesis and the "re-consolidation" thesis are not really in conflict because they are usually talking about different layers. The split is happening in consumption. The consolidation is happening in storage and, more contestably, in semantics.
So rather than asking the binary question, I find it more useful to hold two propositions at the same time and test each against what vendors have actually shipped. Proposition one: the consumption tier is fragmenting and commoditizing, and value is migrating down into the semantic and platform layers. Proposition two: a small number of platform vendors are absorbing the entire vertical stack — storage, semantics, governance, and consumption — into one commercial and technical envelope. The interesting question is not which is true. It is where each is true, and what that means for the decisions you have to make this year.
The split thesis in one picture: a thinning, plural consumer tier sitting on a thickening governed platform tier, with value and trust migrating downward.
The case that BI is splitting
The strongest version of the split thesis rests on a structural observation about where the difficult, durable work lives. Building a chart is no longer hard. Defining "net revenue" correctly — with the right currency conversion, the right treatment of returns and rebates, the right fiscal calendar, applied consistently to a dashboard, a planning model, an exported spreadsheet, and an AI agent's answer — is still hard, and it is the part that gets organizations into trouble when it is wrong. The split thesis says: pull that hard, shared work out of the dashboard and into a dedicated semantic layer, and the dashboard becomes a commodity skin over it.
Three product movements give this argument real weight rather than leaving it as theory.
1. The semantic layer became a product category
For most of BI's history the semantic model lived inside the dashboard tool — BusinessObjects universes, Cognos frameworks, Power BI's tabular models, Looker's LookML. The defining shift of the last few years is that the semantic layer has been pulled out as a standalone, tool-agnostic product. dbt's Semantic Layer, powered by MetricFlow, lets you define metrics in version-controlled code and serve them to any downstream tool through an API; dbt Labs open-sourced MetricFlow under an Apache 2.0 license at its Coalesce 2025 conference in October 2025, an explicit bet that the semantic definition should be portable rather than locked to one vendor's renderer. AtScale open-sourced its Semantic Modeling Language (SML) in September 2024 as a YAML-based, multidimensional standard intended to be readable across platforms. Cube has been a headless, universal semantic layer since it was open-sourced in 2019; today the open-source Cube Core sits underneath Cube's commercial agentic BI platform and serves metrics chiefly through a Postgres-compatible SQL API, plus a REST API, so that BI tools, applications, and AI agents can all consume the same definitions. The common thread is the deliberate separation of "what a metric means" from "what draws the chart."
2. The data platforms grew their own metric layers
At the same time, the cloud data platforms decided that the semantic layer belonged next to the data rather than in the BI tool. Snowflake's Cortex Analyst translates natural-language questions into SQL against semantic models, and Snowflake promoted those models to semantic views — native, governed schema objects, generally available since June 2025, that standard SQL can query and that Cortex Agents and Snowflake Intelligence also draw on — a semantic layer that lives in the warehouse. Databricks added metric views to Unity Catalog so that a KPI is defined once in the catalog and consumed consistently across dashboards, Genie, and alerts; in April 2026 it made them generally available as part of Unity Catalog Business Semantics and began open-sourcing the core implementation in Apache Spark. Google opened up Looker's LookML semantic layer with BI connectors and an Open SQL Interface that exposes LookML models to any tool that speaks JDBC, and in April 2026 previewed a managed MCP server native to Looker so that agents can query it directly. Whether the semantic layer ends up in a neutral tool like dbt or Cube, or inside the platform like Snowflake and Databricks, the direction is the same: it is leaving the dashboard.
3. The interface tier is being commoditized by agents
The third force is the one executives feel most directly. Conversational and agentic interfaces are turning the dashboard from a destination into one option among several. Tableau renamed Einstein Copilot for Tableau to Tableau Agent and pairs it with Tableau Pulse, which proactively surfaces metric changes into Slack and email rather than waiting for someone to open a dashboard; at Tableau Conference in May 2026 it unveiled an agentic analytics platform spanning Tableau Cloud, Server, Desktop, and Next. Copilot in Power BI has been generally available since 2024, and Microsoft retires the older Q&A feature in December 2026 in its favor. ThoughtSpot first shipped its Spotter agent in November 2024 and in December 2025 surrounded it with a team of BI agents — SpotterModel, SpotterViz, and SpotterCode alongside Spotter 3. SAP's own answer is Joule and, rolling out in phases since October 2026, Joule Work, a single front door across SAP and non-SAP applications. When the question can be asked in plain language and answered by an agent grounded in a governed semantic layer, the specific dashboard tool matters less. That is the heart of the split: if the meaning lives below and the question is asked above, the middle — the proprietary visualization tool — is the part most exposed to commoditization.
There is also a commercial logic that reinforces the split. "Headless" or "composable" BI — assembling a semantic layer, a query engine, and a lightweight front end from separate components — is attractive precisely because it resists lock-in. If the metric layer is portable, you can change the front end without re-implementing your business logic, and you can serve the same governed metrics to an embedded application, an internal dashboard, and an agent without maintaining three definitions. For organizations that have been burned by migrations, that portability is worth a great deal, and it is a genuine architectural argument for the layers separating.
The case that BI is re-consolidating
Now the other side, which is equally well evidenced. The re-consolidation thesis says the industry's actual money and momentum are flowing toward a handful of platforms that absorb storage, semantics, governance, and consumption into a single estate — and that the "best-of-breed semantic layer plus interchangeable front end" picture, while elegant, is not how most large enterprises are actually buying.
One lake to hold it all
Microsoft Fabric is the clearest exhibit. Its foundation, OneLake, is positioned as "a unified data lake for your whole organization," included automatically in every Fabric tenant, with the OneLake catalog as the single place to discover, manage, and govern the data in it. Storage, engineering, the warehouse, Power BI, and Copilot are sold as one fabric — the name is not subtle. SAP and Microsoft announced at Microsoft Ignite in November 2025 that SAP Business Data Cloud would share data with Fabric and OneLake, with general availability planned for the third quarter of 2026; SAP's BDC FAQ lists the integration as a public preview, and as of November 2026 no general-availability announcement has followed. The pitch is the opposite of composability: do not assemble pieces, adopt the estate.
The lakehouse vendors moved up the stack
Databricks tells a parallel story under the banner of what it now calls the Databricks Data + AI Platform (formerly the Data Intelligence Platform). It did not stop at storage and compute. Unity Catalog now carries governance, lineage, and the metric views described above; AI/BI dashboards and Genie — since June 2026 a family of AI coworkers led by Genie One, generally available alongside Genie Agents and Genie Code — are first-party experiences built on that same catalog. The strategy is vertical integration: the same vendor that holds your Delta tables also holds your governance, your metrics, and your natural-language interface. That is consolidation, not separation — even though, confusingly, the same metric views are part of what makes Databricks a credible semantic-layer platform for the split thesis too.
SAP's unification play
SAP's Business Data Cloud (BDC) is the same move expressed in SAP's terms. BDC is not a new product so much as a commercial and architectural unification: it bundles SAP Analytics Cloud and SAP Datasphere with SAP HANA Cloud and master-data capabilities (SAP Master Data Governance and, since 2026, SAP Reltio), brings in Databricks and Snowflake as partnered engines (SAP Databricks and SAP Snowflake), and ties consumption together under capacity-unit pricing. In July 2026 SAP also completed its acquisition of Dremio, which it is making the basis of an open, Apache Iceberg-based lakehouse in BDC. SAP reinforced the unification commercially: since January 1, 2026, SAC and SAP Datasphere are no longer eligible services for new BTPEA, CPEA, or pay-as-you-go subscriptions, SAP's pricing pages route new licenses through BDC core capacity measured in capacity units, and existing agreements run to the end of their term. That is a deliberate decision to sell the platform rather than the parts. BDC Connect extends the estate outward with zero-copy sharing of data products with external platforms — Databricks reached general availability in October 2025, Snowflake on May 4, 2026, and Google BigQuery in July 2026, while Microsoft Fabric is in public preview and Amazon Athena is planned for the first half of 2027. The framing matters: rather than letting your data scatter across best-of-breed tools, SAP's answer is to make its governed estate the center of gravity and reach out to the others.
The counter-thesis: three platforms — Fabric, Databricks, and SAP BDC — each absorbing the same vertical stack rather than letting it separate into best-of-breed parts.
The semantic layer war is where the two theses collide
If you want to see the tension between splitting and consolidating play out in real time, watch the semantic layer. It is simultaneously the strongest evidence for the split — because it is being extracted into standalone products — and the prize each platform most wants to own, because whoever controls the metric definitions controls the trust. Both things are true, and the contradiction is the whole story.
The independents argue for neutrality. dbt's Semantic Layer and MetricFlow, AtScale's SML, and Cube all make the same wager: that your metric definitions are too important to lock inside any one vendor, and should sit in a portable layer that any tool or agent can call. Even that camp is consolidating: Fivetran completed its all-stock merger with dbt Labs on June 1, 2026, so the company behind the dbt Semantic Layer now also sells data ingestion. The platforms argue for proximity. Snowflake's semantic views and Cortex Analyst, Databricks' Unity Catalog metric views and Genie, and Google's Looker semantic layer with its Open SQL Interface all say the semantic layer should live next to the data and the governance, where it can be enforced rather than merely published. SAP makes the proximity argument inside its own world: Datasphere's analytic models are the semantic layer for the SAP estate, feeding SAC, planning, and Joule from one governed definition.
The semantic layer is being fought over from both directions — and a vendor-neutral interchange standard has emerged to bridge them, which is itself evidence that no single owner has won.
The most interesting development cuts against simple narratives in both directions. In September 2025, a launch coalition of 17 companies convened by Snowflake — Salesforce (which owns Tableau), dbt Labs, Cube, Hex, Sigma, ThoughtSpot, Alation, Atlan, and Mistral AI among them — announced the Open Semantic Interchange (OSI), a vendor-neutral specification for how metrics, dimensions, and relationships are described so that they can be read consistently across tools and AI agents. The working group published the first version of the specification in an Apache 2.0-licensed repository in January 2026, by which time Databricks, AtScale, and Qlik had joined. On June 22, 2026, the project entered the Apache Software Foundation's Incubator under a new name, Apache Ossie, with the specification itself unchanged; by July the coalition had grown to more than 50 organizations, and reference converters already link it to dbt MetricFlow, Snowflake semantic models, and the Apache Polaris catalog. Ossie is fascinating precisely because it complicates both theses. It supports the split, by treating the semantic definition as a portable artifact independent of any renderer. But it also implies a kind of re-consolidation at the level of meaning — a single shared grammar for metrics, even if the products that store and serve them remain plural. The layer is separating from the tools, and at the same time converging on a common standard. That is not a contradiction the market has resolved; it is the live edge of it.
Where does this leave SAP? Datasphere is firmly on the platform-native side: its analytic models are designed to be the governed semantic layer for the SAP estate, and SAP's strategic value proposition is that this layer is enriched by the business semantics already present in S/4HANA — entities, hierarchies, and master data that a generic warehouse does not have for free. The open question I watch closely is interoperability. Ossie's ecosystem page lists nearly 80 organizations, Microsoft, Databricks, Oracle, and Salesforce among them; SAP itself is not listed, although Dremio, which SAP acquired in July 2026, is (checked in November 2026). As Ossie matures, the pressure on every platform vendor, SAP included, to speak a common semantic dialect will grow, because customers will not want to re-author "net revenue" three times for three tools. SAP's instinct is integration within its own estate — in 2026 it put the SAP Knowledge Graph at the core of its SAP Business AI Platform — while the market's drift is toward portable meaning across estates. How SAP reconciles those is, in my view, one of the more consequential roadmap questions of the next two years.
Agentic and embedded analytics: the interface dissolves into the workflow
Both theses agree on one thing: the standalone dashboard is losing its monopoly on consumption. They disagree on what replaces it. The split camp expects a plurality of interchangeable agents calling a shared semantic layer. The consolidation camp expects each platform's own agent, grounded in that platform's own catalog. The evidence so far supports a messier middle, where agents are proliferating but are only as trustworthy as the semantic layer beneath them.
Consider the trajectory. ThoughtSpot moved from a single Spotter agent in late 2024 to a coordinated team of BI agents announced in December 2025, and since July 2025 its generally available Agentic MCP Server has let other AI clients call Spotter's skills through the Model Context Protocol. Tableau's analytics is now framed as agents — Tableau Agent for conversational analysis and Tableau Pulse for proactive metric monitoring — pushed into the flow of work in Slack, email, Microsoft Teams, and Google Workspace rather than confined to a dashboard, with Tableau MCP servers generally available since May 2026. Copilot in Power BI now works in reports, as a standalone experience, and in the mobile apps. SAP's Joule spans SAP Business AI, and SAP's Autonomous Suite — more than 50 domain-specific Joule Assistants orchestrating more than 200 specialized agents, by SAP's May 2026 count — has been rolling out in phases since October 2026. The common pattern is that analytics is dissolving into the applications and conversations where work already happens — embedded, proactive, conversational — rather than living in a separate BI destination people remember to visit.
This is where the semantic layer stops being an abstraction and becomes a safety requirement. An agent that generates SQL or picks a metric is only as reliable as the definitions it is grounded in. Ungoverned, it will confidently return a "revenue" number assembled from the wrong table. Grounded in a governed semantic layer — Snowflake's semantic views, Databricks' metric views, Datasphere's analytic models — it inherits the joins, filters, and access controls that make the answer trustworthy and auditable. This is the deepest reason the value is migrating down the stack: in an agentic world, the semantic layer is not a convenience, it is the control point that decides whether an autonomous answer can be trusted. Whether that layer is neutral or platform-native, the organizations that invest in it will get usable agents, and the ones that skip it will get plausible-sounding fabrications at machine speed.
The economics: FinOps quietly favors consolidation
Architecture arguments are often settled by the invoice. One reason the re-consolidation thesis has commercial wind behind it is that fragmented, consumption-priced platforms are hard to forecast, and finance teams have noticed. When compute is metered per query and a dozen tools and now a fleet of agents all hammer the same warehouse, costs become volatile and difficult to attribute. The discipline of FinOps — bringing engineering, finance, and the business together to manage variable cloud spend — has become a standing concern in the data platform conversation precisely because of this.
The pricing models tell the story. Microsoft's Power BI is licensed per user — Pro at fourteen dollars per user per month and Premium Per User at twenty-four dollars per user per month, paid yearly, since April 1, 2025 — while Fabric capacity is purchased as a reserved or pay-as-you-go pool, with an F64 capacity, for example, listed at about $8,410 per month pay-as-you-go and about $5,003 per month on a one-year reservation in Microsoft's Central US pricing. SAP's move to capacity-unit pricing under BDC, and its decision to route new SAC and Datasphere licenses through BDC core capacity from January 2026, is the same instinct: convert a sprawl of per-item charges into one capacity pool that can be planned and governed centrally. Consolidation is partly an architecture story, but it is also a procurement story — one bill, one capacity model, one place to apply FinOps discipline, is genuinely easier to manage than many.
This does not settle the debate, because composability has its own economic logic: a portable semantic layer lets you put cheap, even free, front ends in front of expensive governed data, and avoid paying premium per-seat prices for users who only consume. But it does explain why the people who control budgets often lean toward the integrated estate even when the architects in the room prefer best-of-breed. The split is intellectually attractive; consolidation is frequently easier to defend in a budget review. Any honest assessment has to weigh both.
Best-of-breed versus consolidation: a decision lens, not a dogma
After all of this, the practical question for most teams is not "which thesis is correct" but "for this decision, in this organization, which way should we lean." I do not believe there is a universal answer, and I am suspicious of anyone who offers one. What helps is a small set of factors that tend to indicate whether composing best-of-breed pieces or consolidating onto a platform will serve a given organization better.
Lean toward consolidation when your data already lives substantially in one vendor's gravity well, when your governance and compliance obligations make "one auditable estate" worth a premium, when your team is small relative to the integration burden, and when predictable, plannable cost matters more than squeezing out the last efficiency. Lean toward composable, best-of-breed when avoiding lock-in is a first-order strategic concern, when you have genuinely heterogeneous data that no single platform can claim, when you have the engineering maturity to own the integration, and when a portable semantic layer would let you serve many surfaces — embedded apps, internal dashboards, agents — from one definition without re-implementing it.
A decision lens rather than a verdict: the conditions that should tip a given choice toward consolidation or composition — with the semantic layer as the constant.
Notice the band across the bottom of that lens. Whichever way you lean, the same investment pays off: a governed semantic layer. If you consolidate, it is the part of the platform you must take most seriously, because it is what lets you swap or add consumption surfaces without re-litigating every metric. If you compose, it is the spine that holds the assembly together and keeps the pieces honest. The semantic layer is the one decision that survives a change of mind about everything else, which is exactly why it is worth getting right before anyone argues about tools.
What this means for SAP Datasphere, SAC, and Joule
For organizations whose center of gravity is SAP, these two forces resolve into a fairly clear set of implications — provided you read SAP's recent moves as the consolidation play they plainly are, while staying honest about the splitting pressures that will not respect any vendor's boundaries.
SAP's positioning in one frame: consolidate the SAP estate around a Datasphere semantic layer, and use BDC Connect to share data products — rather than copy them — with Databricks, Snowflake, BigQuery, and, in public preview, Microsoft Fabric.
Datasphere is SAP's semantic layer — treat it as one, not as a warehouse
The most consequential mental shift is to stop thinking of Datasphere as "SAP's cloud data warehouse" and start treating its analytic models as the governed semantic layer for the SAP estate. In the architecture that BDC implies, every consumption surface — SAC stories, planning, Joule — should query Datasphere's models rather than reaching into raw tables. SAP's genuine differentiation here is not generic warehousing, where it competes with everyone; it is that this semantic layer can carry the business semantics already present in S/4HANA, the entities and hierarchies and master data that a neutral lakehouse does not get for free. If you are building on SAP and you let modeling logic sprawl back into individual stories, you are forfeiting the one advantage the platform gives you.
SAC is a consumption surface among several — and that is fine
The splitting pressure says the dashboard tool is becoming interchangeable, and SAP's own strategy partly concedes this by routing consumption through Joule and by making BDC, not SAC, the unit of sale. The healthy interpretation is not that SAC is diminished but that its job is clarified: it is the native SAP surface for exploration, storytelling, and — crucially — planning, which remains a genuinely differentiated capability that pure BI tools do not have. SAC does not need to be the only place SAP data is consumed; through BDC Connect and the broader estate, the same governed semantics can surface in other tools. Treating SAC as "the SAP-native consumption surface, especially for planning" rather than "the one dashboard to rule them all" matches where the market is going.
Joule is the agentic front door — its trustworthiness is a Datasphere problem
Joule is SAP's answer to the agentic consumption shift, with Joule Work as the front door across SAP and non-SAP applications, rolling out in phases since October 2026. Everything in the agentic section applies to it directly: Joule will be exactly as trustworthy as the semantic layer it is grounded in. That makes the quality, completeness, and governance of your Datasphere models not a back-office concern but the thing that determines whether business users can trust what Joule tells them. SAP's TechEd 2026 roadmap widens that grounding — customer-specific SAP Knowledge Graph context for Joule and BDC data products inside Joule Studio are both planned for general availability in Q1 2027 — which makes model and data-product quality matter more, not less. Organizations that invest in clean, governed analytic models will get a useful Joule; those that point it at ungoverned data will get confident, plausible, and wrong answers. The agentic front door does not reduce the importance of the semantic layer — it raises the stakes on it.
The open question: portability across estates
The honest tension for SAP-centric architectures is the same one the whole industry faces, sharpened. SAP's strategy is integration within its estate; the market's drift, embodied by Apache Ossie (the former Open Semantic Interchange), is toward portable meaning across estates. Most large enterprises will not be all-SAP, and they will increasingly resent re-authoring the same metric for SAP, for Fabric, and for Databricks. The strategic question to put to SAP — and to your own architecture — is how the governed semantics in Datasphere will interoperate with the rest of the data estate as common standards mature. BDC Connect already answers part of this on the data-access axis, with bidirectional, zero-copy sharing with Databricks, Snowflake, and BigQuery, and the Dremio acquisition brings Apache Iceberg and a catalog built on Apache Polaris into SAP's own stack — Polaris integration being one of the proposals on Ossie's roadmap. The semantic axis is the one still being written.
So — is business intelligence splitting?
Yes, and no, and the "and no" is the part most commentary gets wrong. Consumption is genuinely splitting and commoditizing: the dashboard is losing its monopoly to notebooks, embedded analytics, and a growing fleet of agents, and value is migrating down into the layers that hold meaning and trust. At the same time, storage and platform are genuinely re-consolidating: Microsoft Fabric, Databricks, and SAP Business Data Cloud are each absorbing the vertical stack into one estate, and the buying behavior of large enterprises, reinforced by FinOps pressure, keeps rewarding that. These are not competing predictions about the same thing. They are accurate descriptions of different layers moving in opposite directions at the same moment.
The semantic layer is where the two forces meet, and its trajectory is the most telling signal of all. It is being extracted into neutral products and simultaneously pulled into every platform's core — and then, with Apache Ossie, beginning to converge on a shared grammar that, under Apache governance, belongs to no single vendor. The layer is separating from the tools and unifying around a standard at the same time. If you want one prediction to organize around, it is this: the semantic layer is becoming the center of gravity of the entire stack, and the contest of the next few years is less about who owns the dashboard than about who owns — or whether anyone owns — the definition of a metric.
For practitioners, that resolves into advice that is almost boringly stable across both theses. Invest first in a governed semantic layer; for SAP estates, that means taking Datasphere's analytic models seriously as the semantic spine, not as a warehouse. Treat the consumption tier — SAC, Joule, and whatever agents follow — as important but interchangeable surfaces over that spine. Choose consolidation or composition by your own conditions rather than by the loudest narrative, knowing the semantic layer is the decision that survives either way. The question "is BI splitting?" is the wrong one to optimize for. The question that actually pays off is "where does the meaning live, and how well is it governed?" Get that right and you are resilient whichever way the rest of the market breaks.
Sources and further reading
- Open Semantic Interchange initiative — Snowflake (Sept 2025)
- OSI specification live, new working-group members — Snowflake (Jan 2026)
- Apache Ossie (Incubating): the new name for Open Semantic Interchange — Snowflake (Jul 2026)
- Ossie project incubation status — Apache Incubator
- Ecosystem — Apache Ossie (incubating)
- Open-sourcing MetricFlow under Apache 2.0 — dbt Labs (Coalesce 2025)
- Fivetran + dbt Labs complete merger — Fivetran (Jun 2026)
- AtScale open-sources the Semantic Modeling Language (SML) — Sept 2024
- Cube Core and Cube — Cube (May 2026)
- Cube Core — open-source semantic layer (GitHub)
- Unity Catalog Business Semantics: GA and open sourcing — Databricks (Apr 2026)
- Databricks launches Genie One — Databricks (Jun 2026)
- Databricks Data + AI Platform — Databricks
- Semantic views generally available — Snowflake Summit 2025 release notes
- Querying semantic views — Snowflake Documentation
- Looker opens its semantic layer via the Open SQL Interface — Google Cloud (Aug 2024)
- Looker updates for agentic BI at Next '26 — Google Cloud (Apr 2026)
- OneLake, the unified data lake — Microsoft Fabric
- Power BI pricing — Microsoft
- Microsoft Fabric pricing — Microsoft Azure
- Deprecating Power BI Q&A — Microsoft Power BI blog
- What is Tableau Agent — Tableau
- Tableau unveils the Agentic Analytics Platform — Salesforce (May 2026)
- Introducing Spotter, the AI analyst — ThoughtSpot (Nov 2024)
- ThoughtSpot Agentic MCP Server generally available — ThoughtSpot (Jul 2025)
- ThoughtSpot launches four BI agents — ThoughtSpot (Dec 2025)
- SAP BDC Connect for Microsoft Fabric announced — SAP News (Nov 2025)
- SAP BDC Connect for BigQuery generally available — Google Cloud (Jul 2026)
- SAP completes Dremio acquisition — SAP News (Jul 2026)
- SAP Analytics Cloud pricing (licensed via BDC core capacity) — SAP
- SAP TechEd 2026 innovation news guide — SAP
Attribution and sources: This essay is independent editorial analysis. SAP capabilities, release timing, and packaging reflect SAP's public communications and the author's advisory experience as of November 2026; non-SAP product claims are drawn from the vendors' own announcements and documentation as cited above. Roadmap dates and capability scopes are subject to change and should be verified against official vendor communications before high-stakes decisions. This content is not official SAP, Microsoft, Databricks, Snowflake, Google, Salesforce, Fivetran, dbt Labs, AtScale, Cube, ThoughtSpot, or Apache Software Foundation documentation.