How to connect Microsoft Foundry with Microsoft Fabric to talk to your company's data

Over the last few years, companies have invested heavily in centralizing information in data lakes, warehouses and analytics platforms. The problem is that, even when the data is available, getting to it still usually means knowing the model, writing SQL, navigating a dashboard or asking a data team for help.

AI agents are starting to change that interface.

One particularly interesting scenario within the Microsoft ecosystem is combining Microsoft Foundry with Microsoft Fabric, so that a user can ask questions in natural language like:

"How did sales evolve last quarter?"

"Which products grew the most in Argentina?"

"Which customers had the biggest drop in billing compared to last year?"

And get an answer based on the real data the organization already manages in Fabric.

The idea is not to give the language model direct access to the entire database. The architecture is quite a bit more interesting than that.

Two agents, two responsibilities

A simple way to understand this solution is to think of it as a two-level architecture.

On one side there is a Foundry Agent, responsible for interacting with the user, understanding what they need, deciding which tools to use and building the final answer.

On the other side there is a Fabric Data Agent, specialized in understanding and querying the data available inside Microsoft Fabric.

The conceptual architecture looks like this:

This lets you clearly separate AI orchestration from the data access and semantics layer.

Microsoft describes exactly this pattern: the Foundry agent can decide when to use a Fabric Data Agent, invoke it, receive the result and use it to build the answer for the user.

The role of Fabric Data Agent

Fabric Data Agent is the piece that turns enterprise data into a conversational experience.

Instead of teaching a user which table to query or which query to run, you can configure an agent with knowledge about specific data sources and about what that data means within the business.

For example, you could have a Data Agent specialized in sales that understands concepts like:

Revenue
Customer
Product
Region
Sales Order
Margin
Fiscal Period

That agent can work on top of different Fabric components, such as Lakehouses, Warehouses, Power BI semantic models or KQL databases.

But there is an important point: the Data Agent should not be seen simply as a SQL generator.

Its value lies in adding an intermediate layer between the human question and the technical structure of the data.

The question:

Who were our best customers this quarter?

may eventually end up generating a query across several tables, relationships, metrics or semantic models.

The user doesn't need to know those details.

So what does Foundry do, then?

If Fabric can already answer questions about data, it's fair to ask why you need Foundry at all.

The answer is orchestration.

The Foundry Agent can have more responsibilities than simply querying analytical information.

For example, it could receive:

Analyze last quarter's sales,
identify the regions with a drop greater than 10%
and prepare an executive summary for me.

The agent can decide to query Fabric, interpret the result and then use the language model to generate an explanation that fits the user.

You can even imagine scenarios where the agent has several tools:

That way, Foundry becomes a layer of interaction and reasoning across different enterprise systems.

Fabric IQ: an interesting evolution

Microsoft is also moving forward with an integration through Fabric IQ and OneLake Catalog.

With this approach, an agent created in Microsoft Foundry can discover and use Data Agents published in Fabric directly from OneLake Catalog.

This simplifies the architecture quite a bit.

Instead of manually configuring workspace and artifact IDs, you can select the available Data Agents from the Fabric catalog. On top of that, a single Foundry Agent can use multiple Data Agents.

For example:

The agent receives a question and decides which one to use.

Microsoft also notes that, in this integration, each Fabric Data Agent is exposed to the Foundry agent as a Model Context Protocol (MCP) compatible endpoint.

This is especially interesting because it starts turning Data Agents into reusable tools within multi-agent architectures.

A concrete example

Suppose a sales director writes:

Why did sales drop in August?

The flow could go like this.

First, the Foundry Agent interprets that this is an analytical question related to sales.

So it selects the Sales Data Agent in Fabric.

Fabric can query the relevant data and return information such as:

Revenue August: -8.4% MoM

Main contributors:

Argentina: -14%
Brazil: -3%
Chile: +2%

Argentina decline concentrated in:
- Enterprise segment
- Product Category A

Foundry receives that information and can build a much more natural answer:

August sales fell 8.4% compared to July.

The main factor was Argentina, where the drop reached 14%.
Most of that variation is concentrated in the Enterprise segment
and, in particular, in product category A.

Brazil also showed a slight contraction, while Chile
grew 2% over the same period.

The LLM takes care of explaining.

Fabric takes care of retrieving and processing the data.

That separation matters.

Security: what makes the enterprise scenario viable

When we talk about agents querying corporate information, the most important question is probably not which model you're using.

It's:

what data can each user see?

The integration between Foundry and Fabric is designed to work with delegated identity.

When the Foundry Agent calls the Fabric Data Agent, the query can run under the identity of the signed-in user. Fabric keeps enforcing the permissions that user already has on the underlying resources.

This avoids creating an "AI super user" with unrestricted access to all the information.

