Most enterprise questions do not live neatly in one place. The numbers may be in a warehouse, the rules may be buried in PDF files, and the explanation may sit in a support document that only three people know exists. A Microsoft Fabric data agent gives users a conversational way to ask questions across that information while keeping the answer grounded in approved enterprise data. I think of it as a configurable virtual analyst for a business domain, not a generic chatbot that happens to know a little SQL. Fabric Data Agents are now generally available, while some of the newer data sources, integrations, and advanced capabilities discussed later in this post are still in preview.
What is a Microsoft Fabric data agent?
You build that virtual analyst by connecting selected data sources and supplying the context it needs: agent instructions, data-source descriptions and instructions, a focused schema, and example question-and-query pairs where supported. When a question arrives, the agent considers the question, conversation history, available sources, and those configurations, then creates a plan and decides which configured data source, or combination of data sources, it needs to query. It runs under the caller’s identity, respects underlying source permissions, and generates read-only queries for supported structured sources. The result is returned as a human-readable explanation, table, or insight, with the generated query and run steps available for inspection. That transparency matters because “the AI said so” is not a very useful governance strategy.
Working with structured data
The most familiar Data Agent scenario is asking natural-language questions of structured data. Supported SQL sources include the SQL analytics endpoint of a lakehouse, a Data Warehouse, a SQL database in Fabric, and a mirrored database. At a high level, the built-in natural-language-to-SQL tool uses the selected schema, source instructions, and relevant example queries to generate T-SQL. Fabric validates that the query refers only to approved tables and views, executes it through the SQL analytics endpoint, and turns the results into a natural-language response. The standard runtime provides the generally available version of this flow and is the right place to begin for production scenarios that need predictable behavior.
Connecting a database is only the beginning. A good Data Agent needs a deliberately limited schema, clear business definitions, guidance about relationships and joins, and examples that demonstrate the query patterns people actually use. Otherwise, the model must infer too much from object names that were often created for developers rather than business users (Customer_Agg_02 probably made sense to someone). The more ambiguity you remove before the question is asked, the less guessing the agent must do afterward. Figure 1 shows the structured-data flow, including orchestration, SQL generation, validation, execution, answer generation, and the security controls that apply throughout the process.
Structured data does not have to come directly from SQL sources. A Fabric Data Agent can also use a Power BI semantic model as a source. In that case, the Data Agent uses natural-language-to-DAX (NL2DAX) to translate the user’s question into DAX, validates the query against the selected schema, and executes it against the semantic model. This can be especially useful when your organization has already invested in a well-designed semantic model containing trusted measures, relationships, hierarchies, and business definitions, because the agent can build on that curated semantic layer instead of starting from the underlying tables. Semantic models can be prepared for AI in either Power BI Desktop or the Power BI service using Prep data for AI, which stores AI Data Schemas, AI Instructions, and Verified Answers with the semantic model. These settings can then be reused by Fabric Data Agents and other Copilot experiences that work with the model.
Another structured source is an Eventhouse KQL Database, which is particularly useful for real-time, event-driven, telemetry, log, and time-series data. Instead of generating T-SQL or DAX, the Data Agent can use natural-language-to-KQL (NL2KQL) to translate a user’s question into KQL and query the Eventhouse. This opens up scenarios where the same Data Agent can reason over historical business data alongside operational events or telemetry, rather than treating real-time information as a separate analytical world.
Working with unstructured data through Azure AI Search
Many business questions depend on information that does not fit naturally into rows and columns. The Azure AI Search connection, currently in preview, lets a Fabric Data Agent use an existing search index built from PDFs, Word documents, text files, web pages, and similar content. The indexing pipeline is completed ahead of time; the Data Agent connects to the finished index rather than building it. In the Data Agent configuration for that index, you choose whether to use full-text search, hybrid search, or semantic search, along with how many document chunks to retrieve and context describing what the index contains and when it should be used. The agent retrieves the most relevant content, synthesizes an answer, and can provide citations when the index includes a URL or path field. Figure 2 shows how the finished index is queried and how the grounded answer is produced.
Letting the agent choose—and combine—the right sources
This is where Fabric Data Agents become much more interesting. A single agent can work across as many as five data sources, combining structured data from a Warehouse, Lakehouse, SQL database, or mirrored database; curated business logic from a Power BI semantic model; real-time and event data from an Eventhouse; relationship-oriented data from Graph or Ontology; and unstructured content exposed through Azure AI Search. Data source routing then helps the agent decide which source, or combination of sources, is most appropriate for each question.
The orchestrator uses signals such as the source name, description, selected schema, example queries, and any explicit routing rules in the agent instructions. It can call one source, review the result, and then call another when more information is needed. Azure AI Search participates through the context you provide for the index, so unstructured content becomes another governed tool available to the same agent. Figure 3 illustrates the larger pattern: one agent, multiple sources, and one grounded answer.
A practical example
Consider a repair-warranty question. The warranty policy may be indexed in Azure AI Search, while repair claims, failure codes, service-center details, dates, and costs live in a Fabric Data Warehouse. The agent can retrieve relevant policy passages, query the repair records, compare the rules with each repair, calculate the cost that appears to qualify, and explain which items need review. The final response can include document citations along with the Fabric source and query details, giving the user both an answer and a way to validate it. Figure 4 shows this pattern without pretending that either document search or a database query can answer the entire business question by itself.
Data Agents complement reports and dashboards
A Data Agent is powerful, but it is important not to confuse a conversational answer with a governed report. As I wrote in GenAI vs Dashboards: Not the Same (And Never Will Be), reports and dashboards are still the better choice when you need consistent, repeatable, auditable answers to known business questions. Data Agents are strongest when users are exploring, asking ad-hoc questions, or combining information that was never designed to fit neatly on a dashboard. In simple terms, use reports when you already know the questions and need the same trusted answer every time; use Data Agents when you want the flexibility to ask new questions and follow the data wherever it leads. The future is not Data Agents instead of dashboards. It is knowing when to use each one.
What is the difference between a Data Agent and Copilot?
The technology behind a Fabric Data Agent and Copilot is similar because both use generative AI to reason over data, but they are designed for different jobs. Copilot in Fabric is an assistant embedded in a Fabric experience that can help generate and explain notebook code or assist with queries. Copilot in Power BI can create or edit report pages, summarize reports, and answer questions about a report or semantic model. A Data Agent is a separately configured domain expert that works across selected sources, uses source-specific guidance and examples, and can be published for other people, applications, or agents to call. In simple terms, Copilot helps you perform work in the product, while a Data Agent provides an independently consumable Q&A capability over a defined data domain. Neither replaces the other, and the former direct connection between Copilot in Power BI and Fabric Data Agents was retired in August 2026.
Fabric IQ, integrations, and the Data Agent MCP server
Data Agents are part of the Fabric IQ workload, which is currently in preview, and they are also available as part of the Fabric Data Science workload. Fabric IQ provides shared business context across unified data, business intelligence, operational intelligence, and agents, making Data Agents a natural way to consume that knowledge. Publishing Data Agents to Microsoft 365 Copilot is generally available, and the current Microsoft Copilot Studio integration is also generally available. Integration with Microsoft Foundry and the Data Agent MCP server are still documented as preview. A published Data Agent can expose an MCP endpoint where the whole agent appears as one tool, and its description helps an outside orchestrator decide when that tool is appropriate.
What is coming next?
The roadmap is moving quickly, so pay attention to the runtime and feature status you are using. The preview runtime includes Advanced NL2SQL capabilities such as better example-query following, improved filter handling, schema object descriptions, and clarifying questions when a request is ambiguous. The preview code interpreter provides a sandboxed Python environment for calculations, statistics, forecasting, cross-source analysis, and Python visualizations, while preview Fabric visuals can return interactive charts in the Fabric conversation.
Graph and Ontology are also supported Data Agent sources in preview. Graph is useful when relationships between entities are central to the question, while Ontology adds business context by modeling entities, relationships, and organizational meaning on top of the underlying data. These sources extend the Data Agent beyond simply querying tables by giving it more information about how business concepts relate to one another.
My advice is to start with a narrow domain, curate the sources and instructions carefully, test the questions people really ask, inspect the run steps, and expand only after the answers are consistently trustworthy. The technology provides the reasoning, but your context is what makes that reasoning useful.
The post Microsoft Fabric Data Agents: Bringing Structured and Unstructured Data Together first appeared on James Serra's Blog.