Microsoft Foundry at Build 2026: From AI Agent Demos to Production-Ready Enterprise Systems

The Demo-to-Production Gap Is Where Enterprises Get Hurt

This article is part of the EPC Group Microsoft Build 2026 series. For the full strategic read on Project Solara, the Copilot Super App tease, MAI, Scout, MDASH, and RTX Spark — see the pillar: Project Solara, the Death of Apps, and the One Copilot That Wasn't.

There's a specific kind of meeting I've sat through dozens of times over the past eighteen months. A vendor — or sometimes an enthusiastic internal team — shows a beautiful demo of an AI agent completing a multi-step workflow: searching data, drafting a response, routing a task, updating a record. Everyone in the room nods. Somebody says, "We should do that." Then a hand goes up in the back: "What happens when it's wrong?" The room gets quieter.

That gap — between what an agent can do in a controlled demo and what it does reliably, safely, and economically at enterprise scale — is what Microsoft spent a meaningful portion of Build 2026 trying to address. The vehicle is Microsoft Foundry, and the story it tells is worth dissecting carefully, because it's not just a product announcement. It's a statement about what production AI actually requires.

After 29 years building on Microsoft infrastructure, I've seen a lot of platform inflection points. Some of them were real. I think this one is, too — with important caveats for any enterprise architecture team that's serious about governance and cost control.

---

