Traversal

A freezer breaks down in a warehouse. The ops team asks one question: which customers are about to get a bad shipment?

No table has that answer. The freezer knows its own temperature. A different table knows which shipments it cooled. Another knows which orders were on those shipments. Another knows which customer placed each order. The answer is real, but it sits scattered across four tables. Joining them by hand means a four-way join nobody wants to write while the freezer is still warming up.

Traversal is walking that chain automatically: freezer, to shipment, to order, to customer. Follow the edges and you get the answer.

An answer can be a path

Look at the question again. "Which customers are hit by this breach" is not a fact you look up. It is a route you follow, one hop at a time, each hop crossing into a different part of the business.

Each arrow is a relationship you already built and bound. The power is that you can chain them. One hop answers "which shipments." Two hops answer "which orders." Three hops answer "which customers." No query was written for this exact question. And yet the answer is right there. You just walk to it.

Step through it yourself.

One breach, two customers at risk, found by walking three hops. Now picture the same walk across a million nodes, and you have the thing tables were never built to do.

Why this matters for an AI agent

This is the whole payoff, the reason the entities and keys and relationships were worth the effort.

On plain tables, an AI agent can answer questions someone already modeled. "How many orders did Acme place" is one join, easy. But "which customers are affected by freezer F-02" crosses four domains that nobody joined together in advance, so the agent either cannot answer it or quietly makes something up. Give it a graph and it can traverse the relationships on demand and reach an answer no one planned for.

This is exactly what a semantic model cannot do. A semantic model is built for the questions you planned for. Traversal is for the questions you did not. This split is clear and it lasts: an agent that reports versus an agent that reasons.

Where the walk happens in Fabric

In Microsoft Fabric, this is what the data agent does, Fabric's name for an AI agent grounded in your data: it walks the ontology's relationships to answer you, instead of guessing a join. Those walks are what it shows you as evidence.

Underneath, multi-hop reasoning runs over the ontology graph. A query walks real relationship edges instead of guessing joins, and the path it walked is the explanation. The graph is queried in GQL, the ISO-standard graph query language, and it runs over your OneLake tables in place, with no export to a separate graph database. Microsoft documents the graph as supporting that standard. That is a claim about alignment, not proof of full conformance, so support is still being filled in.

One status note, and it is not the same for every piece. As of July 2026 the graph engine is generally available, and so are the data agent and the Power BI semantic model. The ontology item is still in preview, and so is pointing a data agent at a graph or an ontology. Check the status of the piece you actually plan to use.

The one trap

Do not confuse a traversal with a bigger join. A hand-written four-way join answers one question you already knew to ask. Traversal is the ability to answer questions you have not thought of yet, by walking whatever path the question needs. The value is not the single answer. It is that every future question becomes a walk instead of a new engineering project.

And that is the moment the whole model comes together. Entities, instances, relationships, edges: connect them and you have a knowledge graph, the thing an AI agent walks to reason over your business. That is where this is all heading.