Will we soon just talk to our data?

A Plainsight point of view. Why a strong semantic model matters more than ever.

The whole paper is below, free to read. Prefer it as a document you can pass around? Ask us for the PDF and we'll email it over.

The question

"Will we still be building dashboards, or will we just get our answers from a data agent?"

We hear this one in almost every conversation with clients now. The loud claims that dashboards are on their way out make it worth answering properly. This paper is based on the work we are doing with our first clients to set up chat with your data.

The honest answer, up front

You will be able to talk to your data more and more. But not by simply connecting a data agent to your data warehouse.

It works when the foundation underneath is solid. The difference is not the data agent itself, but how well you have prepared your data platform for it. That is the view this paper sets out, and it is a practical one: everything in it comes from work we are doing right now, not from a lab.

So will dashboards disappear? No. Companies have invested a lot in giving their teams fast access to recent data, and that removed a real hurdle: teams looking at outdated numbers, or reading the same data in different ways. Supporting decision makers with data, as fast as possible, stays the heart of BI.

We do not see talking to your data as a replacement for the dashboard, but as a way to give people answers even faster. Managers each want to track their own KPIs, and getting those today usually means the data team building a custom dashboard, which can take many meetings and a lot of time. With a data agent, a manager asks for the metrics they need directly, and the data team gets time back for deeper analyses.

The dashboard stays for what you monitor in a fixed, repeated way. The conversation picks up the many one-off questions that today fall through the cracks.

But for any of this to work, the data agent has to land on the right answer reliably. And that is harder than it sounds.

Why data is different from software

Solving a data question with a data agent is harder than solving a software problem.

For software, coding agents can be creative. Several paths can lead to a correct solution, and tests and documentation quickly catch a wrong result.

Data works differently. Ask how many customers you had last month, and the answer shifts with the filters and the viewpoint you take. A wrong answer looks just as convincing as a right one.

"How many customers did we have last month?"

All accounts, or only active ones? Which region? Which definition of a customer? Only one of those is what the person intended. And nothing flags it if the agent takes a different angle.

Point a frontier AI model at a raw enterprise data warehouse, without a described model to lean on, and roughly one question in five comes back correctly.[1]

So the real challenge is not running the query. It is whether the data agent can link a plain-language question to the right, up-to-date place in your data model. If it can, the rest is easy. If it cannot, it usually goes wrong in one of a few ways: the question is unclear and it picks the wrong field, the definition has changed and the answer is out of date, or the right information is there but never gets found.

We have to guide the data agent so well that it can hardly land anywhere but the right answer. And the questions people actually care about are rarely the simple ones. Picture two of your dashboards showing different revenues for the same product in the same month, and a manager asking the data agent to explain why. That answer is not sitting in any single table. It might be how each report defines its dates, a special rate buried in a contract, or a difference in which customers one counts. To answer it, the agent has to connect tables, documents and dashboards, and reason across all of them.

The rest of this paper is about the groundwork that makes that possible.

The semantic model, and the meaning above it

It all starts with a strong semantic model: the layer where you describe your tables, metrics and relationships, so the data agent knows what each one is for.

A model that is truly AI-ready has all of this clearly described, readable for a human and a data agent alike. When a question maps onto a defined metric, everyone in the company gets the same figure, with no room for interpretation. This is the core, and it is where our expertise lies.

But a well-described model is only the start. On top of it you need a second layer. A semantic model tells the data agent what exists: which tables and metrics there are, and how they connect. What it does not capture is what they mean. Why revenue is calculated a certain way. Which customers count and which do not. What a term means to one team versus another.

That meaning is captured in an ontology: a structured map of what your business means and how its parts connect. The term has been around for a long time, but it is now surfacing and gaining traction in the data world, because it gives the data agent the grip to not just find the right metric but use it correctly.

In plain terms: the semantic model says what exists. The ontology says what it means.

Two things keep this layer trustworthy. It has to stay up to date, because the moment a definition or table changes and the context does not follow, answers turn subtly wrong. And the definitions that matter need a human owner: AI can extract a first version and even judge which source is most trustworthy, but people still have to decide which version is the official one. AI helps build this layer. It does not get to make the final call on what is true.

Ground the same AI in a well-described semantic layer and accuracy on recent benchmarks runs to around 98%, up from the mid-eighties without one.[2]

You do not have to build all of this from scratch, either. Microsoft and Databricks, among others, are actively building ontology and context capabilities into their platforms. A growing part of this layer is something you can lean on your platform for.

Why this fails at most companies

