A finance manager asks, “Which customers explain the decline in margin this quarter?” A convincing answer appears within seconds. Before that answer influences a forecast, three questions matter: Did the agent calculate the right measure? Did it respect the manager’s access? Can the team reproduce the result after changing the model or instructions?

For enterprise leaders, these are delivery requirements. A conversational interface becomes useful when people can act on its answers with a known level of confidence. This guide proposes a practical release process for Fabric data agents, with a finance example and explicit checks before adding Microsoft Foundry orchestration.

Know which capability you are adopting

As checked on October 13, 2026, Microsoft’s Fabric data agent concepts documentation describes the core feature as generally available. The SDK evaluation feature and Foundry integration through Fabric IQ are still documented as preview. Treat those as separate adoption decisions. General availability of one component does not establish the release status of the entire solution.

The current platform name is Microsoft Foundry, replacing the Azure AI Foundry brand. Fabric provides the data-questioning component; Foundry can orchestrate a broader application. A Fabric data agent maintains read-only data connections. Updating an ERP record would require a separate action tool and its own controls.

1. Define a narrow business contract

Consider an illustrative distributor with a Power BI semantic model containing revenue, cost, customer, and fiscal-calendar measures. Regional managers need weekly margin explanations. Begin with this scope rather than connecting every available source.

Agree with finance on what “margin” means, which currency applies, how returns are treated, and whether quarter means fiscal or calendar quarter. Record the data refresh timestamp alongside the expected answer. For financial measures, my recommendation is to start from approved semantic-model measures so the pilot evaluates an established definition.

A useful answer contract includes the reporting period, authorized region, measure definition, result, and any missing data or qualification. An unexplained number should fail review even when it happens to match. This contract is a proposed acceptance standard, not a guarantee that the product automatically supplies every field.

2. Build an evaluation set before tuning

Start with 40 representative questions, an illustrative pilot size rather than a Microsoft requirement. Include routine totals, comparisons, ambiguous wording, incomplete data, and requests outside scope. Finance should approve expected answers from a fixed data snapshot. Keep some questions out of the tuning set to test generalization.

Useful cases include “Show net revenue for the last completed fiscal quarter,” “Why did margin fall?” and “Compare my region with every other region.” The second should clarify the period or metric when needed. The third should reveal only authorized data. Expected behavior can be clarification or refusal; it need not always be a number.

Microsoft’s evaluation workflow accepts question and expected-answer pairs, runs an evaluation, and provides summary and detailed results. Its documentation requires an agent published to the stage being evaluated, production or sandbox. Use an isolated test workspace and restricted audience for this step. Publishing a Fabric agent version is distinct from releasing the application broadly.

The evaluator uses a critic prompt to judge answer equivalence. My recommendation is to supplement that judgment with numerical checks and finance review of failures. An automated score alone cannot establish that the correct period, currency, or business definition was used. This article describes a validation approach; no SDK code or live workload was executed for it.

3. Test access with consumer identities

The sharing and permission documentation says consumers need access to both the data agent and its underlying sources. For Power BI semantic models queried through a Fabric data agent, Read permission is sufficient; workspace membership and Build permission are not required for that interaction. Other entry points can have different permission requirements.

Run the same evaluation questions as a regional manager, a central finance analyst, and a user without source access. Check row and column restrictions where configured. Confirm that denied queries do not surface protected values through explanations or follow-up questions. Testing only with a workspace administrator would miss the actual consumer experience.

Use permissions to enforce boundaries. Instructions can describe appropriate behavior, but they should never substitute for access control. Preserve the identities and effective permissions used in each test so future releases can repeat the same checks.

4. Review geography and the orchestration boundary

Current prerequisites include paid F2 or higher Fabric capacity, or P1 or higher Power BI Premium capacity with Fabric enabled, plus source access. The tenant-settings guidance, updated September 29, 2026, explains when cross-geography processing and storage switches are required, including capacities outside the EU data boundary and the US. Review the applicable settings with your administrator rather than enabling them blindly.

For the preview Fabric IQ integration, verify a supported full-Fabric region, a Foundry project with a deployed model, the same tenant, the same signed-in account, and required permissions. The documented connection uses delegated user authentication. Responses may leave Fabric’s compliance boundary or geographic region and become subject to Foundry’s handling terms. Data location review must cover both services.

Add orchestration after validating the Fabric agent itself. Then test the complete path again: source selection, Fabric answer, and Foundry’s final response. A correct tool result can still become a misleading summary. Keep any transaction-changing tool behind a separate authorization decision.

5. Release against quality and business measures

For this hypothetical pilot, set an initial target of at least 95% correctness on approved routine questions, with no observed unauthorized disclosures in the defined test set. These are proposed gates, not vendor benchmarks or evidence of zero risk. Review material errors individually instead of hiding them inside an average.

Measure median time to a verified answer, analyst correction rate, clarification frequency, and cost per accepted answer. Include capacity and model usage, evaluation effort, and human review in the cost calculation. Compare with a manual baseline using equivalent questions and data.

Suppose 300 monthly requests each save ten minutes after verification. That would represent 50 hours of potential capacity, an illustrative calculation rather than a forecast. Track realized savings before extending the agent to another domain. Version the configuration and evaluation set, rerun them after material changes, and retain a fallback to established reports.

The broader platform context is covered in my earlier enterprise AI architecture article. The next decision is concrete: identify the questions the agent must answer, the access it must enforce, and the evidence required for release. That gives architects and business sponsors a shared basis for approval.

References

Microsoft Learn: Fabric data agent concepts and release status

Microsoft Learn: Evaluate your data agent, preview

Microsoft Learn: Sharing and source permissions

Microsoft Learn: Required tenant settings and cross-geography handling

Microsoft Learn: Consume a data agent through Fabric IQ, preview

Microsoft Learn: Microsoft Foundry overview and current terminology