What Microsoft Foundry Actually Is (and Isn't)

Microsoft Foundry — formerly Azure AI Foundry — is the platform Microsoft has assembled for the full agent lifecycle: building, deploying, governing, and monitoring agents across an enterprise. What makes the Build 2026 announcements notable isn't any single feature. It's the accumulation of capability that addresses, at last, the layers every serious architecture team has been asking about.

Foundry is not a drag-and-drop chatbot builder. Think of it instead as the operating environment for agents — the place where runtime, grounding, memory, evaluation, observability, and governance come together under one control plane. If your mental model of Foundry is still "a UI for calling GPT-4," you need to update it before your next architecture conversation.

The key capabilities that reached general availability or meaningful preview at Build 2026:

Multi-Model Runtime: OpenAI, Anthropic, Mistral, DeepSeek, and MAI

Foundry now hosts models from OpenAI, Anthropic, Mistral, DeepSeek, and Microsoft's own MAI family. That breadth is not accidental. One of the most common architectural mistakes I see enterprises make is treating their AI strategy as synonymous with their model choice — as if picking the best model solves the problem. It doesn't. Production systems need model routing: the right model for the right task, priced appropriately, with fallback logic baked in.

Foundry's multi-model architecture makes that possible within a single platform boundary. You're not gluing together five different API contracts from five different vendors and praying the latency holds. The runtime is managed. The observability is unified. That matters enormously when you're running dozens of agents simultaneously and trying to attribute cost, trace errors, and prove compliance.

Foundry Agent Service and the Control Plane

The Foundry Agent Service, paired with observability in the Foundry Control Plane, is where the production story gets serious. An agent running without observability is like a financial process running without an audit log. You might trust it works today, but you cannot prove it, you cannot debug it when it doesn't, and you certainly cannot satisfy your compliance team when they ask what happened to a particular customer record on a particular Tuesday.

The Control Plane provides the instrumentation layer: agent invocations, tool calls, model responses, latency, error rates, and governance signals all flowing into a unified view. For teams that have been running agents cobbled together from disparate SDKs, this kind of centralized observability isn't a nice-to-have. It's the thing that turns an experiment into a system.

OneLake Catalog in Foundry: Data Grounding at Scale

One of the quieter but more significant announcements was the OneLake catalog in Microsoft Foundry reaching general availability. Grounding — giving agents access to authoritative, current, structured data rather than relying on model weights alone — is the single most important determinant of agent quality in enterprise settings. An agent that hallucinates a policy document or invents a contract clause isn't just wrong. It's a liability.

OneLake is Microsoft's single AI-ready data lake that unifies a multi-cloud estate into one addressable catalog. With that catalog directly accessible from within Foundry, agents can be grounded against the same authoritative data sources that power your Power BI reports and Fabric pipelines. That's not a marketing line — it's a meaningful architectural shortcut that previously required significant custom plumbing.

Ontologies as Knowledge Sources: Teaching Agents the Language of Your Business

Also notable from Build 2026: Ontologies are now accessible from Microsoft Foundry as knowledge sources (preview). This is a capability I want enterprise architecture teams to pay close attention to, because it addresses a problem that doesn't get discussed enough.

Most agents fail not because the model is bad, but because the agent doesn't understand the domain. It doesn't know that your "account" in the CRM is different from your "account" in the ERP. It doesn't know the difference between a "project" in finance and a "project" in engineering. Ontologies define business entities and relationships so agents can reason in the language of the business — not the generic language of the internet. Making those ontologies available as first-class knowledge sources inside Foundry is a genuine step toward agents that are actually calibrated to your enterprise context, not just your prompt.

Cosmos DB Agent Memory Toolkit: Persistence That Doesn't Leak

The Azure Cosmos DB agent memory toolkit standardizes persistent memory for agents using Cosmos DB, Azure Durable Functions, and Foundry models working in concert. This sounds technical, but the business implication is straightforward: agents need memory to be useful across sessions, and that memory needs governance the same way any other data store does.

One of the subtler risks of agentic systems is what I call "memory drift" — an agent that accumulates context over time and begins making decisions based on stale or incorrect state. The Cosmos DB toolkit gives architects a managed, consistent pattern for agent memory that can be audited, versioned, and cleared when necessary. That's not glamorous. It's essential.

Foundry IQ: One Retrieval Endpoint to Rule Them All

One of the most significant — and least-covered — announcements from Build 2026 is Foundry IQ, which is now generally available. Think of it as the managed knowledge layer that sits underneath all of Foundry's grounding capability. Rather than requiring agents to maintain separate connections to Work IQ, Fabric IQ, Azure SQL, File Search, and various MCP sources, Foundry IQ unifies all of those behind a single SLA-backed retrieval endpoint.

That matters in practice because knowledge retrieval is where production agent systems fall apart most quietly. You get inconsistent results not because your model is bad, but because query A hit your SharePoint index and query B hit Azure SQL and they were running at different freshness levels with different latency characteristics and nobody had a single visibility window across all of it. Foundry IQ collapses that into one endpoint with a published SLA, and it ships with a Foundry IQ MCP server for agents that communicate via the Model Context Protocol.

Web IQ lives inside Foundry IQ as well — real-time web grounding delivered at sub-165ms latency with zero data retention. For agents that need to reason over current external information without storing it, that combination of speed and data hygiene is precisely the right design for regulated industries.

---

The Open Trust Stack: ACS and ASSERT

Two open-source components from Build 2026 deserve a dedicated conversation because they address the trust layer that most enterprise agent discussions never reach.

ACS — Agent Control Specification is an open standard that gives agent runtimes a deterministic allow/deny decision at five lifecycle checkpoints: input, LLM call, state transition, tool execution, and output. The word "deterministic" is doing real work in that sentence. The governance problem with most current agent deployments isn't that the agent misbehaves dramatically — it's that you can't prove it didn't. ACS provides a formal, auditable control surface at each of those five points, so "the agent was authorized to make that tool call" becomes a statement you can demonstrate, not just assert.

ASSERT — Adaptive Spec-driven Scoring for Evaluation and Regression Testing is a MIT-licensed evaluation and regression framework from Microsoft Research. What makes it practically useful is the design choice: you write behavioral specifications in plain text, and ASSERT converts them into executable test suites. It works across LangChain, CrewAI, LiteLLM, OpenAI, and other frameworks, which means you're not locked into Microsoft's runtime to use Microsoft's evaluation tooling.

Together, ACS and ASSERT form what Microsoft is calling the open trust stack for agents. ACS provides runtime control. ASSERT provides behavioral verification over time. Neither one replaces the governance policy decisions your team needs to make — but both give you the instrumentation to prove that those policies are actually being enforced and that the agent's behavior hasn't drifted since you last checked.

For enterprises in regulated industries where "our AI system behaves as specified" needs to be a documented, testable claim rather than a confident assumption, this open trust stack is the most practical governance tooling Microsoft has shipped to date. Both are open source. Both are usable today.

---

What EPC Group Looks for in Every Foundry Architecture

When we engage with enterprises on Azure AI architecture — whether that's a greenfield agent deployment or a governance audit of something already in flight — there are five questions we always ask before a single line of agent code gets written.

Who owns the data the agent touches? Foundry's integration with OneLake and Fabric's permission model helps here, but it doesn't replace a data ownership conversation. If your governance team can't answer this question, no amount of platform sophistication will save you.

How is the agent's behavior versioned? Agents change when models change, when prompts change, when grounding data changes. The Foundry Control Plane's observability helps you detect behavioral drift, but only if you've established a baseline. Start measuring on day one.

What is the cost envelope, and who controls it? Multi-model routing is a cost governance tool as much as a performance tool. Cheap, fast models for routine tasks; capable, expensive models for complex reasoning. Foundry enables that routing — but someone has to define and enforce the policy.

What happens when an agent is wrong? Not if. When. The answer should be a documented escalation path, a recovery procedure, and a retraining or re-grounding trigger. The Foundry Agent Service gives you the error signals. Your team needs to have a plan for what to do with them.

How do Defender, Purview, and Entra map to this agent? Every agent that touches organizational data is a data subject and a potential security surface. Agent 365 — which reached GA on May 1st, predating Build, and was further extended at Build 2026 with the Agent 365 SDK reaching GA — extends Defender, Entra, and Purview protections to agents through a unified control plane that surfaces unmanaged local agents and provides visual registry mapping. This isn't optional plumbing for enterprises in regulated industries — it's the architecture.

---

The MAI Playground and Cloud Model Access

Foundry also now hosts Microsoft's MAI model family — seven cloud-based models spanning reasoning, image, voice, transcription, and coding — alongside the new MAI Playground. These are Foundry-hosted, cloud-executed models, distinct from the Aion family of local on-device Windows models announced separately in the Windows track at Build 2026. The distinction matters for architecture decisions: MAI models run in Foundry with cloud billing and cloud governance; Aion models run on-device with no cloud dependency. Same company, different execution environments, different governance profiles.

The MAI Playground is a purpose-built evaluation environment for developers to test Microsoft's cloud models against representative workloads before committing to production configurations. For enterprise teams that need to justify model selection to procurement, legal, or compliance stakeholders, having an official evaluation environment matters. "We tested it in the MAI Playground against our workload types" is a more defensible answer than "we ran a few prompts and it seemed good."

---

The Governance Reality Nobody Budgeted For

Here's the part of the Foundry story that doesn't make the keynote slides, but that every enterprise architecture team needs to budget for before they leave this conversation.

The platform capabilities Microsoft announced at Build 2026 are genuinely impressive. Multi-model runtime. Centralized observability. Managed memory. Ontology-grounded knowledge. In aggregate, this is the most coherent production AI platform Microsoft has assembled to date.

But the platform doesn't govern itself. Ontologies don't write themselves. Cost policies don't enforce themselves. Memory governance doesn't happen because someone checked a box.

Every one of these capabilities requires a corresponding human decision — a policy, an owner, a review cadence, a rollback procedure. The organizations that will extract real value from Foundry are the ones that treat it as an engineering and governance problem simultaneously, not as a procurement decision followed by a hope.

At EPC Group, our Virtual Chief AI Officer (vCAIO) program exists precisely because most enterprises don't have someone whose job it is to hold both of those conversations at once. The model is not the product. The system is the product. Foundry gives you the foundation. The architecture around it — data governance, permission modeling, cost controls, observability baselines, escalation paths — that's the work.

---

Frequently Asked Questions

Q: Is Microsoft Foundry the same as Azure AI Foundry?
They are the same platform. Microsoft rebranded Azure AI Foundry to Microsoft Foundry, reflecting a broader positioning as the enterprise agent platform — not just an Azure service.

Q: What is Foundry IQ and how does it differ from just using OneLake directly?
Foundry IQ is a managed knowledge layer that unifies Work IQ, Fabric IQ, Azure SQL, File Search, and MCP sources behind a single SLA-backed retrieval endpoint, with a Foundry IQ MCP server for protocol-compliant agent access. Using OneLake directly requires separate query and indexing wiring for each source. Foundry IQ provides consistency, unified observability, and a single SLA across all of them — which matters when you need to prove retrieval behavior to a compliance team.

Q: What are ACS and ASSERT, and are they production-ready?
ACS (Agent Control Specification) is an open-source standard providing deterministic allow/deny governance at five agent lifecycle checkpoints — input, LLM, state, tool execution, and output. ASSERT (Adaptive Spec-driven Scoring for Evaluation and Regression Testing) is a MIT-licensed framework from Microsoft Research that converts plain-text behavioral specs into executable test suites. Both are open source and available today. They form Microsoft's open trust stack for agents and are the most practical governance instrumentation shipped at Build 2026.

Q: Can I use Foundry without a Microsoft Fabric subscription?
Many Foundry capabilities are available independently of a full Fabric subscription, but deep integrations — particularly around OneLake catalog grounding and Fabric Ontologies — benefit significantly from the full Fabric ecosystem. Evaluate your data architecture first.

Q: What does "agent memory" mean in practice, and why does it matter?
Agent memory allows an agent to retain context across multiple sessions or interactions — for example, remembering that a user prefers certain output formats, or that a particular workflow has already been partially completed. The Cosmos DB agent memory toolkit provides a governed, managed pattern for this persistence so enterprises can audit and control what agents remember.

Q: How does Foundry's observability compare to what we'd build ourselves?
Building your own observability for AI agents is possible, but it requires instrumentation of every tool call, model invocation, and error event — then stitching those signals together in a way that survives model updates and prompt changes. Foundry's Control Plane does that as a managed service, which is a significant engineering cost reduction, especially for teams that are still building out their AI operations function.

Q: Where does EPC Group fit in a Foundry deployment?
EPC Group serves as your Azure AI architecture partner — from initial governance design and data readiness assessment through Foundry deployment, cost modeling, Defender/Entra/Purview integration, and ongoing vCAIO advisory. Contact us at the details below to discuss your specific agent roadmap.

---

Sources

• AI Magazine — Is Microsoft AI the Ultimate Enterprise Trojan Horse?
• Microsoft Azure Blog — Build 2026: Building Agentic Apps with Microsoft Fabric and Microsoft Databases
• The Verge — Microsoft Build 2026 Biggest Announcements
• Mashable — Microsoft Build 2026: Agent-First Future
• PCMag — Microsoft Build 2026 Recap
• Microsoft 365 Dev Blog — Work IQ: Production-Ready Intelligence for Every Agent
• CNET — Microsoft Build 2026 News

---

EPC Group | contact@epcgroup.net | 888-381-9725 | www.epcgroup.net

---

---

---

EPC Group Can Help

Microsoft Build 2026 raised the ceiling on what agentic AI can do across the Microsoft estate — and the floor on what your tenant has to be to deploy it safely. EPC Group has been doing this work for 29 years across Fortune 500 and federal organizations, with six Microsoft Solutions Partner designations and a perfect 100 NPS on G2.

If any of the following sound like your next 90 days, that is exactly the work we do:

• Microsoft 365 Copilot Readiness Assessment — the 30-day tenant audit, Purview labeling, and adoption motion that turns an under-5% Copilot conversion into a measured rollout.
• Governed AI on Microsoft Framework — one named architecture covering Entra, Purview, M365, SharePoint, Fabric, Power BI, Copilot, Defender, and Agent 365. Seven layers, five maturity stages, one accountable owner.
• Virtual Chief AI Officer (vCAIO) — fractional senior leadership for organizations that need the operating model in 2026 but cannot hire a full-time AI executive yet.
• AI Consulting Services, AI Governance, Microsoft Copilot Consulting, Power BI Consulting, Microsoft Fabric Consulting, and Azure Consulting.

Email contact@epcgroup.net, call 888-381-9725, or request a consultation. Senior architects only — no offshore handoff, no junior account managers.

LinkedIn Post

There's a meeting I've been in dozens of times. The AI agent demo is beautiful — multi-step workflow, clean output, everyone's nodding. Then a hand goes up: "What happens when it's wrong?"

That silence is the gap between a demo and a production system. And Microsoft just spent a significant portion of Build 2026 trying to close it with Microsoft Foundry.

I've been building on Microsoft infrastructure for 29 years. Here's my honest read on what was actually announced and what it means for enterprises that are past the proof-of-concept stage.

WHAT FOUNDRY NOW DELIVERS

Microsoft Foundry is the full agent lifecycle platform — runtime, grounding, memory, observability, governance — under one control plane. What reached GA or meaningful preview at Build 2026:

Multi-model runtime: OpenAI, Anthropic, Mistral, DeepSeek, and Microsoft's own MAI models (cloud-hosted in Foundry — separate from the Aion local Windows models), all addressable from a single platform. This isn't just model variety. It's the foundation for intelligent model routing — cheap fast models for routine tasks, capable expensive models for complex reasoning. That routing decision IS a cost governance decision.

Foundry Agent Service + Control Plane observability: Running agents without observability is like running financial processes without audit logs. The Foundry Control Plane gives you invocations, tool calls, model responses, latency, error rates — unified. This is what turns an experiment into a system.

Foundry IQ — now GA: One SLA-backed retrieval endpoint that unifies Work IQ, Fabric IQ, Azure SQL, File Search, and MCP sources. With a Foundry IQ MCP server for protocol-compliant access. Web IQ lives inside it — real-time web grounding at sub-165ms latency with zero data retention. That combination of speed and data hygiene is precisely what regulated enterprises need for external knowledge access.

OneLake catalog in Foundry — now GA: Grounding agents against authoritative data is the single biggest quality lever in enterprise AI. With the OneLake catalog directly accessible from Foundry, you're grounding agents against the same data that powers your Power BI reports and Fabric pipelines. That used to require custom plumbing. Now it's managed.

Ontologies as knowledge sources (preview): Agents fail not because the model is weak — they fail because the agent doesn't understand your domain. Ontologies teach agents the language of your business: that your "account" in the CRM is different from your "account" in the ERP. Making that available inside Foundry is a real step forward.

Cosmos DB agent memory toolkit: Agents need persistence across sessions to be useful. The Cosmos DB toolkit standardizes that memory using Cosmos DB + Azure Durable Functions + Foundry models, with governance baked in. You can audit what an agent remembers and clear it when needed. That matters.

ACS + ASSERT — the open trust stack: Two open-source tools that address the governance layer most enterprises haven't reached yet. ACS (Agent Control Specification) gives runtimes a deterministic allow/deny at five agent lifecycle checkpoints. ASSERT (MIT-licensed, from Microsoft Research) converts plain-text behavioral specs into executable test suites that work across LangChain, CrewAI, LiteLLM, and OpenAI. Together they let you prove agent behavior rather than just assert it.

AGENT 365: EXTENDED AT BUILD, NOT BORN THERE

Quick but important note on framing: Agent 365 reached GA on May 1st, before Build 2026. What Build delivered is the Agent 365 SDK reaching GA — the programmatic control plane that lets you build governance, registry management, and visual agent mapping into your own tooling. The distinction matters because Agent 365 isn't a Build announcement to evaluate; it's an operational reality to deploy against now.

THE GOVERNANCE REALITY

Here's what doesn't make the keynote slides.

Ontologies don't write themselves. Cost policies don't enforce themselves. Memory governance doesn't happen because a checkbox exists.

Every one of these platform capabilities requires a corresponding human decision — a policy, an owner, a review cadence, a rollback procedure. Foundry gives you the foundation. The architecture around it — data governance, permission modeling, cost controls, observability baselines, escalation paths — that is the actual work.

The organizations that get real value from Foundry are the ones that treat it as an engineering AND governance problem simultaneously. Not a procurement decision followed by a hope.

WHAT I LOOK FOR IN EVERY FOUNDRY ENGAGEMENT

Five questions before a single agent goes anywhere near production data:
Who owns the data the agent touches?
How is the agent's behavior versioned?
What is the cost envelope, and who enforces it?
What happens when the agent is wrong — not if?
How do Defender, Entra, and Purview map to this agent?

If your team can't answer all five, the platform won't answer them for you.

At EPC Group, we serve as the Azure AI architecture partner for enterprises navigating exactly this. From governance design and data readiness through Foundry deployment and ongoing Virtual Chief AI Officer (vCAIO) advisory — because the model is one input. The system is the product.

Where is your organization on the demo-to-production journey — and which of those five questions is hardest to answer right now?

#MicrosoftBuild #EnterpriseAI #AzureAI #MicrosoftFoundry #AIGovernance #EPCGroup

---

X Post

Thread 🧵

1/ Microsoft Foundry at Build 2026: multi-model runtime, GA Foundry IQ (one SLA-backed retrieval endpoint unifying Work IQ/Fabric IQ/Azure SQL/File Search/MCP, sub-165ms web grounding), ACS + ASSERT open trust stack, OneLake grounding, Cosmos DB memory, Ontologies.

2/ Note: Agent 365 went GA May 1 (pre-Build). The Agent 365 SDK is the Build item. MAI models = cloud/Foundry. Aion = on-device/Windows. These are different execution environments — keep them distinct in your architecture.

3/ The demo-to-production gap is where enterprises get hurt. ACS gives you deterministic allow/deny at 5 agent lifecycle checkpoints. ASSERT turns behavioral specs into executable regression tests. Platform capabilities are necessary. They're not sufficient.

Full architecture breakdown: https://www.epcgroup.net/microsoft-foundry-build-2026-production-ai-agents/ #MicrosoftFoundry #EnterpriseAI