The technology is rarely what breaks. Across our own engagements and the projects we get called into afterwards, the same five patterns keep coming back. Every one of them is avoidable, and every one of them is cheaper to avoid than to repair.

It is worth remembering the scale of the problem: 95% of enterprise GenAI pilots show no measurable impact on the bottom line. The gap is rarely the model; it is the foundation underneath it.[3]

1. The demo comes first. The foundation never follows. A chat interface on the warehouse makes a convincing demo in week one. Then finance asks why the agent's revenue differs from the board report, nobody can explain it, and people quietly stop asking. A pilot that skips the groundwork does not fail loudly; it just never gets trusted with a real decision.

2. The context goes stale. Definitions get written down once, at the start. Then a table changes, a metric is refined, and the context does not follow. Answers do not break; they turn subtly wrong. Anthropic reported their own accuracy drifting from around 95% to roughly 65% in a single month when context was not kept up to date.[4] Nobody had planned for maintenance.

3. The same word means three things. Sales counts customers one way, finance another, operations a third. People absorbed that ambiguity for years without noticing. The data agent inherits it and answers confidently anyway, with somebody's definition, just not necessarily yours.

4. Nobody owns the definitions. AI can draft what your terms mean and even judge which source looks most reliable. What it cannot do is decide what is official. Where that responsibility is never given to a person, three versions of "margin" live on side by side. Someone has to make the call, and it has to be their job.

5. The agent is asked what your analysts cannot answer. A useful test: if your own analysts could not answer a question today, because the data is missing or nobody trusts it, a data agent will not be able to either. What the agent really does is force the conversation most companies keep putting off: whether their data quality, processes and KPIs are good enough.

This is an organisation project, not an IT project

Adding the context a data agent needs turns out to be the ideal moment to line your definitions up across the organisation.

Over the years, business terms and abbreviations grow inside a company, often meaning different things to different teams. Setting up chat with your data, as we are doing with our clients, brings all of that to the surface. That is a feature, not a nuisance. The alignment you do for the agent is alignment your people needed anyway.

It works both ways: you give the agent the clarity it needs, and your teams start reading their numbers the same way. An organisation that agrees on what its numbers mean makes better decisions, with or without AI. We call it working towards a single source of thought, pushed from the data platform.

As for where to begin: the first step is not the most exciting, but it is the most important. Keep investing in a good data platform. For many organisations, this year is about fixing data quality and building robust semantic models, enriched with the context AI needs to find its way among all the tables.

You do not have to get it perfect at once. Start where the questions come most often and the decisions weigh heaviest, get your models and definitions right there, and build out from a small but tidy base. The value compounds: each domain you get right makes the next one easier, and the data agent more useful.

How we work

Plainsight makes data platforms AI-ready: robust semantic models, human-curated definitions and the data quality underneath them, built with your people rather than around them.

1. Find where the questions concentrate. We start with the questions your organisation actually asks: which decisions weigh heaviest, which numbers get challenged in meetings, where dashboards disagree today. That tells us which domain to make AI-ready first.

2. Model and define that domain, with your people. We build or strengthen the semantic model for that domain and sit your teams around the table to agree what each term officially means. AI drafts; your experts decide. This is where most of the alignment value is created.

3. Give every definition an owner, and keep it current. Each definition that matters gets a named owner, and changes in the platform carry through to the context the agent reads. This is the unglamorous part that decides whether answers are still right in six months.

4. Extend, domain by domain. With the first domain earning trust, we widen the base. Each new domain reuses what the previous ones agreed, so the work gets faster and the conversation with your data gets broader.

What shifts with AI is where the value sits: no longer only in building dashboards, but in capturing one shared, reliable meaning for your numbers and keeping it current as your business changes. That is the work. Not a chatbot, but the foundation a conversation with your data can really build on.

So, will we soon just talk to our data?

Increasingly, yes. But the quality of that conversation depends on the foundation underneath, and on how much your organisation agrees on what its data means. That is where the work begins.

Wondering how ready your own platform is? That is a conversation we are happy to have — get in touch, or read more about how we build data & analytics platforms and generative BI.

Sources

1. Spider 2.0 benchmark of AI models on real enterprise warehouses, ICLR 2025. A point-in-time figure; models improve, the gap to grounded set-ups remains.
2. dbt Labs semantic-layer benchmark, 2026: 98–100% accuracy with a governed semantic layer against 84–90% for the same questions without one.
3. MIT Project NANDA, "The GenAI Divide: State of AI in Business," 2025.
4. Reported by Anthropic on its own internal data agent, 2025.