A customer metric may exist in a curated semantic model, raw Lakehouse tables, a Warehouse mart, an Eventhouse stream, and a policy document. Each can return a defensible answer with a different grain, freshness, owner, permission boundary, and business meaning. A multi-source Data Agent fails when it chooses the technically relevant source instead of the authoritative source for the decision.
Fabric Data Agent supports up to five sources in one agent and uses orchestration, planning, and routing logic to invoke source-specific tools. Microsoft documents agent instructions, source descriptions, schema, metadata, and examples as routing context. The configuration surfaces differ by source type, so reliable routing requires an explicit authority model and source-specific evaluation rather than one generic prompt.
When two sources can answer the same question, which one is authoritative, for whom, and at what freshness? Write that rule before adding the second source.
Create a source authority contract
For every source, define the business domain, supported question types, authoritative metrics, grain, freshness, user cohort, access boundary, owner, query or retrieval tool, exclusions, and fallback. Specify what happens when sources disagree, a source is unavailable, a user lacks access, or a question needs evidence from more than one source.
| Source role | Authoritative for | Not authoritative for | Routing evidence |
|---|---|---|---|
| Power BI semantic model | Governed measures, approved business dimensions, RLS-aware executive metrics, and verified answers. | Raw-detail exploration, operational telemetry, or document policy text. | Prep for AI schema, AI instructions, verified answers, Read permission, and route tests. |
| Lakehouse / Warehouse / SQL | Structured detail, governed relational queries, reconciliations, and source-specific exploration. | Metrics that must use curated semantic calculations unless explicitly approved. | Selected schema, source description, source instructions, SQL examples, and ground truth. |
| Eventhouse KQL | Fresh operational events, telemetry, time-series state, incidents, and bounded investigation. | Certified financial metrics or long-form policy explanations. | Event-time contract, selected KQL entities, instructions, examples, and latency tests. |
| Graph / Ontology | Relationship paths, domain entities, semantic context, and connected-data reasoning. | Bulk export, unsupported graph boundaries, or metrics better defined in a model. | Graph or ontology scope, descriptions, instructions where supported, and path tests. |
| Azure AI Search | Policies, procedures, contracts, manuals, and other indexed document evidence. | Numeric truth that should be calculated from governed structured data. | Index context, retrieval settings, citations, user access, and grounding evaluation. |
Respect each source's configuration model
Keep agent-level instructions limited to rules that apply across sources: routing precedence, shared terminology, response format, ambiguity handling, evidence requirements, and no-answer behavior. Put table, join, filter, time, value, and query logic in source-specific instructions and examples where that source supports them.
Power BI semantic models are different. Microsoft says the DAX generation tool uses AI Instructions and Verified Answers from Prep for AI; semantic-model-specific instructions at the Data Agent level are ignored for DAX generation. Data Agent does not provide source descriptions or example queries for semantic models. Use agent instructions for cross-source routing and keep metric logic in the model's Prep for AI configuration.
SQL and Eventhouse sources support schema selection, source descriptions, instructions, and examples. Graph supports descriptions, instructions, and GQL examples but not node-and-edge schema selection. Ontology supports a description but not source instructions or examples. Azure AI Search uses index context, search type, document count, and response instructions. Do not copy one source's configuration pattern into another and assume it is effective.
Descriptions must distinguish sources rather than restate broad capabilities. Name the questions each source should answer, the freshness and grain it owns, and the nearest overlapping source it should not replace. If the boundary cannot be stated clearly, use separate Data Agents or redesign the source portfolio.
Build route-level ground truth
Create a test set that records the expected source or source combination before testing answers. For each question, preserve user persona, expected route, prohibited routes, generated query or retrieved passages, deterministic result, final answer, evidence, latency, and severity. Include paraphrases, ambiguous acronyms, overlapping metrics, mixed fresh and historical data, permission differences, unavailable sources, and questions that should trigger clarification.
| Dimension | Test | Pass condition | Remediation |
|---|---|---|---|
| Route accuracy | Expected versus selected source for direct, paraphrased, overlapping, and ambiguous questions. | Agent selects the authoritative source or asks a useful clarification. | Source contract, descriptions, routing instruction, schema focus, or agent separation. |
| Tool accuracy | Generated SQL, DAX, KQL, GQL, ontology response, or retrieved document chunks. | Tool output matches source-specific ground truth. | Source configuration, model Prep for AI, examples, index tuning, or source redesign. |
| Combination fidelity | Questions that need a metric plus explanation, event plus policy, or entity plus relationship. | Every component uses its authoritative source and preserves evidence and qualifiers. | Explicit decomposition, routing rule, multi-agent boundary, or unsupported-use refusal. |
| Conflict handling | Sources return different values, freshness, versions, or definitions. | Agent applies the approved precedence or exposes the conflict without inventing reconciliation. | Authority rule, freshness metadata, clarification, or human escalation. |
| Permission behavior | Users with different access to agent and underlying sources. | Each route respects effective source access and fails closed. | Permission correction, source separation, route redesign, or clear denied response. |
| Runtime stability | Standard versus preview routing over the identical source portfolio and question set. | Any route change is measured, approved, and reversible. | Runtime rollback, configuration change, release gate, or targeted monitoring. |
| Answer fidelity | Source attribution, units, freshness, citations, truncation, uncertainty, and final synthesis. | Answer preserves the evidence and never hides route limitations. | Response instruction, explicit evidence, clarification, or escalation. |
Track route accuracy separately from answer accuracy. A correct answer from the wrong source can pass a shallow test and fail after the sources diverge. Record selected tools and run steps, then classify each failure by intent parsing, route, source configuration, generated query, retrieval, permission, source availability, or synthesis.
Prove effective access and runtime changes
Sharing the Data Agent does not replace access to its underlying sources. Test each persona against every route, including a source the user cannot access, a source permission removed after publication, and a mixed question where only part of the evidence is allowed. The agent should not substitute a weaker source to bypass a denied authoritative source unless that fallback is explicitly approved and disclosed.
Runtime selection affects orchestration, planning, routing, and source query tools. Compare standard and preview runtimes with the same sources, configuration, identities, and question set before changing production. Monitor route distribution, wrong-source corrections, tool failures, authorization errors, latency by route, capacity, source freshness, answer feedback, and runtime or configuration releases.
Maintain a published baseline, versioned draft, source contracts, route test suite, and rollback procedure. Test source unavailable, timeout, empty result, stale source, conflicting evidence, unsupported preview source, and output truncation. A route failure should produce a clear limitation, not a confident answer assembled from whatever source remains available.
Run a three-to-five-week routing assessment
- Select one Data Agent, two to five sources, user cohorts, business owners, high-value cross-source questions, and measurable route targets.
- Map source authority, overlap, grain, freshness, configuration support, permissions, tool behavior, runtime, and current failures.
- Write source contracts, narrow schemas, configure Prep for AI where required, refine descriptions, instructions, examples, index context, and fallback rules.
- Create route-level ground truth with expected and prohibited sources, query or retrieval evidence, deterministic results, and answer criteria.
- Run route, tool, conflict, permission, source-outage, ambiguous-intent, mixed-evidence, runtime, latency, and adversarial tests.
- Classify failures, remediate the correct layer, compare draft with published behavior, and prove release and rollback.
- Deliver the authority matrix, source configurations, routing scorecard, permission matrix, regression suite, runbooks, and go, limit, split, or stop recommendation.
Frequently asked questions
How many data sources can one Microsoft Fabric Data Agent use?
Microsoft's current documentation says one Fabric Data Agent can use up to five data sources in any combination. Supported categories include SQL sources, Eventhouse KQL databases, Power BI semantic models, Graph, ontology, and preview Azure AI Search indexes.
How does Fabric Data Agent choose between multiple data sources?
The orchestrator evaluates the user question against available source metadata, schema, descriptions, instructions, and examples, then invokes the relevant query or retrieval tool. Clear non-overlapping source contracts and regression tests are required because overlapping domains can route a question to a plausible but non-authoritative source.
Where should semantic model instructions go in a mixed-source Data Agent?
Microsoft says semantic-model-specific guidance belongs in Power BI Prep for AI because the DAX generation tool uses those AI instructions and verified answers. Agent-level instructions should contain cross-source routing rules and global behavior, not semantic-model query logic.
Can a Fabric Data Agent combine structured and unstructured sources?
Microsoft's newer source-specific preview documentation describes combining Azure AI Search unstructured content with structured Data Agent sources. Validate tenant availability, source routing, permissions, evidence attribution, and failure behavior because some broader concept documentation may lag preview support.
How long does a Fabric Data Agent routing assessment take?
A focused assessment commonly takes three to five weeks for one Data Agent, two to five sources, and a representative cross-source question set. It covers source authority, configuration asymmetries, permissions, routing ground truth, generated queries, answer synthesis, runtime comparison, and release controls.
Official implementation references
- Data Agent orchestration and multi-source configuration
- Source-specific configuration support
- Instructions, descriptions, and routing context
- Semantic model and Prep for AI routing guidance
- Standard and preview routing runtimes
- Underlying source permissions and sharing
Start with the questions where two sources disagree or the agent chooses the wrong one. Datrick can turn that ambiguity into source contracts, route-level ground truth, measured regressions, and a controlled architecture decision.