Fabric and Foundry solve different problems
Pull-quote: “Ask which identity the query runs as. That single question separates the two platforms more cleanly than any feature list.”
Microsoft Fabric and Microsoft Foundry are not competing products, and the reason teams keep arguing about them is that both now show you a chat box over your own data. Fabric is the data platform: storage, pipelines, warehouses, semantics, and the reporting layer. Foundry is the AI application platform: models, agent runtime, tools, evaluation, and the governance around agents. The boundary between them is not a feature list, it is the point where a request stops being a query and becomes a loop.
This is for the architect who has to draw that boundary on a diagram other people will build against, and for the platform lead deciding which team owns which artefact.
What you will be able to do
- Define Microsoft Fabric and Microsoft Foundry precisely enough to settle an argument about scope.
- Describe the documented integration path from a Fabric data agent into Foundry Agent Service, including its identity model.
- Say which platform owns the semantic layer, and why Fabric IQ and Foundry IQ are not the same kind of thing.
- Decide when a model call belongs inside a Fabric notebook rather than inside an agent loop.
- Name the documented limits of a Fabric data agent before you promise a stakeholder something it cannot do.
What is Microsoft Fabric, and what is Microsoft Foundry?
Fabric is a software-as-a-service analytics platform organised around OneLake and sold as capacity. Foundry is a platform-as-a-service offering for building, running, and governing AI applications and agents. They sit at different layers, which is why the comparison feels slippery.
Microsoft describes Fabric as a unified platform whose workloads include Data Engineering, Data Factory, Data Warehouse, Real-Time Intelligence, Data Science, Databases, Power BI, and the Fabric IQ workload currently in preview (What is Microsoft Fabric). Everything in it reads and writes OneLake and draws on one purchased capacity measured in capacity units.
Microsoft Foundry is described as “a unified Azure platform-as-a-service offering for enterprise AI operations, model builders, and application development”, which “unifies agents, models, and tools under a single management grouping” with tracing, evaluations, and role-based access control under one Azure resource provider namespace (What is Microsoft Foundry). If the name is unfamiliar, it is the product previously called Azure AI Foundry and before that Azure AI Studio, renamed at Ignite in November 2025, with the older documentation paths still live.
The most useful separation is by artefact. Fabric produces tables, semantic models, ontologies, reports, and published data agents. Foundry produces agents, knowledge bases, evaluations, and endpoints. When you cannot decide where something belongs, ask what it produces.
Where does the data platform end and the AI platform begin?
At the loop. A single request that resolves into one query and one answer belongs in the data platform. A request that plans, calls tools, evaluates what came back, and may call again belongs in the AI platform.
That line is worth stating in engineering terms rather than as a slogan. Foundry Agent Service exists to run exactly that loop: it exposes the Responses API as a single entry point, hosts prompt and hosted agents in a managed runtime, orchestrates tool calls including web search, file search, memory, code interpreter, MCP servers, and custom functions, and traces the whole thing through Application Insights (Foundry Agent Service). None of that is a Fabric capability, and Fabric does not claim it.
A Fabric data agent is a bounded question-and-answer surface. It “generates SQL, DAX, and KQL read queries” against sources you register, and the documentation is explicit that it does not generate statements that create, update, or delete data (Fabric data agent). It answers. It does not act.
So the architecture question is not “Fabric or Foundry”, it is “how many turns does this need, and does it write anything”. One turn and read-only means you may not need an agent platform at all. Multiple turns, tool use, or any write needs a runtime, and that runtime is Foundry.
If you are building the loop yourself instead, the design considerations are the ones in the harness, not the model, decides whether your agent works: state, budgets, stop conditions, and verification. Foundry gives you a managed version of that harness, and a managed harness always costs some control over the loop.
How does a Fabric data agent actually reach Foundry?
As a tool on a Foundry agent, connected by workspace and artefact identifiers, running under the signed-in user’s identity through On-Behalf-Of authorization.
The constraints matter more than the steps. You build and publish a data agent in Fabric, copy the workspace_id and artifact_id from its URL, which has the form .../groups/<workspace_id>/aiskills/<artifact_id>, then add that as a connected resource on the Foundry project and enable it as a tool. At runtime the agent decides whether the question needs Fabric, and the tool runs the query as the user (the Fabric data agent tool).
Four documented constraints will shape your design, and each one has caught a project:
- Identity passthrough is the model. The Foundry documentation for this tool states that user identity authentication must be used and that service principal authentication is not supported. Every end user needs access to the published data agent and to each underlying source, or the tool call fails.
- Same tenant, both sides. The Fabric workspace and the Foundry project must be in the same Microsoft Entra tenant, and Fabric guidance adds that both should be signed in with the same account during setup (consume a data agent in Foundry).
- Paid Fabric capacity. An F2 or higher capacity, or a Power BI Premium P1 or higher with Fabric enabled. A trial capacity is not the same thing.
- The data agent must be published. An unpublished agent is not reachable from outside Fabric.
The first constraint carries the whole architectural consequence. Because the query runs as the user, Power BI row-level security and semantic model permissions are enforced per person with no filtering logic from you. That is a genuine advantage over building your own text-to-SQL path, and it is why an unattended job with no user cannot use it. If your requirement is a nightly agent with no human in the loop, this integration is not the one, and check current documentation rather than a blog post, because service principal support has been repeatedly described as coming.
Which platform owns the semantic layer?
Fabric does, and getting this wrong is the most expensive mistake in the pair. Business meaning belongs in the data platform, where it can be governed once and inherited by every consumer.
Fabric’s answer is the Fabric IQ workload, which combines two items over OneLake: the Power BI semantic model, carrying measures, hierarchies, and dimensions, and ontology, currently in preview, which defines entity types, relationships, properties, rules, and actions in business language. Microsoft describes ontologies as generatable from semantic models already in production, so terminology stays consistent across reports, agents, and applications (What is Fabric IQ).
Foundry IQ is a different kind of object, and the similar name causes real confusion. It is a knowledge layer built on Azure AI Search: a multi-source knowledge base connecting to stores such as Azure Blob Storage, SharePoint, and OneLake, queried by an agentic retrieval engine that plans subqueries, runs them in parallel, reranks results, enforces permissions, and returns grounded answers with citations (What is Foundry IQ).
The distinction in one line: Fabric IQ decides what “active customer” means, and Foundry IQ decides which documents to read before answering. Both can be right at once, and Foundry IQ can take Fabric IQ and OneLake as knowledge sources, which is composition rather than overlap.
If your metric definitions live in three places, no amount of retrieval tuning will make agents agree with each other. That failure and the governance work that prevents it are the subject of ontology governance and the semantic layer.
When should the model call live inside Fabric instead of Foundry?
When the unit of work is a column rather than a conversation. Classifying two million support tickets is a data engineering job that happens to call a language model, and pushing it through an agent runtime adds latency, cost, and nothing else.
Fabric AI Functions are built for exactly this. They apply a hosted model across a pandas or Spark DataFrame with one call per operation, covering classification, sentiment, extraction, summarisation, translation, grammar repair, similarity, and embeddings (AI Functions). Calls through the built-in endpoint are billed to your Fabric capacity under the Copilot and AI meter and appear as an AI Functions operation in the Capacity Metrics app, so a data engineering workload that uses a model still shows up on the capacity you already monitor (billing for AI Functions). Prebuilt Foundry tools are callable from Fabric on the same capacity, in public preview (Foundry Tools in Fabric).
Two practical notes. You can point AI Functions at your own Azure OpenAI, Microsoft Foundry, or OpenAI-compatible endpoint, and billing then follows that endpoint. And the documented default model has changed between revisions of the documentation, so read the billing page before sizing a budget rather than repeating a figure from a talk.
Your checkpoint that the accounting works: run the function, then read ai.stats on the result. It reports successes, exceptions, and token counts including cached, input, output, and reasoning tokens. If those numbers do not appear, you are not on the built-in endpoint and the cost is landing somewhere other than where you think. The reasoning behind choosing a per-row call over an agent loop is in cost and latency engineering for LLM systems.
What does each platform not give you?
Fabric does not give you an agent loop, and its data agent has hard documented limits. Foundry does not give you governed business semantics, and it will happily run a beautifully instrumented agent over data nobody has modelled.
The Fabric data agent limits are specific enough to check against your requirement before you promise anything:
| Constraint | Documented limit |
|---|---|
| Data sources per agent | Up to five, in any combination of lakehouse, warehouse, semantic model, KQL database, mirrored database, or ontology |
| Query types generated | Read-only SQL, DAX, and KQL. No create, update, or delete |
| Unstructured content | Not supported. No PDF, DOCX, or TXT files |
| Chat result size | Capped at 25 rows and 25 columns per response |
| Example queries | Up to 100 per data source |
| Tables per source | Guidance is 25 or fewer for best results |
| Model choice | You cannot change the model the data agent uses |
| Language | English only at present |
| Regions | The data source capacity and the agent capacity must be in the same region |
The 25-row cap surprises people, because it turns “export the customer list” into a task the data agent will politely fail at. It is a conversational analytics surface, not an extract mechanism. Foundry’s gaps are the mirror image: Agent Service gives you runtime, tools, tracing, and publishing into Teams, Microsoft 365 Copilot, and the Entra Agent Registry, and no opinion at all about whether your revenue measure is defined twice.
How should the two teams split the work?
Along the published artefact, not along the technology. The data platform team owns everything up to and including the published data agent and the semantic definitions behind it. The AI platform team owns the loop, the tools, the evaluations, and the user-facing surface.
That split produces a contract both sides can test. The data team’s deliverable is a published data agent with a named set of sources, an instruction block, example queries, and a documented row cap. The AI team’s deliverable is an agent that calls it correctly, handles an empty result, and is evaluated on tasks rather than single responses.
The interface needs three things written down: which data agent, which identity model, and what happens on failure. Skip the third and you get an agent that reports a plausible answer when the tool call was denied on permissions, which is worse than an error because it looks like data.
Where this goes wrong
Treating Foundry as a data platform. The symptom is copies of Fabric tables landing in blob storage so an agent can read them. The cause is not knowing the data agent tool exists. Connect the data agent and keep one copy.
Treating Fabric as an agent platform. The symptom is a data agent asked to take actions, write records, or run a five-step workflow. The cause is that a chat box looks like an agent. Data agents generate read queries only, and the loop belongs in Foundry.
Designing for a service principal that is not supported. The symptom is an unattended job that works in the Foundry playground and fails in production. The cause is that the tool runs On-Behalf-Of the user. Design a human-in-the-loop surface, or use a different data path.
Confusing Fabric IQ with Foundry IQ. The symptom is two teams each believing they own a metric definition. The cause is the shared name and adjacent scope. Fabric IQ is business meaning over OneLake, and Foundry IQ is retrieval over knowledge sources.
Running a per-row transformation through an agent loop. The symptom is a classification job that costs more than the pipeline it feeds. The cause is using a conversational runtime for a set-based operation. Use AI Functions in a notebook and read ai.stats to confirm what it spent.
Promising an export from a conversational surface. The symptom is a stakeholder saying the agent is broken because it returned 25 rows. The cause is a documented cap nobody read. Build a report or a pipeline for extracts.
Common questions
Is Microsoft Foundry the same as Azure AI Foundry?
Yes, it is the current name for the same platform, renamed at Ignite in November 2025 and called Azure AI Studio before that. Both documentation paths are still reachable, so you will see ai-foundry and foundry URLs in search results. Treat the foundry paths as current.
Do I need Fabric to use Foundry?
No. Foundry works against any data source you connect. Fabric becomes relevant when the data your agent needs is governed analytics data, because a published Fabric data agent then gives you query generation and per-user permission enforcement rather than something you build yourself.
Which one enforces row-level security?
Fabric does, and it reaches into Foundry because of the identity model. The data agent tool runs the query as the signed-in user through On-Behalf-Of authorization, so Power BI row-level security and semantic model permissions apply per person. That enforcement is a property of the user token, which is why the same guarantee does not hold for a service identity.
Can a Foundry agent write data back into Fabric?
Not through the data agent, which generates read-only queries by design. A write has to go through something built for it, such as a pipeline, a notebook, or an API in front of a Fabric database, and it belongs behind an approval gate rather than inside the model’s tool loop.
Where should the ontology live if we have both platforms?
In Fabric, as an ontology item in the Fabric IQ workload, generated from semantic models already in production where possible. One definition is then inherited by reports, data agents, and any Foundry agent reaching back through them, rather than each consumer carrying its own version of what a customer is.
Next steps
Write down the one-turn test for your current use case: does this request resolve into a single read-only query, and does anything get written. If it is one query and nothing is written, build the Fabric data agent and stop there. Otherwise you need a runtime, and the boundary you just drew is the interface between the two teams.
Then read Databricks and Fabric together and where governance leaks, because the identity question here has an exact parallel at the storage boundary, and choosing a data platform in 2026 by workload if the underlying decision is which platform to standardise on. We publish what we test in AI Fieldwork, and more engineering writing sits in the Signals index.