Adding more agents does not automatically create a better system. It creates more routing decisions, identity transitions, model calls, failure modes, versions, and owners. A useful multi-agent architecture starts with business boundaries that can be governed and tested independently. Microsoft positions Fabric Data Agents as conversational analytics specialists: they select among attached Fabric sources, generate read-only SQL, DAX, or KQL where supported, and return governed answers. External orchestrators and multi-agent runtimes can invoke those specialists as part of a broader workflow.
The architecture should preserve that specialization. The orchestrator owns intent classification, workflow state, tool selection, answer composition, and escalation. Each Fabric Data Agent owns one coherent analytics domain, authoritative sources, instructions, examples, permissions, and evaluation set. Any component that changes a ticket, order, customer record, deployment, or financial state remains outside the Data Agent behind deterministic action controls.
Which two business domains need different owners, permissions, vocabulary, or release gates? If that question has no clear answer, one well-designed Data Agent is probably safer than a multi-agent system.
Split agents by governed decision domain
A Fabric Data Agent can connect to a limited set of supported sources. That technical limit is not the primary reason to split. Create separate agents when the business domains have different accountable owners, permission models, semantic definitions, data freshness, risk, evaluation questions, or change cadence. Finance margin analysis and service operations may both use Fabric, but they should not necessarily share instructions, sources, release approval, or a single generic tool description.
Write a contract for every specialist. State the decisions it supports, authoritative sources, supported question classes, prohibited questions, identity model, freshness, expected evidence, quality threshold, owner, release version, and escalation route. The contract becomes the basis for the orchestrator's routing policy and the specialist's regression suite. Avoid agents named after platforms or databases; route by business capability and decision intent.
| Boundary signal | Keep one Data Agent when | Separate Data Agents when | Evidence |
|---|---|---|---|
| Business ownership | One owner accepts metric definitions, answer quality, access, and release risk. | Different executives or data owners must approve scope and changes independently. | Named domain owner and responsibility matrix. |
| Semantic language | Terms, measures, time grains, and exclusions are coherent across the question set. | The same term has different definitions or source truth across domains. | Business glossary and ground-truth examples. |
| Data access | The intended users and effective source permissions substantially overlap. | Users, regions, customers, or sensitivity boundaries require different identities or policies. | Persona-to-source permission matrix. |
| Quality and release | One evaluation set and release cadence can safely cover all sources. | Domains need independent tests, incidents, rollback, or regulatory approval. | Versioned scorecards and release gates. |
| Runtime behavior | One agent can select the correct source reliably and stay within acceptable latency and consumption. | Source selection is persistently ambiguous or one workload destabilizes the others. | Routing confusion, latency, capacity, and error analysis. |
Make routing explicit, observable, and reversible
The orchestrator should have a compact catalog of specialist contracts rather than access to vague agent descriptions. For each route, include domain, supported intents, exclusions, required identity, sensitivity, expected latency, cost class, and fallback. A Fabric Data Agent's published description also influences tool selection in supported clients, so keep public descriptions aligned with the orchestrator catalog and version them with the agent.
Use deterministic routing before model routing where practical. Tenant, product, geography, workflow state, user role, and selected domain can eliminate invalid specialists without an LLM decision. A model can classify the remaining intent, but require a confidence threshold, record the alternatives considered, and ask a clarifying question when the request spans domains or remains ambiguous. Do not silently query every specialist and let a model choose the answer; that multiplies data exposure, consumption, latency, and synthesis risk.
Define composition before implementation. Some questions need one specialist. Others need sequential evidence, such as retrieving current revenue before evaluating a support intervention. Parallel calls are appropriate only when the sources and permissions are independent and the final synthesis preserves units, time windows, filters, and uncertainty. The orchestrator should cite which specialist supplied each material claim and must not invent a cross-domain join that no governed source or tested rule supports.
Preserve identity and isolate actions
Identity support differs by consumption path. A Foundry Fabric tool uses end-user On-Behalf-Of authorization in Microsoft's documented integration and does not support a service principal for that specific tool path. Direct MCP and custom application paths can use a user token or, in documented preview scenarios, a service principal that has explicit workspace and source access. Copilot Studio and Microsoft 365 Copilot introduce their own authentication and sharing behavior. Select a pattern per route and test the exact production identity.
A shared service principal creates a fixed data persona. It does not automatically preserve each application user's source permissions. The orchestrator and application must enforce their own user-to-domain authorization before invoking that route. If individual source security must follow the user, use a supported delegated path and prove RLS, CLS, workspace, source, and Purview behavior for each persona. Never transform one broad service principal into a universal analytics back door.
Fabric Data Agents are read-only. Keep them read-only inside the architecture. If an answer should lead to an action, pass a structured proposal to a separate action component. That component should validate required fields, retrieve authoritative state, enforce user and service authorization, check policy, require human approval for high-impact changes, use idempotency keys, record the exact request and result, and support compensation or rollback. The orchestrator must not convert generated narrative directly into executable parameters.
| Test family | Scenario | Required result |
|---|---|---|
| Route selection | Clear, ambiguous, unsupported, overlapping, adversarial, and cross-domain questions. | Correct specialist, justified clarification, or safe refusal with no unnecessary tool call. |
| Identity | Allowed, restricted, wrong tenant, revoked, expired, service-principal, and delegated personas. | Every route uses the intended identity and fails closed at both orchestrator and source. |
| Specialist quality | Metrics, filters, joins, time windows, empty results, stale data, and prohibited questions. | Generated query, source result, and answer meet the domain-specific ground truth. |
| Synthesis | Parallel and sequential answers with conflicting units, dates, scopes, and uncertainty. | Claims remain attributable; conflicts are surfaced rather than averaged or hidden. |
| Action isolation | Prompt injection, missing approval, duplicated request, changed source state, and action failure. | No direct Data Agent write; deterministic validation, authorization, idempotency, audit, and recovery. |
| Resilience | One specialist unavailable, slow, throttled, misconfigured, or rolled back. | Bounded retries, route-specific degradation, clear user state, and no cascade across healthy specialists. |
Evaluate the system at three levels
Specialist evaluation asks whether each Fabric Data Agent selected the right source, generated the right query, respected permissions, and explained the result accurately. Routing evaluation asks whether the orchestrator chose the right specialist, avoided invalid routes, clarified ambiguity, and stayed within latency and consumption budgets. End-to-end evaluation asks whether the synthesized response helped the user make the intended decision without losing provenance, scope, or uncertainty.
Maintain one versioned test set per specialist and a separate orchestration set. Include real user language, known overlaps, unsupported requests, access boundaries, prompt injection, source outages, answer conflicts, and action attempts. Record the orchestrator version, specialist version, identity, source versions, generated queries, outputs, final response, latency, consumption, and evaluator decision. A change to any specialist description or instruction can alter routing and therefore requires both local and end-to-end regression.
Trace every request across orchestrator decisions and specialist calls with one correlation ID. Monitor route distribution, clarification rate, no-route rate, wrong-route corrections, tool failures, answer quality, latency, consumption per successful decision, user feedback, and action approvals. Establish route-level circuit breakers and known-good versions. One unhealthy specialist should degrade its domain without taking down the entire assistant.
Run a four-to-six-week multi-agent architecture pilot
- Select one end-to-end decision workflow, two genuinely distinct data domains, one orchestrator, one user cohort, and accountable owners.
- Define specialist contracts, source truth, supported questions, identity, permissions, quality thresholds, release gates, and prohibited actions.
- Choose the orchestration platform and consumption path, then document trust boundaries, state, routing, synthesis, data handling, and failure isolation.
- Implement deterministic filters, specialist catalog, model routing where needed, clarification, correlation, timeout, bounded retry, and safe fallback.
- Build specialist, routing, synthesis, permission, adversarial, outage, capacity, and action-isolation tests using production-shaped identities.
- Run the cohort, review wrong routes and wrong answers, remediate the responsible layer, exercise rollback, and repeat the full suite.
- Deliver the architecture, agent catalog, permission matrix, evaluation scorecards, observability dashboard, runbooks, and go, limit, or stop recommendation.
Frequently asked questions
Can Microsoft Fabric Data Agents be used in a multi-agent architecture?
Yes. Microsoft describes Fabric Data Agents as conversational analytics components that external orchestrators and multi-agent runtimes can invoke. Each Data Agent remains focused on read-only, governed access to its attached Fabric sources while an orchestrator handles routing, conversation, synthesis, and any separate action workflow.
When should we use multiple Fabric Data Agents instead of one?
Use multiple Data Agents when domains have different owners, source permissions, business vocabularies, quality tests, release cadences, or risk boundaries. Keep one agent when the sources serve one coherent decision domain and can be governed and evaluated as one unit. Splitting agents only to mirror technical systems usually adds routing complexity without improving trust.
Should a Fabric Data Agent perform business actions in a multi-agent workflow?
Fabric Data Agents are designed for read-only governed data access. Keep analytics and action execution separate. The orchestrator can request evidence from a Data Agent, but a separately authorized action tool or agent should apply deterministic validation, approval, idempotency, and audit controls before changing a business system.
How should identity work across multiple Fabric Data Agents?
Choose the identity pattern per route and consumption channel. User delegated or On-Behalf-Of access preserves individual source permissions where supported. A service principal creates a fixed data persona and needs explicit access to each agent workspace and attached source. Do not mix identity assumptions between direct MCP, Foundry, Copilot Studio, and custom application paths.
How long does a Fabric Data Agent multi-agent architecture assessment take?
A focused architecture pilot commonly takes four to six weeks for two specialist Data Agents, one orchestrator, one user cohort, and one controlled workflow. The work should prove domain boundaries, routing, identity, answer synthesis, failure isolation, evaluation, observability, capacity, and recovery before broader expansion.
Official implementation references
- Fabric Data Agents in external and multi-agent architectures
- Fabric Data Agent standard and preview runtimes
- Microsoft Foundry prompt, workflow, and hosted agent architecture
- Fabric Data Agent tool integration and identity passthrough
- Foundry tool catalog, MCP, and Agent-to-Agent options
- Agent Framework Agent-to-Agent and workflow patterns
Start with two specialists and one decision workflow. Datrick can define the boundaries, build the routing and identity test harness, and deliver a production architecture recommendation before agent sprawl begins.