AI Chat on a Classic Reporting Setup: Which Option Do You Actually Pick?

Star schemas in the gold layer, semantic models on top, and now the business wants to "chat with our data." The problem is not that Microsoft lacks an option. The problem is that there are five, all overlapping, several in preview, and all evolving fast.

The reporting side points at Copilot in Power BI. The warehouse side points at a Data Agent on the warehouse. Read anything recent and the answer is suddenly an ontology. Some teams go to Microsoft Foundry, either directly or with a Data Agent in between. Others skip all of it and hook up Claude or ChatGPT over MCP or the command line. It feels like several Microsoft teams built the same thing, all in preview, all slightly different. The real question is not which one is newest, but which one to actually pick, and when.

The most useful reply came from someone already running this in production. They implemented Fabric Data Agents, some on semantic models and some on gold views and tables, called the setup simple, and reported strong reviews from end users. That immediately raised the follow-up questions that matter: do users have meaningful multi-agent conversations with context carrying over, and which works better in practice, an agent on the semantic model or an agent on the views.

A recurring architectural point was about metadata. Semantic models carry their business context inside the model, descriptions, measures and synonyms, while plain OneLake tables do not carry column descriptions today. That is the difference between an agent that understands "revenue" and one that guesses. The comparison drawn in the thread was with Databricks Genie, which reads descriptions from Unity Catalog, so metadata has a single source that agents reuse. A Microsoft employee in the thread noted that schema descriptions for these sources are on the roadmap and coming soon.

The ontology conversation was the sharpest. One participant followed the Microsoft tutorial with a small model of two facts and ten dimensions. Their full daily medallion load runs in 10 to 15 minutes, but the ontology refresh does a full graph ingestion and takes around three hours. That led to a sensible question: is the right shape a wide but shallow ontology, mostly master data and selected cross-domain aggregates, while detailed facts stay in semantic models. Others agreed the harder open questions, where structured and unstructured data meet and how much manual curation each use case needs, are still unsettled. A few pointed to Azure Databricks Genie as the option to evaluate for Databricks-heavy estates, based on accuracy and performance in their own comparisons.

Reading the documentation, the five options are less a menu of competitors and more a set of layers, each grounded in a different place.

Copilot in Power BI grounds on the semantic model schema, the linguistic schema with synonyms, and field and measure descriptions. That makes it excellent for people who live inside reports, but it also makes model preparation the deciding factor: clear names, descriptions, a clean star schema, hidden helper fields, and the Prep data for AI step. It is nondeterministic, so a poorly modeled semantic model produces confidently wrong answers.

A Fabric Data Agent is the broader Q&A layer and is generally available. It supports up to five data sources in any combination: lakehouse, warehouse, SQL database and mirrored databases through NL2SQL, an Eventhouse KQL database through NL2KQL, Power BI semantic models through DAX, and, in preview, Graph, ontology, and Azure AI Search. A semantic model source reuses the model's measures and business logic but does not accept example query pairs, while SQL and KQL sources lean on instructions and example queries you provide. The agent respects Microsoft Purview DLP and access policies, and you can publish it to Microsoft 365, Foundry, Copilot Studio, and custom apps.

The ontology (preview) lives in Fabric IQ. It defines entity types, properties, relationships and rules, binds them to data in OneLake without moving it, can be generated from existing semantic models to reuse business language, and is queried through an NL2Ontology layer. Its cost is refresh: upstream changes need a manual graph refresh before they appear, which is exactly the scaling wall the community ran into.

Microsoft Foundry is where custom orchestration happens. A Foundry agent can consume a Fabric Data Agent as a tool, with identity passthrough so it queries only what the end user is allowed to see, or it can ground on a Fabric IQ ontology through Foundry IQ. That is the "direct or with a Data Agent in between" split from the thread, stated plainly.

The external LLM path is real and does not have to be ungoverned. A published Fabric Data Agent exposes a single MCP tool, and any MCP client, a script, Visual Studio Code, or a Claude or ChatGPT style client, can call it with a valid Fabric bearer token. Routing an external model through the Data Agent MCP server keeps answers grounded and permission-aware, which is very different from pointing an external model straight at the raw database.

The options are not really competing. They are layers, and they differ mainly in where the business context comes from. Treating "chat with our data" as a product choice is the mistake. It is a metadata question.

Start where the business language already lives, which is your semantic models. A Fabric Data Agent on those models inherits the measures, relationships and descriptions you already curated for reporting, and that is precisely why the production success in the thread came from that setup rather than from raw tables. Add Copilot in Power BI for the people who work inside reports all day. Expose the agent over MCP when a team wants to reach it from Claude, ChatGPT or the command line, and keep it flowing through the Data Agent so Purview policies and per-user permissions still apply.

"This is not a tooling contest. It is a question of where your metadata lives."

Reach for an ontology only when questions genuinely cross domains and depend on relationships a single semantic model cannot express. And go in with the refresh cost in mind: if a daily medallion load finishes in 10 to 15 minutes but a full graph ingestion takes three hours, a deep ontology over every fact will not keep up. A wide but shallow ontology, master data and selected cross-domain aggregates, with detailed facts left in semantic models, is the pragmatic shape today.