When we started Cube, the idea was to take the semantic layer out of business intelligence tools and make it available to any application. The same definitions could serve dashboards, embedded analytics, and, increasingly, AI agents.
That separation is becoming more important as the number of data consumers grows. But making the model available everywhere creates an ongoing responsibility: keeping it useful and current as the business changes.
Building a semantic model has always been expensive. Maintaining it as sources, business definitions, and consumer needs change is the larger commitment. AI gives us a way to build a data model factory: a system that continuously develops and maintains the model using feedback from production.
Data consumption is growing faster than the foundation
Agents are making it easier to explore data, build dashboards, and add analytics to applications. Work that previously required a data-team ticket can now start with a question in a conversation.
The infrastructure underneath those experiences still needs to provide the right definitions, relationships, permissions, and performance.
OpenAI's write-up on its internal data agent illustrates how much work goes into that foundation. Its agent combines schema information, human annotations, context extracted from code, institutional knowledge, and memory. Some context is refreshed automatically; other context comes from people explaining what the data means.
All of that context has to evolve with the business.
Anthropic describes what happens when maintenance falls behind. In its self-service analytics write-up, the team reports offline accuracy drifting from roughly 95% to 65% over a month before it treated skill maintenance as an engineering problem. It began updating skill documentation alongside the data models those skills describe.
A successful initial deployment doesn't remove the need for ongoing data engineering. More consumption creates more opportunities to discover where the foundation needs to change.
A semantic model doesn't need to anticipate every question
A common argument against semantic layers is that data engineers cannot model every question someone might ask. I agree that they cannot, but a semantic layer shouldn't require them to.
Someone asking for revenue per order by region doesn't necessarily need a data engineer to add a new metric before they can get an answer. If revenue and order count already have governed definitions, a query language should let the consumer combine them.
We designed Semantic SQL to support that flexibility.
An agent can write a calculation such as:
The calculation uses the measures already defined in the model. Cube resolves those measures in the query's aggregation context and applies the caller's access rules. The resulting ratio can be part of an ad hoc analysis without first becoming a permanent field in the shared model. I've written about this approach before.
As I wrote previously, SQL gives consumers a familiar way to express analytical questions, but measures need evaluation semantics that ordinary table columns don't provide. Pavel's technical explanation of Semantic SQL goes into how Cube handles that through query rewriting.
This gives consumers room to answer questions we didn't explicitly model in advance. A calculation can remain local to an analysis. If it becomes widely useful, it can become a candidate for the shared model.
New business definitions still require work. If the company changes what counts as revenue, the system needs to incorporate that decision. That is a different problem from combining existing measures to answer a new question.
Data engineers are designing how that work happens
The data engineer's job is becoming less about writing every model change by hand and more about designing the system that carries out those changes. We've already seen a similar shift in software engineering: agents handle more implementation, while engineers define the intended behavior, provide context, and establish how the work will be checked.
That requires spending more time with business users and understanding their data needs. A schema won't tell an agent which customers count as active or why finance excludes a particular transaction type. Data engineers turn those requirements into definitions, examples, and tests the system can use.
At DoorDash, domain owners contribute and vet evaluations, including judging criteria for questions without a straightforward reference query. Their business knowledge helps define how the system's work is evaluated.
Automations can handle recurring classes of modeling work
A system maintaining the semantic model needs to observe both upstream changes and downstream usage. Schemas and pipelines reveal changes to the underlying data, while query history, conversations, errors, and performance reveal where the model needs to improve. We're already seeing frontier teams among our customers build parts of this system with Cube.
These teams already have agents inspecting logs for query errors and slow queries, preparing changes, and opening pull requests for review. The same pattern can be used to tune pre-aggregations: identify queries that would benefit, propose a configuration, and compare results and performance against the existing workload.
We're also seeing agents pick up scoped requirements from the backlog and implement model changes. A data engineer defines the business requirement and acceptance criteria, and a separate review process tests the implementation against those criteria.
Recurring ad hoc calculations provide another input. An automation can observe which calculations keep appearing and propose reusable metrics for the shared model, along with the usage and context supporting the proposal. A domain owner still needs to confirm the definition before it becomes shared business logic.
Conversation history can reveal missing descriptions or business rules that cause agents to misinterpret the data. An automation can identify those gaps and propose context updates for review. Anthropic already uses a scheduled agent to turn stakeholder corrections into documentation fixes, with pull requests going to domain owners. Those corrections also become evaluation cases, so subsequent changes can be checked against the same failures.
Each automation needs its own development environment and branch to make and test changes independently. That lets multiple automations run in parallel while producing changes people can inspect. The checks need to compare each candidate against the current model, verifying that it addresses the original problem without breaking other queries or answers.
At Cube, we're building toward a system that carries out more of this work in the background. In a follow-up, I'll go deeper into how the automations, development environments, and verification infrastructure fit together. Further out, these loops could extend upstream into the transformations that prepare the data.
