About a year ago I wrote that AI can write your semantic layer — read the tables in your warehouse, propose measures and dimensions, and keep building alongside you as the model grows. That's real, and Semantic Model Agent does it in Cube today.
Since then, software engineering has been moving through a clear progression: from one engineer supervising one agent, to orchestrating many agents that verify their own work, to supervised autonomy where agents continuously loop through entire classes of work in the background. The same shift is coming to analytics — and to semantic layers specifically.
What changed in software engineering
As models get better, the bottleneck moves from instruction to iteration. More of the code is generated, which leaves verification to the human — and the human becomes the constraint. You prompt, the agent says it's done, you check it yourself and report what's wrong, and you do that a dozen times before it actually works.
So validation moves into the loop too: the agent writes the unit tests, runs the end-to-end suite, and checks its own work in the browser before handing anything over. It keeps going against a fixed spec until the checks pass.
The second constraint is memory. Long-horizon work exceeds a context window many times over, and prompting can't solve that — the state has to live in the environment rather than in the model. Anthropic's write-up on harnesses for long-running agents describes the pattern: each session leaves artifacts behind for the next one — commits with real messages, a progress file, a list of what's done and what's still failing — and the next session starts by reading those and running the tests, so it picks up where the last one stopped instead of guessing.
Signals from both directions
A semantic layer sits between the data and the people asking questions of it, and a loop around it needs signals from both sides.
Upstream, the foundation moves. A pipeline adds a column, a transformation changes grain, a source schema gets renamed, a nightly load lands a fact table with a row count it hasn't had in ninety days. Each of those is a signal that part of the semantic layer may now describe data that no longer exists in that shape.
Downstream, consumption tells you what the model is missing. Query patterns show which measures get used and which have been dead for a year. The questions people and agents ask — including the ones the agent had to answer with an ad-hoc calculation because no governed measure existed — are a direct list of what belongs in the model and isn't there. The artifacts built on top say the same thing from another angle: which dashboards exist, which are still opened, and which broke the last time a definition changed.
Together, these signals give the system enough context to propose a change, validate it, and continuously improve the semantic layer without someone opening a ticket first.
What we're building at Cube
Designing agentic analytics loops is the core piece of our product roadmap right now, and I want to share some of the practical product changes and new features we're planning to release toward it.
Agentic development environment
Cube was built on the idea of applying software engineering best practices to data management. The semantic layer was designed code-first and under version control from day zero, and that's what enables review, testing, CI/CD, and the rest of the practices that came out of software engineering.
Now software engineering itself is being redefined by agents. One of the biggest trends there is giving agents sandboxed infrastructure of their own: a place to write code, test it, and propose merges into production. Cube has always had development environments for users, alongside staging and production.
We're extending that with environments for agent sessions. It enables multiple concurrent agents working on the same data model in parallel — each creating artifacts, testing them, and proposing merges to production. It's also where the state lives between runs: the branch, the artifacts, and the results of the checks stay in the environment, so a long-horizon job picks up what the previous run left instead of starting from an empty context.
Verification infrastructure
One reason agentic loops have been adopted so successfully in software engineering is that the verification infrastructure was already there, along with the practices built around it — everything from linting to testing to CI/CD checks. An agent can run all of it and find out whether its change is safe before a person ever looks at it.
At Cube we're investing in verification infrastructure for agentic analytics as well. We recently released Cube Evals, which benchmark the agent's answers against ground truth your team has written down, and we continue to improve them.
From there it's about expanding that surface and making it multi-layered. Cheap unit tests on the data model itself — does this measure return the right value at this grain, does this join fan out. And tests for the artifacts downstream of the model, since a report or a dashboard rests on definitions that can change underneath it and today nobody finds out until someone opens it. That would make verification infrastructure in analytics layered the same way it is in software engineering: unit tests on the model, checks on the artifacts built from it, and evals on the answers.
Closing the loop
We already have Agent Skills, scheduled jobs, and external MCP Connectors (Model Context Protocol). Together with agentic development environments and verification infrastructure, these are the building blocks for designing data engineering loops.
A scheduled job can be triggered either by a schedule or by an external trigger — an upstream data model change, a dashboard error. The trigger spins up a new agentic development environment where agents address the issue, run the content validator, make sure everything is safe, and propose a pull request to get merged.
We recently added the dbt integration, so the flow doesn't have to involve only Cube. dbt can be the source of the signal, and the agent can make changes to the dbt model when that's where the problem is.
Cube Agent already has access to query history, so it can run on a schedule to constantly optimize query performance, and to turn the ad-hoc calculations people write in Semantic SQL into governed measures. Once the primitives are in place and the integrations are connected, the use cases are limitless.
Agent-centric product design
Business intelligence is a decision support system, and historically it has supported decisions made by humans — strategic and tactical. More and more of those decisions are going to be made by agents, and we already see it happening. Not all of them, but the majority of tactical ones will be made predominantly by agents. The next generation of BI needs to be a decision support system for agents and humans.
The pattern of how humans use BI changes too. Even when a human is making the decision, they'll rely on agents to prepare the materials and do the analysis, and they'll consume it in read-only mode. That means the key product primitives BI historically had need to change.
The high-level application surfaces have always been the data model editor, the workbook, and the dashboard, following the key functions of BI: modeling, exploration, presentation. Those functions aren't going away, but they're going to be worked by agents. So humans need a way to review the artifacts that work produces — data model code diffs, reports, insights, dashboards — and to review them in the context of a specific agent session, whether that's an interactive one a human triggered or a background long-horizon job triggered by an upstream signal.
That's why we're changing the hierarchy of primitives in Cube's product design and making the human-to-agent conversation a first-class object on the application surface.
We'll be shipping these pieces over the next few releases. If you're designing something similar, or you have a class of data engineering work you'd hand to a background agent tomorrow, reach out — those conversations are shaping what we build next.
