A Fabric Data Agent can make governed structured data easier to query, but natural language does not remove data engineering or analytical ambiguity. The agent can select the wrong source, generate a valid query for the wrong metric, inherit inconsistent definitions, return a truncated result, fail on a user's missing permission, or produce a confident explanation that is not sufficient for a material decision.

Datrick treats the agent as a controlled analytical product. AI can generate query candidates, instruction drafts, paraphrased questions, failure classifications, and regression tests. Approved definitions, deterministic queries, source permissions, business owners, and human review determine what the agent is allowed to answer and whether the response is correct.

Want a data agent but cannot define which questions, sources, and decisions it should support? Start with one business domain and a measurable question contract.

Define an agent use-case and answer contract

Identify users, business decisions, supported questions, data sources, metrics, sensitive fields, prohibited topics, acceptable latency, languages, integration channel, audit needs, escalation, and measurable value. Define whether the agent provides exploration, an approved KPI answer, a lead for an analyst, or input to another agent. Do not let a conversational prototype silently become a decision system.

Implementation domainRequired evidenceDecision
Business usePersonas, decisions, question catalogue, current workflow, time spent, risk, owner, and acceptance criteria.Is the agent solving a bounded and measurable problem?
Source portfolioSemantic models, Warehouses, Lakehouses, KQL databases, schemas, ownership, freshness, quality, lineage, and overlap.Which source is authoritative for each question and metric?
Agent configurationDescription, instructions, example queries, source selection guidance, Prep for AI settings, verified answers, and versions.Can the agent interpret organizational language without hiding ambiguity?
Security and governanceAgent sharing, source permissions, RLS/CLS, service principals, Purview, audit, DLP, retention, and sensitive scenarios.Can every persona query only permitted data through every integration path?
Quality evaluationGolden questions, expected queries and results, security negatives, unsupported questions, scoring, failures, and regression history.Does answer quality meet the threshold for the intended use?
OperationsCapacity, deployment, monitoring, feedback, incidents, source change, ownership, support, review cadence, and exit criteria.Can the organization operate and improve the agent after launch?

Prepare sources before configuring the agent

Resolve ambiguous names, duplicate metrics, inconsistent time logic, undocumented grain, weak relationships, stale data, missing ownership, and conflicting sources. For semantic models, use explicit measures, descriptions, formats, hidden technical fields, synonyms, AI data schema, AI instructions, and verified answers where appropriate. For SQL and KQL sources, expose governed views, documented fields, stable types, tested joins, and query patterns that protect performance.

Fabric Data Agents are designed for structured SQL, DAX, and KQL read queries. They do not currently provide a general unstructured-document retrieval layer, and conversational results are limited and summarized rather than intended for complete data export. Route document-grounding, bulk extraction, write-back, workflow action, and high-volume API requirements to the correct complementary architecture instead of forcing them through the chat experience.

Write instructions as guidance, not security

Configure the agent description so people and orchestrators understand its purpose and boundaries. Add instructions for source selection, metric terminology, required filters, time interpretation, common ambiguities, clarification, unsupported questions, and response expectations. Include representative example queries with approved results.

Instructions can improve relevance but do not replace source logic, permissions, or deterministic validation. Do not use prose to repair an incorrect measure or prevent access to sensitive fields. Fix the durable source layer and enforce access through Fabric and underlying source controls.

Design sharing, identity, and integration paths

Sharing the Fabric Data Agent and sharing its underlying sources are separate decisions. Microsoft documents that users need minimum effective permission on every source they query and that Power BI RLS and CLS continue to apply. Test the published agent with representative users, not only with its creator or workspace administrator.

For application integration, choose user-delegated identity or a service principal based on the required security model. On-behalf-of patterns preserve user context; application identities require precise source permissions, credential lifecycle, workload identity controls, usage attribution, and abuse protection. Record whether Copilot Studio, Foundry agents, custom applications, or other orchestrators can invoke the agent and how permissions behave end to end. For remote tool consumption, use the Fabric Data Agent MCP server implementation and security guide to assess the client and full data path.

Review Purview DLP, restricted access, audit, eDiscovery, sensitivity, retention, and employee or customer privacy requirements. Agent interactions and generated queries can become discoverable operational records. Define who can access them and how security, privacy, and support teams investigate incidents.

Build a deterministic agent evaluation suite

