July 30, 2026·Architecture

Microsoft IQ and Databricks Genie Are Chasing the Same Thing. Power BI Developers Already Have It.

fabric-iqgeniesemantic-modelgroundingagentic-ai

A customer came to me recently with what looked like a migration question. They were on Tableau and curious about Fabric, and they wanted to know what it would take to move their reports across. That is a reasonable question, but the conversation did not stay there. In about forty minutes it walked itself from moving a few reports to getting one place that answers every question the same way. We went from reports to scenario planning to threshold alerting to agents that reason about what happened and why. And every one of those steps was pulling from the same grounded definition of the business underneath.

The question was never really about reports. It was about where meaning lives, and whether the answers stay consistent no matter who or what is asking.

We have been here before. It is the same reason organizations centralized analytics in the first place. When a warehouse says profit was one number and a finance database says it was another, the disagreement does not stay contained. It travels up and down the chain, into board decks and forecasts and commission checks, and someone spends a week reconciling two numbers that should have been one. The fix was never a bigger repository. It was a single governed definition of what "profit" means, computed one way and secured one way and reused everywhere. In the Microsoft stack that definition lives in the Power BI semantic model. It is the measures and the row-level security and the exclusion filters that most report readers never see and always depend on.

Here is a version of the thing I mean, small enough to fit in a sentence:

Net Revenue =
CALCULATE(
    SUMX ( Sales, Sales[Quantity] * Sales[Net Price] ),
    Sales[Channel] <> "Intercompany"
)

That measure is not plumbing. It is a contract. It says intercompany sales do not count as revenue. It enforces that ruling on every visual and every export and now every agent that touches the model. The semantic model developer has been writing contracts like this for a decade while being described as someone who builds charts.

Which brings me to the two announcements that everyone read as competition and almost no one read as validation.

At Ignite 2025, Microsoft introduced Fabric IQ, an intelligence layer meant to let agents reason about the business rather than about raw tables. Seven months later Databricks shipped Genie One at its Data and AI Summit. Genie One is an agentic coworker sitting on top of Genie Ontology, a context layer that reads across an organization's tables and documents and tickets and chats to build a live map of what things mean. Two rivals and two flagship keynotes landed on roughly the same three-layer shape underneath. There is a semantic grounding layer, an agent on top of it, and a governance plane around it.

You can read that as a feature race. I read it as a concession. Both companies spent their biggest stage of the year telling you the model was never the bottleneck, and that grounding was the real one. The thing that decides whether an agent gives a trustworthy answer is not the size of the language model, it is whether the business meaning underneath is defined once and defended. That has been the argument on this site for a while, and it is a strange feeling to watch the two largest data platforms make it for you.

For the Power BI developer, this is the most validating news in years, and it is being covered as a product rebrand.

People are blurring two things here that deserve to stay separate. A semantic model and an ontology are not the same asset, and agents need both for different jobs. The semantic model reconciles values. It answers "what was margin last quarter" with one number, filtered and secured correctly. An ontology relates entities and carries actions. It answers "why did margin drop" by letting you traverse from margin to the specific product to the supplier to the shipment that was late, and then it defines what you are allowed to do about it. Microsoft's own documentation draws this line cleanly. Fabric IQ's ontology defines entities, their relationships, and the actions available on them. It lets agents follow a chain like Order to Shipment to a cold-chain breach to explain an outcome. The semantic model is not built for that traversal. The ontology is not built for consistent measures.

The ontology is not a rename of one semantic model, and it should not be. It is an abstraction that sits over several models at once, unifying the concepts that each one defines inside its own domain. The semantic model is the foundation. The ontology is the floor built on top of it, extending the foundation rather than replacing it. Microsoft lets you generate an ontology directly from semantic models already in production, so the layer everyone is racing to build starts from definitions you already govern. You are not starting from square one. You are starting from the part that is hardest to fake.

That is where the two grounding strategies split. There is a definition-first path where the ontology inherits meaning from a governed semantic model. There is a discovery-first path where meaning is harvested from raw tables and documents. Genie Ontology is explicitly the discovery-first version, reading across scattered sources to reconstruct what things mean. My bet is that discovery-first grounding quietly reintroduces the exact inconsistency the semantic model was built to remove, because reconstructing a definition from three systems that disagree gives you a confident answer, not a correct one. When only some of the data lives in some of the places, an agent grounded on the harvest cannot be right all of the time, and it will rarely tell you which time it was wrong. The teams who go ontology-first without a governed model underneath will, I think, spend next year rebuilding measure definitions they already had.

