Can we just bring back OLAP cubes?

Not the engines; the flow; the experience. MDX! Eh, probably not MDX.

Today's AI agents can write a full analysis of why your checkout rate dropped. They just can't reliably query your actual checkout rate. You need more than text-to-SQL and bigger clusters and better models to solve this - agents need grounding in the broader semantic context of your business. They need to know your event schema; the funnel event definition; that you changed your checkout event last week; that you had telemetry loss that one week in December.

That context is expensive to re-discover on every query. It lives in table names, grains, join keys, naming conventions, nullability, metric definitions, and a hundred bits of tribal knowledge that drift every time the data team ships a refactor. The query of today is not right when reused tomorrow; that fact is deprecated, that dimension redesigned. It’s not impossible to discover context on demand - the industry direction of trend. but it’s expensive to pay that cost every time.

We’ve been here before. When you wanted to give a business-savvy, math-literate person a way to slice and dice without understanding the warehouse underneath, you gave them Excel and SSAS: a pivot table and an OLAP cube. You could then get out of the way - the could still mess up formulas, make bad decisions - but the process of getting the raw business data was safe.

An OLAP cube distilled a business into dimensions and measures: a governed semantic layer defining what could be split by what, and how it could be aggregated. Agentic analytics is rediscovering a problem the BI already solved once: if you want fast, reliable self-serve analysis, you need governed semantics with performance enabled by precomputation and an accessible interface meeting users where they work.

If cubes are so good, why don’t they rule the world? They did for a time - call it the early 2000s? For all their flaws, they gave business users something remarkable: working self-service analytics. The UIs were clunky, building was hard, upkeep harder, skills esoteric. But behind the facade of a pivot table, all of that complexity disappeared. The business saw what mattered - speed, consistency, interactivity, excel integration**.

What killed the cube was the very thing it was supposed to tame - a flood of data. More volume, more granularity, fresher data, and faster-changing business questions. Traditional cubes could not keep up. Updates took hours; then days; then a week. Asks for new slices took too long; ad hoc questions could only be served by the database, undercutting the cube. Analysis moved into the warehouse; the lakehouse; the cloud.

The cubes that survived kept the interface but lost the engine. Most faded, locked into rigid UIs; engines that couldn’t scale across machines and ancient devx that scared off new developers and frustrated the business. Cubes fled to the traditional bastions of the business - finance, HR - and left the cutting edge of web analytics to the new platforms that would eventually devour them.

We do not need to bring back OLAP cubes as engines. We need to bring back what they gave us: a governed, high-speed, slice-and-dice interface over business semantics. Drilldown. Stable measures. Optimization - like aggregates- that scales behind the interface, instead of distorting it. An API that can power spreadsheets, charts, and applications without forcing every consumer to rediscover the warehouse from scratch.

Agents don’t need to know your warehouse. They need a list of dimensions, metrics and a business problem; a playground for a savant with the memory of a goldfish to slice and dice without a care for nullability, cardinality and cost. Give them a cube. Or something that slices like one.

**one of these may matter more than the other