Fabric Data Agents

Hi ali_lmalki,

Fabric Data Agents do have an orchestrator/routing layer that decides which data source to use.

The current Microsoft documentation describes the process roughly as:

1. The orchestrator creates a plan for the user's question.
2. It evaluates the metadata of the available sources — including source name, description, selected schema, and example queries.
3. It selects the source most likely to answer the question.
4. It invokes the appropriate query-generation tool (NL2SQL, NL2DAX, NL2KQL, etc.).
5. If the question is ambiguous, it can inspect more of the source schema and potentially use another source.

So it isn't simply matching the user's question against a static list of instructions. 

A useful detail is that you can inspect the run steps after an answer to see which source was selected and what metadata influenced the routing decision. This is probably the best way to understand what the agent is doing in practice.

Find here some official docs which can help for details:

Data agent configurations - Microsoft Fabric | Microsoft Learn

Improve data source routing - Microsoft Fabric | Microsoft Learn

Hope this helps, if so, consider leaving kudos or mark it as solution.

Best regards!

Hi ali_lmalki​ 

Have you had a chance to look through the responses shared earlier? If anything is still unclear, we’ll be happy to provide additional support.

Hi ali_lmalki​ 

We wanted to follow up to check if you’ve had an opportunity to review the previous responses. If you require further assistance, please don’t hesitate to let us know.

Hi ali_lmalki,

Yes, there is a routing/orchestration layer involved.

Microsoft documents that the Fabric Data Agent runtime handles the planning and routing logic before it generates a query against a source. So it is not just blindly sending every question to every connected source.

The source choice is influenced by the metadata and guidance you configure around each source. Microsoft specifically recommends improving routing by:

1. keeping the selected schema focused
2. adding a clear description for each data source
3. adding representative example queries where supported
4. using explicit routing rules in the agent instructions if the first three are still not enough

For example, a source description might say that one Lakehouse contains operational sales data, while a KQL database contains telemetry and event data. That gives the orchestrator more context when deciding where a question belongs.

Example queries are particularly useful because the agent can compare the user’s question with those examples and use them as signals for source selection. One caveat is that Microsoft currently documents example-query support for Lakehouse, Warehouse, and Eventhouse/KQL sources, but not for Power BI semantic models or Ontologies.

So if the agent is consistently choosing the wrong source, I would first improve the descriptions and reduce overlapping schemas before adding lots of hard-coded routing instructions.

That usually gives you a cleaner setup than trying to manually tell the agent where every possible question should go.