I could be wrong in a specific way, and I will say it plainly. If the harvest gets good enough to reconstruct a single consistent definition from scattered sources, and if it learns to abstain when the sources disagree instead of guessing, then the curated model stops being special and the developer's head start evaporates. That is the falsifiable version. It is testable, and I intend to test it.

None of this is abstract for the Power BI developer, because the path from a report to an operational system runs straight through the model they already maintain. Look at how the customer conversation actually laddered up.

The report stays. It is the retrospective view, and it is grounded in the semantic model. Scenario planning sits next to it, using the same measures for plan-versus-actuals instead of inventing new ones. Threshold alerting comes next, and this is where the model stops being retrospective. In Fabric you can set an Activator alert directly off a Power BI visual. You pick the measure and the condition and the action, all off the definition you already wrote. Then reasoning agents sit at the operational end, grounded in the same place so that when someone asks an agent a question and reads a dashboard an hour later, the two agree. That consistency is nearly impossible to guarantee when each surface grounds itself separately. It is close to free when they all ground from one model.

One grounded source feeding every consumer from reports to reasoning agents

So the question a Power BI developer should be asking on Monday is not whether to go learn ontologies. It is how the semantic models they already own can become accelerants for AI work without starting over. That is a question you can answer this week on a real model with a real usage export.

I have been doing exactly that with a prompt, run inside VS Code against a semantic model with the Power BI MCP server connected and a workspace-monitoring export attached. I generalized it from customer work into something you can point at your own model. Here it is:

You are helping me show business users how to get more from a Power BI report we
already have, without rebuilding the model.

Inputs:
- Semantic model: [name + link]
- Workspace monitoring / telemetry export: [attached]

Step 1. From the telemetry, identify the most-used measures, pages, and reports.
List them briefly, and focus everything that follows on those.

Step 2. Propose 3 to 5 ideas that move this report from retrospective use toward
operational use. Consider Activator for threshold questions and Foundry for
reasoning questions, but do not force an idea into either if a different pattern
fits better.

Step 3. Rank the ideas. Do not assume my priorities. Rank against ONE of the
criteria below and tell me which you used, so I can re-rank against a different
one if I disagree:
- revenue or cost exposure the idea addresses
- decision latency it removes (how much sooner someone can act)
- number of users or decisions affected
- effort to stand up

Step 4. For each idea, flag whether it works with the model as it stands today,
or needs a new measure, column, or relationship. Be specific about what is missing.

Constraints: skip low-level details. Do not discuss DirectLake vs import vs
DirectQuery. I am not tuning the model. These are working notes for me, not a
customer-facing deck.

Point it at a public model like Contoso Sales and the shape of what comes back is telling. The most-used page is a monthly revenue-by-region view, so the ideas anchor there. An Activator rule on the existing Net Revenue measure that fires when a region drops below its trailing threshold, and it works as-is. A reasoning agent that explains a regional dip by walking to the product and channel level, which needs one new relationship the reporting model never required. A plan-versus-actuals variance alert that reuses the same measures, works as-is. The value of Step 4 is that it separates the ideas you can ship Friday from the ones that need a small model change, and it does that honestly instead of quietly assuming a rebuild.

That last distinction is the point. Almost everything a Power BI developer needs to start operationalizing their reports is already sitting in the model. Some of it needs a relationship added. Very little of it needs to start over.

We spent years being told data is the new oil. The metaphor always undersold the hard part. Nobody builds a business on crude sitting in a tank. The value shows up when you refine it into something distributable, something the rest of the organization can pick up and use without a chemist standing next to them. The semantic model is that refinery. Turning raw tables into a governed, reusable definition of the business was never a reporting chore. It was the thing that makes both dashboards and agents trustworthy, and Power BI developers have been quietly doing it the entire time. Microsoft IQ and Databricks Genie did not change that job. They finally named it.

If you own a semantic model, you are not behind on the agent era. You are holding the part everyone else is trying to reconstruct. The move now is to stop treating it as report plumbing and start treating it as the grounding contract it already is.

I lead Microsoft-focused Data and AI work at iLink. I am writing here as a practitioner in my own voice. This is my read on how to think about grounding for agents. It is not a pitch for anything my employer sells.

Real-Time Dispatch is where I work through the operational boundary of agentic AI: live state, governed action, and the seams where they break. If that is your problem too, subscribe and argue with me in the comments.

Sources

← All writing