If a person can't query certain data in Fabric, the agent shouldn't use it to answer them either.

For enterprise scenarios, this feature is probably more important than any prompting improvement.

How to set it up at a high level

Without going too deep into implementation details, you can think of the process in five steps.

1. Prepare the data in Fabric

First you need a reliable, governed data source.

It could be a Warehouse, a Lakehouse or a Power BI semantic model.

The quality of the agent's answers depends directly on the quality and clarity of that layer.

2. Create a Fabric Data Agent

Inside Fabric you create the Data Agent, select the relevant sources and configure its context.

You can also add instructions to help it understand how to interpret concepts specific to your organization.

For example:

Revenue always means Net Revenue.

When the user asks for sales by region,
use SalesRegion, not BillingCountry.

Fiscal Year starts in July.

This kind of context can make a huge difference in the quality of the answers.

3. Publish and test the Data Agent

Before connecting it to Foundry, it's worth validating it directly in Fabric.

Simple questions:

How much did we sell this month?

Questions with dimensions:

Show me sales by region.

Comparative questions:

Which regions grew the most compared to the same period last year?

The goal is to validate the data layer first and only then add the orchestration layer.

4. Connect it to Microsoft Foundry

In Foundry you can add Fabric as a tool for the agent.

In the most recent approach with Fabric IQ / OneLake Catalog, the published Data Agent can be selected from the catalog and added as one of the agent's tools.

Then you can give the Foundry Agent instructions like:

You are the corporate data assistant.

For questions related to sales, revenue, customers,
products or commercial performance, use the Sales Data Agent.

Do not invent financial values.

If Fabric doesn't provide enough information to answer a question,
clearly explain what information is missing.

This part is essential.

A good agent doesn't just need tools: it needs to know when to use them.

5. Test real questions

Finally, you have to test the agent with the questions the business would actually ask.

Not only:

What were the sales?

But also:

Why did revenue drop?

Which customers explain the gap against budget?

Compare Argentina and Brazil over the last six months.

Summarize the three main changes the CFO should look at.

These questions let you evaluate not just whether the query works, but whether the complete experience is valuable to the user.

A recommendation: don't build "the agent that knows everything"

Technically, it's tempting to connect one agent to all of the organization's data.

That's not necessarily the best architecture.

It can be healthier to build Data Agents specialized by domain:

Sales Agent
Finance Agent
Operations Agent
Supply Chain Agent
Customer Agent

Each with clearly defined data sources, vocabulary and instructions.

Then you can put a Foundry Agent as the orchestrator, responsible for deciding which one to query.

This design makes it easier to reason about permissions, ownership, data quality and the responsibilities of each agent.

And the new integration model through Fabric IQ allows precisely that: a single Foundry agent with several Data Agents available, picking the right one based on the question.

The real challenge isn't the LLM

When you build this kind of solution, it's easy to focus too much on which model to use.

But in an enterprise scenario, the biggest challenges are probably somewhere else:

• Do we have clearly defined metrics?
• Do users understand "revenue" the same way?
• Do the semantic models correctly reflect the business rules?
• Are the permissions well designed?
• Does the agent know when it has enough information to answer?
• Can we observe which source it used to reach the answer?

In other words: a good data agent still needs a good data platform.

AI dramatically reduces the friction of accessing information, but it doesn't replace the need for governance, semantics and quality.

From dashboards to conversations

Dashboards aren't going away.

There are metrics we always want to see the same way, and visualizations that are still the best way to understand certain phenomena.

But agents add another interface.

Someone can look at a dashboard and then ask:

Why did this happen?

And go on:

Which customers explain the drop?

Did something similar happen last year?

Summarize it in three points so I can present it at the meeting.

That kind of interaction would be much harder to handle with a traditional BI interface alone.

The combination of Microsoft Foundry + Microsoft Fabric targets exactly that space: keeping the data inside a governed platform, while letting users interact with it in natural language.

Conclusion

An enterprise agent architecture doesn't need to start with an extremely complex multi-agent system.

You can start with something fairly simple.

Fabric remains responsible for the data, its semantics and its permissions.

Foundry adds the ability to reason about the user's intent, select tools and turn the results into a useful conversation.

From there you can evolve toward several domains, multiple Data Agents, Fabric IQ, MCP and more sophisticated agent architectures.

But the fundamental idea stays simple:

it's not about teaching an AI model all of the company's data.

It's about giving the agent a secure, governed and contextual way to query the right data when it needs it.

And that is probably one of the most interesting applications of agents inside a company.

Note: several of the integration capabilities between Microsoft Foundry, Fabric Data Agent and Fabric IQ are currently in preview. For production deployments, check regional availability, capacity requirements, permissions, compliance limits and the status of each feature in Microsoft's official documentation.