There are a few ideas in data that seem to survive every new era, even if what we need from them changes. The semantic layer is becoming one of those ideas. It has been around for a while. Looker with LookML is probably one of the more familiar examples, and Cube has also been one of the notable players in this space.
In the BI era, semantic layers helped solve a fairly obvious problem: different dashboards, reports and analysts could arrive at different answers because the definition of a metric lived in too many places. As analytics moves into the agentic era, that same problem has not disappeared. The difference is that the consumer is no longer always a dashboard or someone writing SQL. It can now be an agent deciding what data it needs to answer a question.
Cube sits between the underlying data and whatever consumes it, but the semantic layer does more than define a set of metrics. Cube has traditionally framed that layer around four areas: data modelling, access control, caching and the interfaces used to consume the model.
The modelling starts with cubes and views. A cube usually represents a business entity or underlying dataset and contains measures, dimensions, joins and calculations, while a view sits on top of those cubes and exposes a selected part of that model.
That distinction becomes useful when the consumer is an agent. The cube can contain the actual calculation behind something like unique_users, while the agent only needs to know that unique_users exists, what it means and when it should be used. The fact that it is implemented as a distinct count over user_id does not need to become part of the agent's reasoning. The same applies to joins. If the relationship between orders and customers is already defined in Cube, asking for revenue by customer does not require the agent to inspect both tables and work out the relationship each time.
Views give you another level of control over that model. You do not necessarily need to expose every measure or dimension simply because it exists in a cube. A view can present a smaller surface that makes more sense for a particular consumer, which matters with an agent because more available context is not always better context.
Descriptions are part of this as well. A human analyst who has worked with a warehouse for a while may already know what an oddly named table or column represents. An agent only has the context it is given. A field called active_users is useful, but active_users with a description explaining what qualifies someone as active is much more useful. The semantic layer starts to translate the language of the warehouse into something closer to the language the agent can understand.
Cube's model is also code-first, with definitions written in YAML or JavaScript. That gives the semantic layer an explicit place in the development workflow rather than leaving those definitions inside whichever tool happens to consume them.
Access control sits at the same layer. The question is not only what revenue means, but also what part of the model a particular consumer should be able to access. This becomes more relevant with an agent because the set of queries is not predefined in the way it often is with a dashboard.
Caching and pre-aggregations deal with a different part of the problem. An agent can make several analytical queries while working through one user question. Cube can serve repeated analytical workloads through its caching layer rather than treating every request as a fresh query against the underlying warehouse. Cube has had this capability as part of the semantic layer long before the agent use case.
Then there is the interface into the model. Cube exposes the semantic layer through APIs and SQL, and newer agent integrations provide other ways into the same model. The interface can change without requiring the analytical definitions underneath it to change.
Another way I think about the setup is as a separation between knowledge and reasoning. The warehouse contains the data, the agent does the reasoning, and Cube sits between the two, giving the data enough structure and business meaning for the agent to work with it. The agent still has to understand the question and decide what to use, but it should not have to infer basic things like what a metric means, how two entities relate, or which field represents a business concept every time it queries the data.
None of these things were invented specifically for agents. That is partly what makes Cube interesting in this context. It was already providing a layer between the underlying data and its consumers. An analytics agent is another consumer of that layer.
The semantic model gives the agent the structure of the data, but there is still context that does not naturally belong in a measure, dimension or join.
Cube's agent setup allows additional context around the model through things like rules, certified queries and skills. A rule can guide how a question should be interpreted, a certified query can capture an analytical pattern that has already been reviewed, and a skill can describe a repeatable way of approaching a particular analysis.
The semantic model should still own things like definitions and relationships. The additional context has a different job. It can tell the agent how to use what has already been modelled, or give it guidance for situations that are difficult to represent cleanly as a measure or dimension.
That distinction matters because it would be easy to put business meaning everywhere once an agent is involved. If a metric has one definition in the semantic model, I would not want a rule or certified query quietly introducing another interpretation of the same metric. The additional context should make the semantic model easier to use, not become another semantic model sitting beside it.
Cube is a solid product, and I think the core offering is already enough for a lot of teams looking for a standalone semantic layer. The harder question for me is less about whether Cube does the job and more about whether another layer is necessary in the first place.
A lot of organisations will already be using platforms that are moving into the same space. Snowflake, for example, already has its own access-control model and is adding more semantic capabilities. The same is true for tools that started with transformation or data modelling as their core use case and are gradually moving further up the stack. At that point, bringing in Cube means adding another abstraction that needs to be maintained and kept aligned with the rest of the stack.
That becomes harder to justify at the scale a lot of companies actually operate. If the semantic layer genuinely needs to serve multiple warehouses, applications and agents, then having something independent starts to make more sense. But if most of the stack already sits inside one platform or tooling ecosystem, I would want a clear reason for adding another layer rather than using what is already there.
The question for me is not whether Cube is capable. It is whether the independence it gives you is worth the extra layer.
If your team is exploring AI analytics and wants to understand whether your data foundation is ready, our AI Readiness Assessment is a good place to start. Reach us at hello@datacult.com
