Fabric IQ & the intelligence layer

A retailer spent a year unifying its data. Every source moved into one place. Every metric matched. Every dashboard was green. Revenue by region, by month, by product: all correct and all fast. It looked like a full win.

Then the board asked one question. Which customers are we about to lose next quarter?

Nobody could answer it. The data was not missing. The purchases were there. The support tickets were there. The shipping delays were there. The problem was simple: no chart held the answer, and no chart ever would. "Which customers will we lose" is not a number you look up. It is a claim you have to work out step by step, across things that were never joined for that question.

The dashboard was perfect. But it was still a map. A map only shows the roads that someone already drew. This question was a road nobody had drawn.

A dashboard is still a map

Unifying your data is real progress. But it is not the last step, and the retailer is proof. They had one clean copy of everything and still got stuck, because clean data is not the same as data that knows what it means.

A dashboard answers the questions someone built it for. Sums, trends, and breakdowns across the fields it already holds. Ask it something that needs meaning it was never given, or a walk across things nobody connected, and it cannot help. The retailer did not have a data problem. They had a meaning problem, and more dashboards will not fix it.

The layer in the middle adds meaning

Here is what dashboards and raw tables both lack. Rows are built for machines. cust_id 42 and ord_id 101 mean nothing on their own. They mean something only when a layer says: id 42 is a Customer, id 101 is an Order she placed, and "placed" is a relationship you can walk. That layer is the middle layer.

This is what Microsoft means when it calls ordinary data "structures built for machines, not meaning." The middle layer is where the data stops being columns and starts being things: a Customer, an Order, a Shipment, connected the way the business really connects them. Once the meaning is shared, a person and a machine finally read the same data the same way.

So the intelligence layer is not one thing. It is a stack, and the order matters. You need one trustworthy set of data before you can attach meaning to it. You need shared meaning before an agent can reason instead of guess. Build it from the top down and the top has nothing to stand on.

Notice what the stack is really about: each layer depends on the one below it. Agents rest on meaning. Meaning rests on unified data. Skip a layer and everything above it becomes shaky. This is why "just add an AI agent" so often lets people down. An agent pointed straight at raw tables has no meaning to reason over. So it falls back to the one trick tables allow: answer what was modeled, and invent the rest.

The stack has a name, and it is Fabric IQ

Microsoft Fabric IQ is the full, production version of the same stack you just built by hand. The parts line up almost one for one.

One point to clear up first, because the names are easy to mix up. Fabric IQ is not itself Microsoft's intelligence layer. That layer is called Microsoft IQ, and Fabric IQ is one of four capabilities inside it. Each one carries a different kind of context: Work IQ for how employees work, Foundry IQ for an organization's policies and trusted documents, Web IQ for context from the web, and Fabric IQ for business entities and data. This page is about that last one. The split is worth knowing because the useful agents often need more than one: what your data says, what your policies allow, and how your people actually work.

At the base is OneLake, one governed copy of the data. Every layer above reads from the same source, so there are no rival copies to argue over. In the middle sits the ontology and the knowledge graph it forms: the shared meaning that says which rows are Customers, which links are relationships, and how a breach in one place reaches a customer in another. On top are the agents. Fabric calls an AI agent grounded in your data a data agent, and it answers you by walking that graph instead of guessing joins. Agents can also act on that live model, not just answer questions about it. When people say GraphRAG, this is what they mean: retrieval that walks a real graph of meaning, not just a pile of text.

One honest note. The three-layer picture here is our own teaching model, a way to see how the pieces stack. It is not official product naming that you should quote.

And the status is not one blanket label. It is different for each piece, and that is worth getting right because people quote it. As of July 2026 the graph engine is generally available, and so is the data agent. The ontology item and the IQ workload around it are still in preview. Pointing a data agent at a graph or an ontology as its source is also still in preview. So the base of this stack is production-ready, and the interesting part above it is not, yet. Check the status of the exact piece you plan to rely on, on the doc that owns it, rather than trusting one summary sentence, including this one. The shape of the stack, data then meaning then agents, is the part that lasts.

The one trap

Do not mistake unified data for an intelligence layer. Pulling every source into one clean place is the base of the stack, not the whole of it. The retailer had that and still could not answer the question that mattered, because the meaning layer above it was never built. If your plan stops at "get everything into one lake," you have poured the foundation and called it a finished house. The floors above, shared meaning and then agents, are the part that actually answers the board.

That foundation is worth getting right, because everything rests on it. Next: OneLake, the one governed place the whole intelligence layer stands on.