Building a Fabric IQ Data Agent That Actually Answers Business Questions

If you've ever sat next to a finance manager who's trying to write a Power BI question and watched them give up halfway through, you already know why Fabric IQ matters. The promise of "ask your data a question in plain English" has been around for years. Most attempts have been disappointing. The difference with Fabric IQ is the ontology layer underneath it.

We've been running early Fabric IQ work with a few Australian clients, mostly in retail and professional services. The natural language piece is finally getting close to useful, but only because the ontology does the heavy lifting. Throwing a language model at raw tables still produces nonsense most of the time. Throwing it at well-defined entity types and bindings produces something a sales director can actually use.

This post walks through the data agent piece of the Fabric IQ tutorial - the part where you point an agent at your ontology and start asking questions. I'll explain what works, what's still rough, and a few things the documentation glosses over.

Why the Ontology Matters

Before getting into the agent itself, you have to understand why this is structured the way it is. Microsoft didn't bolt a chatbot onto Fabric. They built an ontology layer that lets you define your business in terms a human would use - stores, products, freezers, suppliers - and then bind those concepts back to the actual tables and columns.

So when a user asks "which freezer had humidity below 46 percent last week," the agent doesn't have to guess what table holds freezer telemetry. It already knows that a Freezer is a defined entity, that freezers belong to Stores, and that they have a humidity property bound to a specific column in a specific table.

This is the missing piece in most enterprise AI deployments we see. People connect ChatGPT or Copilot to a SQL database, expect magic, and get back queries that look right but reference the wrong columns. The model has no idea what your business actually means by "active customer" or "completed order." An ontology fixes that.

For more on how we think about structuring this work, see our Microsoft Fabric consultants page and our Business Intelligence work.

Creating the Data Agent

The setup is pretty mechanical. In your Fabric workspace, you hit + New item and pick Data agent. Name it something sensible - the tutorial uses RetailOntologyAgent, which is fine. If you can't see the data agent option in the menu, your tenant admin probably hasn't enabled it yet. That trips up almost every first-time setup we do.

Once the agent opens, you add a data source. This is where you point it at your ontology item (the tutorial uses RetailSalesOntology). Search, select, add. The ontology and all its entity types appear in the Explorer panel on the side.

This step takes about 30 seconds. The complicated work was building the ontology in earlier tutorial steps. Wiring the agent to it is genuinely simple.

One thing the docs don't tell you: when you first add the source, the agent isn't immediately ready to answer questions. There's an indexing and initialisation step that runs behind the scenes. If you fire off a query in the first minute or two, you'll get errors that say there's no data, which can be misleading. Wait a few minutes, try again, and it usually starts behaving.

The Agent Instructions Trick

This part is buried in the docs but it's important. There's currently a known issue where aggregation queries don't work well by default. The fix is adding a single line to the agent instructions: Support group by in GQL.

You add this through Agent instructions in the menu ribbon. Drop the line at the bottom of the input box and it applies automatically.

What's actually going on here? GQL is the graph query language Fabric IQ uses under the hood to translate natural language into structured queries over the ontology. Without the instruction, the agent doesn't reliably emit GROUP BY clauses when you ask aggregation questions like "top product by revenue." With it, aggregations work as you'd expect.

This is a workaround, not a permanent fix. I expect Microsoft to address it before general availability. But while you're in preview, every Fabric IQ agent should have this instruction set. We've added it as a default in our deployment checklist.

Asking Real Questions

Now the fun bit. The tutorial gives you two example prompts:

• For each store, show any freezers operated by that store that ever had a humidity lower than 46 percent.
• What is the top product by revenue across all stores?

The first question is interesting because it involves a relationship traversal. The agent has to understand that a Store operates Freezers, that Freezers have a humidity property over time, and that you want a filtered list grouped by store. A traditional NL-to-SQL system would struggle with this. The ontology makes it tractable because the relationships are explicit.

The second question is a classic aggregation. With the instruction we added earlier, it just works.

The responses come back referencing entity names, not column names. So instead of seeing dim_product.product_name and fact_sales.revenue_aud, you see Products and Revenue. That's the win. A retail manager can read the output without needing to understand the schema.

Where It's Still Rough

A few honest observations from working with this in production-ish environments:

Performance varies a lot with question complexity. Simple lookups come back in a couple of seconds. Multi-hop graph traversals with aggregations can take 30 seconds or more. We've had questions that took over a minute to return, which is borderline unusable for an interactive tool.

The agent sometimes hallucinates entity properties. If you ask about a property that doesn't exist on an entity type, the agent will occasionally invent one rather than telling you it doesn't know. We've seen it claim that Stores have a region property when the ontology doesn't define one. This is a problem because the answer comes back looking authoritative.

Errors are cryptic. When something goes wrong - a bad binding, a missing relationship, a query that times out - the error messages don't tell you what to fix. You end up trial-and-erroring through the ontology design. Fabric's logging has improved over the last few months, but it's still not where it needs to be.

You can't expose the agent externally yet. Right now the data agent lives inside Fabric. If you want to give a customer-facing app the same capability, you need to use the ontology MCP server approach, which is a separate setup.

Who This Is Actually For

I want to be careful about overselling this. Fabric IQ data agents aren't going to replace your BI team. They're good for one specific use case: letting business users explore well-defined data without having to write DAX or wait for a report.

If your data isn't already modelled cleanly, the ontology layer becomes the work. You'd spend three to six months designing entity types and bindings before the agent gives you anything useful. For most of our clients that's actually a feature, not a bug, because the modelling work has value on its own. But you have to know what you're signing up for.

Where this really pays off is in organisations that already have a strong semantic model - typically through Power BI - and want to give it a conversational interface. The ontology can build on top of what you've already done, and the data agent gives non-technical staff a way in.

For executive teams trying to figure out if this is the right path, we run short scoping sessions through our AI strategy consulting practice. The honest answer for some organisations is "not yet" - the value isn't there until your underlying data is in order.

What to Try First

If you're going to test this for yourself:

1. Start with a small, well-scoped ontology - one fact table, four or five dimensions, maybe ten entity types. Don't try to model the entire enterprise on day one.
2. Add the Support group by in GQL instruction immediately. Don't wait until you hit the aggregation bug.
3. Build a test set of 20 to 30 questions before you let business users near it. You need to know which questions the agent handles well and which it doesn't.
4. Set expectations clearly. This is a preview product. Things will break. Don't put it on a customer-facing surface yet.

We've been impressed enough with the direction Fabric IQ is heading to invest serious time in it, but it's still early. The data agent component is the most visible part, but the real architecture decision is whether to commit to building ontologies as a first-class artefact in your data platform. That's a longer conversation, and one worth having with your data team before you go too far down this path.

If you're working through this and want a second pair of eyes, our Power BI consultants and Fabric team have been running these projects across a few different industries. Happy to share what's working.

For the original Microsoft documentation on this step, see Create data agent in the Fabric IQ ontology tutorial.