Artyom Keydunov

A few weeks ago I wrote that we should stop prompting AI to write our semantic layers and start building semantic layer loops instead. I got a lot of great feedback, and a lot of the same question: what does that actually look like in practice? It's the core of Cube's roadmap right now, so I wrote up the specifics of what we are building (more details in the blog post in the comments): 1/ Environments for agent sessions. Cube has always had dev, staging, and production. We're extending that so multiple agents can work on a data model in parallel — creating artifacts, testing them, and proposing merges. It's also where state lives between runs, so a long-horizon job picks up what the last one left instead of starting from an empty context. 2/ Verification infrastructure. Software engineering had linting, tests, and CI before it had agents, which is a big part of why loops worked there. We shipped Cube Evals to benchmark agent answers against ground truth, and from there it's about expanding that surface and making it multi-layered: cheap unit tests on the data model itself, plus tests for the reports and dashboards built on top — so verification in analytics ends up layered the way it is in software engineering. 3/ The loop primitives. Skills, scheduled jobs, and MCP connectors, triggered by a schedule or by a signal like a data model change or a dashboard error. A trigger spins up an environment, agents address the issue, validate, and open a PR. With dbt integration the flow isn't only Cube — dbt can be the signal, and the agent can change the dbt model. 4/ Agent-centric product design. BI has always been a decision support system for humans. More and more tactical decisions will be made by agents, so the next generation has to support both — which changes the primitives. The data model editor, workbook, and dashboard stop being where the work happens and become artifacts to review, in the context of the agent session that produced them.

Almost eight years ago, on September 16, 2018, Pavel pushed the first commit to the Cube open source repo. Cube started as a standalone semantic layer for embedded analytics. Then BI tools connected to it to ensure consistency — the same revenue number in Tableau, in Power BI, in whatever else the company had. Then AI showed up and enterprises stopped caring about that. Why invest in consistency across tools you're planning to retire? What they wanted instead was agentic analytics — internally for their own teams, and externally for their customers and partners. And putting an LLM directly on a warehouse doesn't work. Not because models are bad at SQL — they write better SQL than most people. They have no context. The industry turned to the semantic layer to fill that gap. So one market was being retired by AI while a much bigger one opened up underneath it. We shipped the first features in that direction under the “D3” preview, took it to GA, dropped the “D3” name, and Cube became fully focused on agentic analytics. It was the best growth year we've ever had. We've kept the same brand and the same colors since the first day of open source — never changed them once. The product and the market have moved enough that it's time the brand caught up. Today we're releasing a new look for Cube.

Where does the harness happen — or should I still carry the laptop half-open? I'm talking to a lot of founders and operators, and no one is quite sure yet where the harness ends up. Everyone is building the harness inside their own apps, and also opening those apps up to 3rd party harnesses — mostly Claude Desktop and Codex — via MCP, API, CLI. This is a good mapping of AI adoption: https://lnkd.in/gy5gEa_e Many companies I know are at the 2nd stage — "one engineer orchestrates 5–10 agents at once, each on its own worktree or git checkout, jumping between them." At this stage, mostly everyone runs agents locally. But as we move toward the next stages and go to 100 and then 1,000s of agents running the loop, we need to move the harness into the cloud. Claude's cloud scheduled tasks and routines are early primitives of that — they can run 1,000s of agents in a fully closed loop and kick themselves off. Scheduled tasks are general-purpose. Routines are already specialized for coding — kicked off by a schedule, an API call, or a GitHub webhook, on infrastructure built for that one workload. So a specialized harness is already showing up inside a frontier lab's own product. I'm wondering where the majority of the specialized cloud harness ends up — in super agents, similar to local, or inside domain-focused apps. The recent open weight momentum might be an additional argument for steering the industry away from one centralized frontier lab harness toward decentralized, domain-specific ones — each backed by a specialized model tuned off open weights, running inside the apps we already use.

Excited to launch Python Analysis at Cube! 🐍 Everything in Cube has always been a query against the semantic layer — a workbook tab, an Explore, a question you type into Analytics Chat. All of it resolves to SQL over the measures, dimensions, and definitions your team wrote and reviewed. And SQL reaches further than it gets credit for: cohort grids, retention curves, running totals, top-N within segment. Where it runs out is anywhere you need to fit a model instead of aggregating rows. A forecast with a confidence interval. A regression coefficient. A p-value from a significance test. Customers clustered into segments nobody labeled in advance. Someone on your team is computing that anyway — in a notebook, on a CSV export, on their laptop. Two weeks later nobody can re-run it, and nobody can tell whether the revenue column in that CSV was the same revenue as the dashboard next to it. Python analysis keeps that work in Cube. Attach a script to a tab and its input is that tab's semantic SQL result. The forecast is computed on the same numbers as everything else in the workbook, and it's a saved object other people can open, re-run, and put on a dashboard. Or just ask — tell Analytics Chat to forecast next quarter's revenue and the agent writes the Python, runs it, and saves it to a workbook. Link in comments.

