NL2Ontology

A user types one line into the chat box: "who is hit by the Paris freezer breach?"

The AI agent answers in half a second. It names two companies, mentions a dozen cafés in the 9th arrondissement, and tells you to notify everyone within the hour. It reads like an answer from someone who checked the data. No one was warned by mistake, but only because the ops lead already knew that two of those names are not even customers.

Here is what really happened. The agent read an English sentence, and it wrote an English answer. In between, it never touched your data. It matched the words "Paris" and "breach" against everything it had ever read, then produced the sentence that sounded most likely. Sounding likely is not the same as being true, and none of those names came from a row.

That gap is the whole problem. An English question and a query you can run are two different things, and only one of them can be checked against your data.

Two roads out of one sentence

Give an AI agent a question and it can take one of two roads. The first road stays in language the whole way: a sentence goes in, a sentence comes out, and in the middle the model just recalls what is usually said. That road is fast and it reads well, but it cannot tell you when it is wrong, because it never looked at the data.

The second road converts the question. It reads the sentence and writes a query, something the system can really run against your data. Then it runs it. The answer is whatever the query returned, and nothing more.

Both roads start at the same English sentence. They split on one choice: does the agent answer from memory, or from a result? NL2Ontology is the name for choosing the second road on purpose.

This step is a conversion, not a paragraph

Think of it as three steps, in order. A question goes in: plain words a person would really type. A query comes out: structured, exact, and ready to run, with the entities and the filter written down so a machine can execute it. Then the answer is read straight off the result that ran.

The middle step is what keeps the answer honest. A free-text guess skips it and jumps straight from the question to an answer. NL2Ontology will not skip it. The question must first be turned into a query, and a query has one useful trait a paragraph never has: you can run it and get back exactly what is there, no more and no less.

That is also why the answer stops being creative. Once the rows are back, there is nothing left to invent. Two rows means two customers. Zero rows means say zero, not "probably a few."

Try it. Pick a question, watch it become a query, and see the exact rows it returns. Then reveal the free-text guess it replaces and read them next to each other.

MATCH (f:Freezer)-[:COOLED]->(s:Shipment)
      -[:CARRIED]->(o:Order)-[:PLACED_BY]->(c:Customer)
WHERE f.site = 'Paris' AND f.status = 'breach'
RETURN c.name, o.id

Notice what the guess and the grounded answer have in common: both sound confident. Confidence was never the signal. The result is.

The query layer with a name

In Microsoft Fabric IQ a data agent (Fabric's word for an AI agent grounded in your data) does exactly this natural-language-to-ontology translation, the step this page calls NL2Ontology. The plain question is turned into a structured query over your ontology and sent to the most efficient engine: GQL, the ISO-standard graph query language, when the data is a Fabric graph, and KQL when it is backed by Eventhouse. That query runs on your OneLake tables in place, and the agent answers from the result it gets back, not from the model's memory of similar questions. We show the step in GQL all through this page because the graph shape is the easiest way to watch it work.

It can write a real query only because the ontology sits underneath. The ontology already states that a Freezer cools Shipments, that Shipments carry Orders, and that Orders are placed by Customers. So "who is hit by the Paris breach" has something solid to map onto: the words point at those entities and those relationships, and turn into a graph traversal with a filter. Without the ontology there is nothing to map the words onto, and you are back to guessing.

The ontology lab copies this same structured-query mode. When you connect a model, the lab uses it to write the query. When you do not, a deterministic translator maps the words with fixed rules, so you get the same output every time and can watch the mechanism work with no key at all. Either way the pattern is the same: translate, run, answer from the result. One honest warning, because this is preview software: Fabric IQ is in preview as of July 2026, the exact surface will keep changing, and it carries no production guarantee yet. The idea underneath it will not change.

The one trap

Do not judge the answer by how it reads. A fluent paragraph and a grounded result look the same on the page, and that is exactly the trap: the wrong answer looks just like a right one. The question to ask is never "does this sound right." It is "did a query run, and is this answer the result of that query." If nothing ran, you have a guess, not an answer.

Turning the question into a query is half the job. The other half is making the agent answer from what the query returned and nothing else, even when it wants to add a likely-sounding detail. That habit has its own name, and it is where we go next: data agent grounding.