Evaluation dimensionTest methodFailure example
Source selectionAsk overlapping and domain-specific questions with an approved authoritative source for each.Agent queries an operational table when the governed semantic model owns the KPI.
Query correctnessCompare generated SQL, DAX, or KQL semantics, filters, joins, grain, period, and result with deterministic controls.Valid query calculates orders instead of recognized revenue.
Grounding and explanationVerify cited source, cutoff, measure, query evidence, limitations, and narrative against the result.Correct number is explained with an unsupported causal claim.
SecurityRun positive and negative questions across RLS/CLS personas, missing permissions, sensitive fields, and integration identities.Agent reveals a restricted region or fails open through an application identity.
Scope and truncationTest large results, unsupported documents, write requests, exports, history-dependent follow-ups, and expected clarification.User treats a summarized 25-row response as the complete dataset.
ReproducibilityRepeat questions against a fixed data snapshot and rerun after source, model, instruction, permission, or product changes.Material answer changes without approved data or business-logic change.
Performance and utilityMeasure latency, query cost, capacity use, correction effort, time saved, user confidence, and escalation rate.Accurate response is too slow or requires more analyst correction than the current workflow.

Version each test with persona, prompt, expected interpretation, source, query, result, data snapshot, acceptable narrative, prohibited content, and threshold. Include paraphrases, ambiguity, missing filters, contradictory definitions, unsupported sources, stale data, malicious prompt content stored in data, and expected refusals or clarifications. AI can generate test variants but must not be the sole judge of its own answers.

Operate feedback and source change

Capture user question, persona, source selected, generated query where available, response, latency, error, feedback, expected behavior, and resolution. Separate access failures, source outages, data quality, semantic ambiguity, instruction gaps, product limitations, and user training. Fix the correct layer and add every material failure to regression coverage.

Review source schemas, measures, permissions, instructions, examples, verified answers, integrations, capacity, usage, sensitive topics, and owners on a defined cadence. Pause or restrict the agent when an upstream change invalidates approved answers or when evaluation falls below threshold.

Run a three-to-five-week implementation pilot

  1. Choose one business domain, named users, supported decisions, structured sources, measurable baseline, and accountable owners.
  2. Assess source quality, authority, security, freshness, performance, metadata, and compatibility with current Data Agent capabilities.
  3. Prepare governed views or semantic models and configure the agent description, instructions, source guidance, examples, and verified answers.
  4. Implement agent and underlying-source permissions for representative users plus any approved application or service-principal path.
  5. Create golden questions, deterministic queries, security negatives, ambiguity tests, unsupported requests, truncation cases, and utility scenarios.
  6. Evaluate the published agent against fixed data, classify failures, remediate the durable layer, and repeat the suite.
  7. Pilot with named users while monitoring questions, corrections, source behavior, capacity, security, and support demand.
  8. Deliver source and agent configuration, evaluation suite, scorecard, security model, integration, runbooks, limitations, training, backlog, and rollout gates.

Frequently asked questions

What is a Microsoft Fabric Data Agent?

A Fabric Data Agent is a conversational interface over supported structured data in Microsoft Fabric. It interprets a user's question, selects an approved source, and generates read-only SQL, DAX, or KQL queries to return grounded insights. It can be used in Fabric and integrated into supported agent experiences, but it needs prepared data, instructions, permissions, evaluation, and operating controls.

Which data sources can a Fabric Data Agent use?

Current supported source patterns include selected Fabric structured data sources such as Power BI semantic models, Warehouses, Lakehouses through SQL analytics endpoints, and KQL databases or Eventhouse scenarios. Exact item and feature support changes, so implementation should verify current Microsoft documentation. Fabric Data Agents do not currently use unstructured PDF, DOCX, or TXT content as agent data sources.

Does a Fabric Data Agent respect Power BI row-level security?

Yes. Microsoft documents that Fabric Data Agents honor the user's underlying data permissions, including Power BI row-level and column-level security. Sharing the agent does not automatically grant source access. Users need the required permissions on every source, and tests should verify positive and negative personas across all connected sources and integration paths.

How do you evaluate Fabric Data Agent answer quality?

Create a versioned question set with approved interpretation, source, query, expected result, security persona, data snapshot, acceptable narrative, clarification and refusal behavior, and scoring threshold. Measure source selection, query correctness, calculation accuracy, grounding, security, relevance, truncation, reproducibility, latency, and usefulness. Repeat tests after source, schema, instruction, permission, model, or integration changes.

How long does a Fabric Data Agent implementation take?

A bounded implementation and controlled pilot can often be completed in three to five weeks for one business domain when supported data sources, owners, permissions, business definitions, target questions, capacity, and integration decisions are available. More time is required when data quality is poor, semantic models are ambiguous, sources conflict, security is complex, or the agent must be embedded into a larger application or multi-agent workflow.

Official implementation references

Start with the questions people repeatedly ask analysts and the structured sources that already have accountable owners. Datrick can prepare the data, implement the agent, prove its answers, and define production rollout gates.