In Short: What Is Microsoft Foundry?
Microsoft Foundry is the production platform for building, deploying, and operating enterprise AI agents and applications on Azure. It hosts the models, the agent runtime, the tools, the identity layer, the observability stack, and the governance controls in a single managed service.
For organisations already running Microsoft Fabric, this matters more than it might first appear. Fabric is where your data lives. Foundry is where your AI agents run. The connection between the two is now the most important architectural decision most data leaders will make in the next twelve months.
What Problem Is Microsoft Foundry Solving?
Building a working AI agent is no longer the hard part. A small team with a model API key and a weekend can ship a useful prototype.
The hard part is everything that comes after. Network isolation. Identity and access control. Observability across multi-step agent runs. Evaluations that catch regressions before users do. Versioning and lifecycle management. Tooling that does not require every team to reinvent the same plumbing. Cost attribution by agent, by model, by user.
Most organisations that have tried to take a homegrown agent into production have hit the same wall: the gap between a working demo and a system the security and compliance teams will sign off on is enormous. Foundry's pitch is to close that gap with managed infrastructure, so engineering teams can focus on agent logic rather than rebuild the same enterprise scaffolding for every use case.
What Is Microsoft Foundry, Exactly?
Foundry has several distinct components, and it helps to separate them clearly.
- Foundry Agent Service - The runtime that hosts agents. Went generally available in March 2026. It supports three types: prompt agents (configured through the Foundry portal with no code), workflow agents (visual orchestration of multiple agents and business logic), and hosted agents (your own code, in any framework, deployed to a managed runtime).
- Foundry Models - A catalogue of more than 11,000 models across OpenAI, Anthropic, Meta, Mistral, xAI, DeepSeek, NVIDIA, and Microsoft's own Phi family. You select models per agent, mix providers within a single workflow, and pay per token consumed.
- Foundry Tools and Toolbox - The mechanism for giving agents access to data and actions. Tools include web search, code interpreter, file search, MCP servers, Logic Apps connectors, Microsoft Fabric Data Agents, SharePoint, and custom APIs. Toolbox provides a unified configuration layer so the same tool definitions work across frameworks.
- Microsoft Agent Framework - The open-source framework, now at v1.0, that unifies Semantic Kernel and AutoGen. You can develop locally and deploy to Foundry Agent Service with a single command.
- Foundry Control Plane - The enterprise governance layer. ARM-based management, RBAC through Microsoft Entra, end-to-end private networking with bring-your-own VNet, customer-managed keys, and full observability through Azure Monitor.
- Evaluations and Memory - Out-of-the-box evaluators for coherence, relevance, groundedness, and safety, plus custom evaluators in preview. Memory is a managed long-term store that persists context across agent sessions without requiring a separate vector database.
The point of grouping these together is not feature volume. It is that they share an identity model, a security boundary, a billing surface, and an observability pipeline. That coherence is what makes the platform usable in regulated environments.
What Changes for Organisations Already Running Fabric?
This is where the strategic value lands.
- Fabric Data Agents become tools, not endpoints - A Fabric Data Agent answers natural-language questions over your Lakehouse, Warehouse, or semantic model. On its own, it is a useful self-service layer for analysts. Connected to Foundry Agent Service as a tool, it becomes a component in a larger agentic workflow. A customer service agent can query your Fabric data layer, take an action in CRM, and write back to your operations system - all in a single governed conversation.
- The data and AI estates share an identity boundary - Foundry agents authenticate through Entra. Fabric workspaces authenticate through Entra. Row-Level Security in Fabric is honoured when a Foundry agent queries a Fabric Data Agent on behalf of an end user. There is no impedance mismatch between data permissions and AI permissions, which removes one of the most common reasons enterprise AI projects stall.
- Observability spans both layers - Tracing in Foundry Control Plane captures the full agent execution, including tool calls into Fabric. When something goes wrong, you can see whether the agent picked the wrong tool, the tool returned incorrect data, or the model misinterpreted the result. This is a meaningful step beyond "the agent gave a bad answer, we don't know why".
- Cost attribution becomes possible - Foundry costs surface in Azure Cost Management at the resource, deployment, agent, and run level. Combined with Fabric capacity reporting, you can finally answer the question business stakeholders actually ask: how much does this AI feature cost us per use?
Where Does Foundry Fit in the Microsoft Data and AI Stack?
The cleanest way to think about the stack:
OneLake and the Fabric workloads sit at the bottom as the data foundation. Power BI sits on top as the BI consumption layer. Fabric Data Agents sit alongside Power BI as the natural-language consumption layer over governed data.
Foundry sits one level above that, as the agent and AI application layer. It consumes Fabric through Data Agents and direct connections, it consumes line-of-business systems through Logic Apps connectors and MCP servers, and it produces agent experiences that surface into Microsoft 365 Copilot, Teams, custom applications, or the Foundry portal itself.
This separation is intentional. Fabric is opinionated about data. Foundry is opinionated about agents. Each does its job well, and the integration between them is what creates the platform effect Microsoft is positioning around.
The Strategic Point Most Organisations Miss
Foundry is not a faster way to build chatbots. Treating it that way is the most common and most expensive mistake.
Foundry is an opinionated platform for building agentic systems that do work. The difference matters. A chatbot answers questions. An agent reads context, decides which tool to use, executes it, evaluates the result, and either acts again or returns. The platform infrastructure required to do that reliably at enterprise scale is substantial, and that is what Foundry actually delivers.
Organisations that adopt Foundry expecting "Copilot Studio with extra steps" end up underwhelmed. Organisations that adopt it as the production runtime for systems that take action across their data estate, line-of-business applications, and customer touchpoints get something genuinely different.
The investment is not in the platform. It is in identifying the workflows worth automating with agentic systems, getting the data layer in shape so agents can rely on it, and building the operational practice - evaluations, monitoring, iteration - that keeps agents trustworthy in production.
Who Will Get the Most From Microsoft Foundry?
Foundry is most relevant for organisations that:
- Already run, or are committed to running, on Microsoft Fabric, Azure, or the broader Microsoft 365 stack
- Have specific business workflows where an agent could meaningfully reduce manual work or compress decision cycles
- Operate in regulated environments where private networking, Entra-based identity, and audit trails are non-negotiable
- Have a governed data layer - or are building one - that an agent can reliably query
- Want optionality across model providers and agent frameworks rather than lock-in to a single vendor's stack
Organisations still in the prototype phase, or those without a clear use case beyond "we should do something with AI", should not start with Foundry. The platform is designed for production. Use lighter-weight tools to validate the use case first, then move to Foundry when the question becomes "how do we run this reliably at scale".
Why Work With Solv Systems on Microsoft Foundry?
At Solv Systems, we connect Microsoft Foundry to the data layer underneath it, so agents have something solid to reason over.
Data Estate First
We start with what your agents will need from your data layer, not with the agent itself. If the Gold layer is not modelled correctly, no agent will give reliable answers, regardless of which model it uses.
Agent Architecture That Holds Up
We design multi-agent workflows with clear separation of concerns: orchestration, retrieval, action, and validation. This is what makes the difference between a demo and a system that holds up under real production load.
Governance Built In
We build within your existing Entra, Purview, and Fabric governance model so security and compliance are enforced by infrastructure, not by prompt engineering.
Operational Practice From Day One
We help your team establish the evaluation, monitoring, and iteration practices that keep agents trustworthy after launch. The platform supports this. It does not do it for you.
