Microsoft Fabric Data Agent — Complete Guide (2026)
How to set up, configure, and deploy the Fabric Data Agent — covering supported data sources, response limits, service principal authentication (preview), Copilot Studio and Microsoft Foundry integration, governance, and confirmed limitations. Verified against official Microsoft documentation through June 2026.
The Microsoft Fabric Data Agent is a conversational AI interface that lets users ask natural language questions against Fabric data sources — Lakehouse, Warehouse, KQL databases, and Power BI semantic models. You connect up to 5 data sources per agent. Responses are capped at 25 rows and 25 columns. The agent publishes an API endpoint callable from Copilot Studio, Microsoft Foundry, and custom apps. Requires F2 or higher Fabric capacity. Currently in public preview with service principal authentication added in June 2026.
The Microsoft Fabric Data Agent is currently in public preview. Response results are capped at 25 rows and 25 columns. Service principal authentication was added as a preview feature in June 2026. Features and limitations will change as the product moves toward general availability. Verify current status at Microsoft Learn before any production deployment.
What Is the Microsoft Fabric Data Agent?
The Fabric Data Agent is a conversational AI layer built on top of your Fabric data sources. You configure it with data source connections and instructions, publish it, and users interact with it through a chat interface — asking questions in plain English and receiving answers drawn directly from your governed Fabric data.
Under the hood, the agent uses Azure OpenAI Assistant APIs to parse each question, check user permissions, generate the appropriate SQL or KQL query, execute it against the connected sources, and format the result. Every step respects your existing row-level security, Purview governance policies, and workspace boundaries.
The agent is distinct from a dashboard or a report. It does not visualise data — it answers questions about it. Think of it as a governed, permission-aware query interface that anyone on your team can use without SQL knowledge.
Fabric has two AI agent types that are easy to conflate. The Data Agent is reactive — users ask questions, it queries data sources. The Operations Agent is proactive — it monitors KQL databases on a 5-minute cycle and pushes recommendations to Teams. They solve different problems and can be used together in the same architecture.
The 25-row response cap is the most common source of confusion when teams first deploy the Data Agent. It is not a bug — it is by design. The Data Agent is built for conversational insights, not data exports. If your use case requires returning full datasets, the right tool is a notebook, a pipeline, or a direct SQL endpoint — not the Data Agent.
Fabric Data Agent — Supported Data Sources
The Data Agent connects to data sources within your Fabric workspace. You can connect up to 5 sources per agent. Each source type has specific permissions and configuration requirements.
| Data Source | What the Agent Queries | Permission Required | Supported |
|---|---|---|---|
| Lakehouse | Delta tables via SQL analytics endpoint | Read access on the Lakehouse | ✅ Yes |
| Data Warehouse | Tables and views via T-SQL | Read access on the Warehouse | ✅ Yes |
| KQL Database | Tables via KQL queries | Read access on the KQL database | ✅ Yes |
| Power BI Semantic Model | Measures and tables via DAX | Read (Write not required) | ✅ Yes |
| External databases | Not directly accessible | Mirror to Fabric first | ❌ No |
| Shortcut tables | Depends on shortcut type | Varies | ⚠ Partial |
| SQL Database in Fabric | Tables via T-SQL | Read access | ✅ Yes |
Each Data Agent can connect to a maximum of 5 data sources. If your use case spans more than 5 sources, create multiple specialised agents — one per domain — rather than a single agent trying to do everything. Specialised agents also produce more accurate answers because the context is narrower.
Schema Quality Directly Impacts Answer Accuracy
For each connected source, the agent reads column names, table names, and any descriptions you provide. Ambiguous column names like col_a or val1 produce poor query generation. Descriptive names like net_revenue_usd or order_status_code produce reliable results. Time spent on schema documentation pays back in agent accuracy.
You can provide up to 100 example queries per data source. These are the highest-impact investment in agent quality — real questions paired with correct expected answers teach the model how your business actually talks about its data.
How to Set Up the Fabric Data Agent
- F2 or higher Fabric capacity (or P1 Premium with Fabric enabled). Trial capacities are not supported.
- Admin or Member role in the Fabric workspace where the agent will live.
- At least one Lakehouse, Warehouse, KQL database, or Power BI semantic model in the same workspace.
- Copilot and AI features enabled at the tenant level by a Fabric admin.
- Read access to all data sources you intend to connect.
- Open your Fabric workspaceNavigate to your workspace in the Fabric portal. Confirm your capacity is F2 or higher — the Data Agent item will not appear on Trial capacities.
- Create a new Data Agent itemSelect + New item → Data Agent (under AI + Machine Learning). Give it a name that reflects the domain it covers, such as “Sales Analytics Agent” or “Finance Q&A Agent”.
- Connect data sourcesAdd up to 5 data sources. For each source, select specific tables rather than connecting entire databases — this keeps the agent’s context tight and improves query accuracy.
- Add table and column descriptionsFor every table you connect, add a plain-English description of what it contains. For ambiguous columns, add inline descriptions. This is the single most impactful step for answer quality.
- Write agent instructionsDefine how the agent should interpret questions — which source to prefer for which type of query, what business terms map to which columns, and any compliance constraints (e.g. never surface PII columns). See Section 04 for detail.
- Add example queries (up to 100 per source)Provide real business questions with the correct expected SQL or result format. Examples are the highest-signal training input — use actual questions your team asks, not generic demos.
- Test in the chat interfaceAsk the agent your real questions. Check that table joins, filters, and metric calculations are correct. Refine instructions and examples based on failures before going further.
- Verify governance settingsConfirm that RLS filters on your data sources are working correctly. Test with accounts from different roles to confirm each user sees only their permitted data. Purview DLP policies are automatically enforced — verify none will block expected queries.
- Publish the agentPublishing generates the API endpoint. This endpoint is what Copilot Studio, Microsoft Foundry, and custom applications call. Copy the workspace_id and artifact_id from the URL — you’ll need them for integrations.
- Share accessGrant users Read permission on the agent item and on its underlying data sources. Both are required — access to the agent alone is not sufficient.
Writing Effective Data Agent Instructions
Agent instructions are plain text that you provide during setup. They define how the agent interprets ambiguous questions, which source to prefer for which query type, and any business rules or compliance constraints the agent must follow.
What to Cover in Your Instructions
Define Your Key Metrics
- Revenue = net_revenue_usd (after returns and cancellations)
- Margin = (net_revenue – cogs) / net_revenue × 100
- Active customer = purchased within last 90 days
Map Source Priority
- For current-month data: use the Lakehouse (refreshed hourly)
- For historical trends: use the Warehouse (optimised for aggregations)
- For pre-calculated KPIs: use the Power BI semantic model
Define Synonyms
- “Revenue” = net_revenue_usd
- “Orders” = transactions table
- “Customer” = unique_account_id
- “SKU” = product_code
Set Compliance Rules
- Never surface columns: email, phone, ssn, dob
- Flag results where row count is below 10 (anonymisation risk)
- Always round financial figures to two decimal places
Agent instructions shape how the model interprets and responds to questions — but they do not enforce data access. Real security comes from RLS on source tables, Purview DLP policies, and workspace permissions. Never rely on instructions alone to hide sensitive data. Enforce access at the data layer.
The most common instruction mistake is writing them too broadly — something like “answer questions about sales data.” That tells the model nothing useful. The instructions that actually improve answer quality are specific: column-level definitions, source-priority rules for edge cases, and explicit handling of known ambiguities in your schema. Treat instructions the same way you would treat a data dictionary — specific, precise, and reviewed by someone who knows the data.
Authentication, API Access & Service Principal Support
Authentication Model
The Data Agent enforces the calling user’s identity for data access. When a user asks a question, the agent queries the underlying sources using that user’s permissions — so RLS and object-level security apply automatically based on who is asking, not who configured the agent.
| Authentication Type | Status (June 2026) | Use Case |
|---|---|---|
| Delegated user token (interactive) | ✅ GA | In-product chat, direct user sessions |
| Service principal authentication | 🔶 Preview | Backend apps, automated workflows, Microsoft Foundry production deployments |
| Managed identity | ❌ Not supported | — |
Service principal authentication for the Data Agent was released as a preview feature in June 2026. Applications can now authenticate to the Data Agent using their own app identity — no user sign-in required per request. This unlocks backend services, shared-backend multi-user apps, and production Microsoft Foundry deployments where requiring a delegated user token was a blocker.
Calling the Data Agent API
Once published, the Data Agent exposes an API endpoint. The URL contains two identifiers you copy from the agent’s URL in Fabric:
- workspace_id — the GUID of your Fabric workspace
- artifact_id — the GUID of the Data Agent item
The agent is callable from Copilot Studio as a plugin, from Microsoft Foundry as a tool using MicrosoftFabricAgentTool, and from custom applications using the Azure AI Projects SDK. SDKs are available for Python, TypeScript, and JavaScript. The Fabric Data Agent and the Foundry project must be in the same tenant.
Integrations — Copilot Studio, Microsoft Foundry & Teams
Microsoft Foundry Integration
The most common production pattern uses the Fabric Data Agent as a tool inside a Microsoft Foundry agent. The Foundry agent handles multi-turn conversation, orchestration logic, and the user-facing experience. The Fabric Data Agent handles grounded data queries — returning accurate, permission-aware answers from your enterprise Fabric sources.
During development, interactive browser authentication works. For production deployment to a web app or custom application, service principal authentication (preview, June 2026) is required — the application authenticates with its own identity rather than routing every request through a user sign-in flow.
Copilot Studio Integration
You can register the published Data Agent endpoint as a plugin inside Copilot Studio. Users interact through Teams or a web interface — Copilot Studio handles the conversation layer, and the Data Agent answers data-specific questions. This pattern works well for broad enterprise rollouts where the Data Agent covers one domain inside a larger company-wide assistant.
Teams Direct Access
For simpler deployments, the Data Agent can be accessed directly from within Fabric’s chat interface, shared as a workspace item, or embedded in Teams through Copilot Studio without building a custom application. This is the fastest path to getting the agent in front of users.
The June 2026 Fabric update improved the Data Agent orchestrator’s ability to route queries to the correct data source, particularly in multi-source configurations. If you previously noticed the agent consistently querying the wrong source for certain question types, updating your instructions to reflect source priority is worth revisiting after this update.
Fabric Data Agent vs Operations Agent
These two agent types are often confused because both carry the Fabric “agent” label. They solve completely different problems.
Use both together when your use case includes both reactive analytics and proactive monitoring. The Operations Agent fires an alert when an anomaly is detected; the Data Agent helps the team investigate by answering follow-up questions about the underlying data.
Fabric Data Agent — Confirmed Limitations (June 2026)
These are confirmed, current constraints from official Microsoft documentation. Plan around them before deployment.
The Data Agent is not generally available. Feature behaviour, response limits, and authentication support will change as the product evolves. Check the official concept page and the setup guide before any production deployment.
Fabric Data Agent FAQ
Official Resources — Microsoft Learn Documentation
All links go directly to official Microsoft documentation. No third-party summaries.
This guide is verified against Microsoft Learn documentation and the Microsoft Fabric Community blog as of June 2026. The Fabric Data Agent is in public preview — features, limits, and authentication support will change. Always check the official documentation before any production deployment. UIG Data Lab is an independent publication, not affiliated with or endorsed by Microsoft Corporation.
