Let's start with a real use case: someone on the finance team needs unit sales this quarter versus last, by channel. They don't write SQL, so they file a request, and three days later an analyst sends back a spreadsheet, by which point the question has moved on. Every data team knows this loop. A data agent is the attempt to close it: let people ask the question in plain language and get a trustworthy answer back in seconds, straight from the warehouse.

This post is about the idea itself: what a data agent is, how it works, and when it's worth building. Over the rest of this series, we'll build a concrete one: a data agent over a Microsoft Fabric warehouse, one component at a time. But the concept comes first, because most data agents that disappoint do so for conceptual reasons, not technical ones.

What a data agent actually is

A data agent is a governed, natural-language layer over your data. You ask a question in English; it translates that question into a query in the source's native language (T-SQL for a warehouse, DAX for a semantic model, KQL for an event store), runs that query against your real data, and returns a human-readable answer. In Microsoft Fabric this is a first-class, configurable artifact that uses large language models to do the translation, and its SQL sources go through a built-in NL2SQL service, with NL2DAX and NL2KQL for the other source types.

The critical word is governed. A data agent isn't guessing at answers from a model's training data. It generates a query, validates that the query only touches approved tables and views, executes it read-only under the asking user's own permissions, and formats what comes back. The answer is grounded in a query you could run yourself.

How it works: the loop

Under the hood, every question runs through roughly the same loop:

1. Understand the question and, if the agent has more than one data source, decide which source can answer it (routing).
2. Generate a query (NL2SQL/NL2DAX/NL2KQL) using the schema, your instructions, and any example queries you've provided as context.
3. Validate the query against the allowed schema so it only references approved objects and is well-formed.
4. Execute it, read-only, through the source's query endpoint.
5. Format the result into a readable answer, often a table plus a short summary, and, in Fabric, expose the intermediate steps so you can see exactly how the number was produced.
   
   
   
   That last point matters more than it sounds. A data agent that shows its work is auditable; one that just emits a number is a liability.

The anatomy: what you actually configure

Here's the mental model that makes the rest of this series make sense. A data agent's quality lives almost entirely in the context you give it, and that context is a small number of distinct layers:

Only the first two rows are plumbing: picking a source and wiring up the connection. Everything below that is not code in the traditional sense; it's carefully written English and a handful of exemplar queries. That's the surprising part of building a good data agent: once it's connected, you spend far more time writing precise instructions and examples than wiring up infrastructure. The agent is only as good as the schema knowledge, definitions, and examples you hand it.

What a data agent is not

Setting expectations correctly is half the job:

• It's not a chatbot with opinions. It answers from your data via a query, not from general world knowledge. Ask it something your data can't answer and a well-built agent should say so, not improvise.
• It's not a replacement for your data model. A messy warehouse produces a confused agent. It surfaces your model; it doesn't fix it.
• It's not a causal analyst. "What were sales last quarter?" is in scope. "Why did sales drop last month?" is not; that's judgment and investigation, and Microsoft explicitly puts deep/causal analysis out of scope for the Fabric data agent.
• It's not deterministic for free. Because an LLM sits in the middle, the platform itself says it isn't meant for cases that require guaranteed, 100%-accurate results. You can push it a long way toward reproducibility (deterministic SQL patterns, tight instructions, tested examples), but that's engineering you do, not a default you inherit. (We devote Part 12 to exactly this.)

Grounding vs. hallucination

The reason a data agent can be trusted more than a raw chatbot is grounding: it doesn't recall a number, it computes one against live data and can show the query. The failure mode isn't usually invention; it's a plausible query over a misunderstood schema. The agent joins two tables that shouldn't be joined, or sums a column that means something other than you think, and returns a confident, wrong answer.

That's why most of this series is about removing ambiguity: describing joins that exist (and warning off ones that don't), defining every business term, and giving worked examples. Grounding is something you build, not something you get.

When to build one, and when not to

Build a data agent when most of these hold:

• You have a steady stream of ad-hoc questions that don't justify a dedicated report each.
• The questions are descriptive ("what/how many/which top-N"), not causal.
• Your data lives in a reasonably clean, well-modeled source you can describe precisely.
• Your audience is non-technical but data-literate enough to trust a number with its query shown.
• yjhmn6Read-only access is acceptable; no one is writing back through this.

Hold off when the opposite is true: the underlying model is a mess, every question needs pixel-perfect certified numbers, or what people actually want is investigation and narrative rather than figures. In those cases, fix the model or build a curated report first; a data agent on a shaky foundation just makes wrong answers faster.

Key takeaways

• A data agent turns natural-language questions into governed, read-only queries against your real data, and returns grounded, auditable answers.
• Its quality lives in the context you configure (schema knowledge, business definitions, and example queries) far more than in infrastructure.
• It is not a general chatbot, a fix for a bad data model, a causal analyst, or deterministic by default.
• The main risk isn't invented facts; it's a plausible query over a misunderstood schema, which is exactly what good instructions prevent.
• Build one for a stream of descriptive questions over clean, well-described data; hold off when the foundation isn't ready.

What's next

Next in the series: Setting Up Your First Fabric Data Agent on a Warehouse. We'll cover the prerequisites (capacity, workspace, warehouse endpoint, permissions), creating the agent, and connecting your first data source, so you have something live to configure as we go.

Sources

• Fabric data agent concepts (how it works, difference from a copilot): https://learn.microsoft.com/fabric/data-science/concept-data-agent
• Create a Fabric data agent (configuration, instructions, example queries): https://learn.microsoft.com/fabric/data-science/how-to-create-data-agent
• Add and configure data sources in Fabric data agent (source types, NL2SQL): https://learn.microsoft.com/fabric/data-science/data-agent-add-datasources
• Privacy, security, and responsible use of Copilot in notebooks and Fabric data agents (Responsible AI FAQ, intended uses and limits): https://learn.microsoft.com/fabric/fundamentals/copilot-data-science-privacy-security