About a year ago, I wrote that AI can write your semantic layer. 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. We need to build toward an agentic system that continuously runs a loop to improve the semantic layer. The loop needs signals from both upstream and downstream. Upstream signals include changes in ETL pipelines, transformations, schemas, and the data itself. Downstream signals come from consumption: query patterns, questions asked by people and agents, and the dashboards and other artifacts built on top of the data model—including whether they are actually used. Together, these signals give the system the context to propose changes, validate them, and continuously improve the semantic layer. Every industry is moving toward this autonomous future, and analytics will not be an exception. But autonomy only works if the loop can be trusted. That raises hard questions about data correctness, governance, security, and human review. Building this will require more than an agent that can generate data model code. It will require the infrastructure for a trusted agentic semantic layer loop.

In the last 12 months my personal workflow has changed more than it did in the previous 12 years. I used to log into a dozen products to get anything done — clicking through GitHub to configure CI, managing DNS records at my registrar, updating fields in the CRM by hand. Today I have Claude and Codex connected to all of those apps. I don't touch DNS records or CRM objects myself — I ask the agent to do it and report back. Performing actions, changing state, and updating configuration across products is increasingly going to happen through AI agents — whether a human instructs them or they're running inside self-improving recursive loops. And those agents need an efficient way to do it. That's why we invest heavily in MCPs, APIs, and a CLI at Cube. The goal: expose every action in Cube to these interfaces, so a Cube project or deployment can be 100% managed by AI. We shipped the new Cube CLI today — one command covering the entire public API. In our demo, a single Claude Code prompt goes from a Postgres database to a deployed data model and a working React dashboard.

Today we are (finally!) releasing our official dbt integration. We've had a Cube dbt Python package for a while to help sync dbt models into Cube, but it required a lot of setup and had limited functionality. I'm excited to bring the integration to the next level. Data modeling naturally comes in layers, and dbt is always a layer upstream from Cube. That layering is the foundation for the new integration. We now turn your dbt models into the base layer of the Cube data model, and let the data team build semantic models in Cube on top of it. When you change your dbt model, you can bring those changes into the Cube base layer automatically from a CI/CD trigger. Today we're releasing just one direction — getting models from dbt into Cube — but we envision this as bidirectional. It happens often: a measure or dimension starts in exploration, moves into the Cube data model, and at some point it becomes evident it belongs upstream in dbt. We want to make that flow seamless, and it's what we're working on next. Mikhail Nitsenko, our product engineer behind this feature, wrote an excellent blog post walking through it. Link in the first comment.

Every caching layer in analytics was designed for a dashboard. A dashboard asks the same handful of questions, at the same grains, over and over. You knew the queries before you built the cache, because the dashboard defined them up front. Agents don't work that way. They obviously generate more volume. But unlike deterministic dashboards, agents can get creative: they research, fan out, profile a column, check a cardinality, try a grouping, drill in, verify the number a second way. One user question becomes tens of queries. Nobody is going to argue with that. The part that actually breaks the cache is variety. It isn't just more queries. It's queries you never saw coming, in shapes you didn't plan for, chosen at runtime based on what the last answer happened to say. So how do you pre-compute for that? Back in 1996, it was framed as a data lattice problem: given a storage budget and a known workload, which aggregates do you materialize? Thirty years later that is still the decision every pre-aggregation system makes. And it still takes the same input — a known workload. Materialize everything and the combinatorics eat you alive. Materialize the wrong things and you've built a cache nobody hits. Dashboards obviously provide that known workload. But how do you get it when it's an agent querying your data? The semantic layer can not only give agents the right context about what to query, it can act as the foundation for the caching engine — describing the query space so it can build the optimal data lattice for pre-aggregations. Pavel Tiunov and Alexandr Romanenko wrote a piece on how we built this at Cube. Link in the first comment.

Semantic layer vs context layer? Everyone in data is talking about the context layer right now. Cube Core is the biggest open-source semantic layer, so I keep getting the same question: how does the context layer compare to the semantic layer — what's the difference, if any? The context layer came from a real failure: through 2024 and 2025, almost every company wired an LLM to its warehouse and expected "chat with your data" to just work. Mostly it didn't — not because the models can't write SQL, but because the agent didn't know whether "revenue" meant gross or net, which of three customer tables was the source of truth, or whether the person asking was allowed to see the rows. That's a context problem. But most of what people call "context" — catalogs, glossaries, lineage — only describes the data. It tells the agent about the data. It doesn't compute the answer or enforce who's allowed to see it. A semantic layer does, because you can query it. You define your metrics, dimensions, joins, and access rules once, in code. The agent just asks for a metric by name — in Cube, that's Semantic SQL — and the layer writes the query and applies the permissions. Catalogs and glossaries only describe the data; you can run a real query against a semantic layer, and that's what returns a correct, permitted answer. The context layer is the whole system — entities, ontologies, memory, docs, all pulled in at runtime over MCP — and the semantic layer is the executable core everything else gets assembled around. The diagram below is a simplified version of that whole system. The semantic layer, ontologies, and the other descriptive context are each exposed to the agent as a set of tools. On every run, the agent decides which tools to call and in what order — say, read the core concepts from the entities doc, search the semantic layer's data model, pull the relevant memories, then run a query against the semantic layer. That last step is the important one: it's the execution. Everything before it was just gathering context; the query is where the answer actually gets produced. After that, the agent can end the run or keep looping — to dig further, gather more, or take action with tools that do things: build a dashboard, send an email, update a system of record. If you're designing a context layer right now, start with the executable core. I wrote up the whole thing — where the semantic layer fits inside the context layer, and how the architecture comes together — on our blog. Link in the first comment.