For as long as software has existed, the user has been a person. You log in, you open an interface, you follow some workflow to get a piece of work done. The hardware changed — mainframes, then personal computers, then cloud apps in a browser — but the shape stayed the same. A human sat down and did the work, with the software there to speed parts of it up.
That assumption is now breaking. The emerging user of software is an agent. Claude, Codex, and others are logging into the same tools and doing the same legwork a person used to do. The end result is often identical — a ticket gets filed, a report gets built, a decision gets made — but the path to it is walked by an agent, and it happens far faster than it used to.
Business intelligence is software, and the same shift is coming for it. So the question we've been sitting with at Cube is a simple one: what does a BI platform look like when its primary user is an agent?
How BI actually works
To answer that, it helps to be precise about what BI is. Underneath the dashboards, BI is three connected workflows, and at any real scale each one has historically belonged to a different person — often a different team with a different skillset.
Data modeling is the technical foundation. A data engineer defines metrics, sets up relationships between tables, and prepares the views, cubes, and measures that everything else is built on. This is where the calculations and business logic live, encapsulated so they can be reused downstream.
Exploration is where a data analyst takes those modeled objects and looks for something worth knowing. They slice a specific cohort, apply filters, pivot, and view the data from different angles until an insight falls out — a number that takes the form of a report or a saved workbook sheet. Sometimes the model doesn't have what they need, so they either add a measure themselves or ask the modeling team to add it before they can continue.
Presentation is where those insights get assembled for an audience. An analyst combines reports into something shareable — usually a dashboard, with filters and time-grain switches so a broader group can explore within the story the dashboard is built to tell.
The artifacts that come out of these workflows — individual reports, or dashboards and data apps assembled from them — are what an organization actually runs on. A board reviews them to make a strategic call. An operator reads them to decide whether to reorder inventory, move stock between warehouses, or shift marketing spend. The three workflows exist to produce artifacts that someone — or something — can act on.
The new user is an agent
Now look at what agents are already doing in other software. An agent can read a recorded customer call in a CRM, break it into the specific problems the customer raised, and open the matching tickets in Linear or Jira. Another can read positioning docs in Notion, run a competitive analysis, and pull the keywords for an ad campaign. In a single session it picks up several tools, does the work, and lands on the result.
The result of that work hasn't changed much — at least not yet. There are still tickets in Linear and Jira, records in the CRM, code changes as pull requests. What's changed is who does the work, and how: an agent did it, autonomously, in a fraction of the time, and the sequence of tools it picks up can look a lot like the one a person would. That pattern doesn't stop at CRMs and docs. It applies anywhere the work is "log into a tool, change some state, produce an artifact" — which is exactly what BI is.
What that looks like in BI
Map the agent onto the three BI workflows and the trace is straightforward. Given a goal, an agent can:
- Update the ETL pipeline to bring in a new field.
- Update the transformation that shapes it.
- Update the semantic data model to expose it as a dimension or measure.
- Explore the model, slice it, and analyze it for insights.
- Assemble a dashboard and hand it to the humans for review.
That's the same path that has historically taken a whole team with different skillsets — data engineers, analysts — now compressed into a single session. And it can go a step further: with the insights from a report it just built, an agent can take the operational action directly — not just surface the recommendation but act on it.
This is where the artifacts earn their keep a second time. The report and the dashboard the agent produced along the way aren't just outputs; they're the audit trail. When you need to understand why an agent made a particular call, you have the full lineage — the model change, the exploration, the numbers it read — sitting there to inspect.
We don't need to build new roads
The encouraging part is that none of this requires reinventing BI. The infrastructure that made these workflows work for humans is the same infrastructure agents need:
- Data model SDLC. Branching, review, and CI/CD for changes to the semantic model, so an agent's edits go through the same controls a person's do.
- Security and governance. Permissions and row-level access that hold whether the query comes from a human or an agent.
- Lineage and context. A clear trace from raw data through transformations to the metric, plus the context an agent needs to know what a field actually means.
- Content permissioning. Controls over who — and which agent — can see and change a given report or dashboard.
- Interconnected, drill-downable artifacts. Reports and dashboards that link back to the model they came from, so a result is never a dead end.
That list is the semantic layer doing its job. It's also the thing that keeps agent-driven analytics honest. An agent left to infer definitions from column names will happily produce fifteen versions of "active customer." An agent working on top of a governed semantic layer uses the definition the data team already agreed on, which is what makes its answers trustworthy enough to act on — the same whether the analytics is for an internal team or shipped inside a product to customers. It's why we've always said the semantic layer is what makes the AI useful.
That doesn't mean there's nothing to improve. A new kind of actor, working at machine speed and volume, pushes on all of it — the interfaces, the performance, the guardrails — and there's real work to do there. But the fundamentals are in place. We don't have to build new roads for agents so much as open the existing ones to them, so an agent can make the same changes across modeling, exploration, and presentation that a person can, through the controls that are already there.
How we're building it at Cube
In practice that comes down to programmatic access to the platform across all three workflows, and it's what we're prioritizing on the product roadmap. It takes a few concrete forms.
More MCP tools. Cube already runs a remote MCP server, so an agent like Claude or Codex can connect and query the semantic layer where it already works. We're widening that surface — adding tools for agents to create and manage the objects and content inside Cube, not just read from them.
More API endpoints and an updated CLI. The same operations, packaged so they can be scripted and called directly. An agent shouldn't have to drive a UI built for a mouse when it can call the action itself.
These are active priorities rather than a finished story, and we'll be honest about that as we ship. But the architecture underneath — the semantic layer, the governance, the lineage, the artifacts — is already real, and it's what makes the rest tractable.
Where this goes
The shift from human users to agent users is the kind of platform change that rewrites software, and BI won't be an exception. We don't think the category disappears; we think it becomes something agents operate. Our goal at Cube is to let Codex, Claude, and the agents that come after them do the work a person does inside a BI tool today — model, explore, present — on top of a semantic layer that keeps the answers grounded.
If you're thinking about the same shift, reach out — we'd like to compare notes on what BI for agents should be.