A report and a semantic model are not the same thing, and your AI agent only cares about one of them

Open Power BI, build something, hit publish. Two things appear in your workspace. One is called a report. The other is called a semantic model. Most people look at the report, recognize it, and never think about the second item again.

That second item is the one that matters.

I have watched this confusion play out in a lot of companies, and it gets expensive the moment someone tries to put AI on top of their data. They assume the dashboard is the asset. It is not. The dashboard is the wallpaper. The asset is hiding behind it.

The split nobody explains

Here is the cleanest way I have found to describe it. A report is a layout. It says: put this chart here, that table there, this slicer at the top. It holds no data and almost no intelligence. If your designer quit tomorrow you could rebuild the layout in an afternoon.

A semantic model is different. It holds two things. First, the relationships between your tables, the wiring that lets a customer row connect to an invoice row connect to a plant row. Second, the measures. A measure is a calculation written in DAX, Microsoft’s formula language, and it is where the real thinking lives.

Think about a number like gross margin percent. It looks simple on a tile. It is not stored anywhere. It is computed, and the computation has to decide which cost buckets count, whether to net out credits, how to handle a month with no sales so you do not divide by zero, and how the total should behave when someone filters down to one product. Get any of that wrong and the tile shows a confident, wrong number.

So the model is not a convenience layer. It is the accumulated set of agreements your finance and operations people made, over years, about what the words mean. Edgar Codd gave us the relational model in 1970. Ralph Kimball and Bill Inmon spent the 1990s teaching us how to shape warehouses so those agreements hold. A semantic model is where all of that lands in a Microsoft shop.

When you publish, you get layout plus logic. Report plus model. People see the first and inherit the second without noticing.

Why this lands hard once AI shows up

An AI agent is very good at the report. Ask it to lay out a summary, write the narrative, pick the chart, order the sections. It will do that quickly and often better than a human, because layout and prose are exactly what these models are built for.

The agent is not automatically good at the model. And the model is the part that decides whether the answer is right.

This flips the usual intuition. For years the dashboard felt like the hard, valuable thing, because building a good one took a skilled person weeks. The schema underneath felt like plumbing. AI inverts that. The layout becomes cheap. The semantic logic becomes the moat, the thing your competitor cannot copy by pointing the same model at the same prompt.

I keep coming back to a line I use with teams. The chart is not the product. The definition of the number is the product. AI makes that literally true.

The two doors, and the DAX question

This is where people get stuck, so let me be concrete. When an agent wants a number, it has two ways in.

Door one: ask the semantic model directly. To do that, the agent has to speak DAX. Specifically it has to produce a valid EVALUATE query, the kind the model can run. Microsoft’s own tools do this with a step they call natural-language-to-DAX. The Power BI REST API exposes an execute-queries endpoint that takes exactly that, a DAX query, and hands back rows.

Door two: skip the model and ask the warehouse in SQL. The SQL endpoint on a Fabric warehouse or lakehouse speaks ordinary T-SQL. No DAX involved.

So “does my agent need DAX?” has a precise answer: only if it goes through door one. And door one has a sharp edge. If the agent emits a sentence of reasoning instead of a clean EVALUATE block, the connector rejects it. That single failure mode is behind a lot of the flaky behavior people see when they wire an LLM to a Power BI model and watch it throw HTTP 400 errors. The model is not the problem. The agent is sending prose where a query belongs.

Door two has its own catch, and it is the interesting one. If you query raw SQL, who computes gross margin? If the answer is “the agent, on the fly,” you have handed the most delicate part of your business logic to a system that will cheerfully invent a slightly different formula each time. That is how you end up with three versions of the same KPI in one week.

The move that makes this calm

Here is the part I rarely see written down, and it is the whole point of this post.

You do not have to choose between “agent writes DAX” and “agent invents SQL math.” There is a third option, and most mature teams drift toward it without naming it. Push the measure logic down into curated SQL views. Bake the gross-margin formula into a view called something obvious. Now a plain-SQL agent selects from that view and gets the governed, agreed number, with no DAX and no improvisation.

I have seen exactly this in the wild, where a data lead had already, almost by instinct, written the margin formula into the view rather than leave it to whatever queried the table. That instinct is correct. It is the SQL equivalent of a DAX measure, and it travels anywhere SQL travels.

So the working pattern looks like this. Keep the semantic model as the canonical definition of every measure, the single place humans argue about what the number means. Then, for the agent, export those definitions into curated views and a short metric dictionary the agent can read. The agent writes simple SQL. The numbers stay correct. And the whole thing stops depending on a fragile DAX-generation step.

Why bother keeping the model at all, then? Because some calculations genuinely belong there. Time intelligence, year-over-year with the right calendar handling, running totals that respect filters, these are painful to reproduce in SQL and pleasant in DAX. For those, let the agent go through door one with a fixed query template, as a narrow exception rather than the default.

What this means for the next twelve months

If you are about to put an agent on your analytics, three things follow.

Inventory your semantic models before anything else. That is where your real intellectual property sits, and you should treat the measure definitions as a first-class asset, version them, document them, name an owner. Most teams cannot produce a clean list of their own measures, which tells you how invisible this layer has become.

Decide your door on purpose. SQL over curated views is the lower-drama path for most question-answering. DAX against the model is right when the metric needs the model’s machinery. Pick per metric, not per religion.

And stop measuring AI readiness by how nice the dashboards look. A gorgeous report on top of a vague model is a liability now, because the agent will read the vague model and produce vague, confident answers at scale. A plain report on top of a sharp model is the thing you want.

Running Tallyfy for over a decade taught me that the durable value in software is almost never the screen. It is the rules underneath the screen, the part users never see and never thank you for. Business intelligence is the same story. The report was always the easy half. We just could not tell, until something came along that could do the easy half for free.

The model is the half you were paid to get right. It still is.