Most people still treat Microsoft Foundry as “Azure OpenAI with a nicer UI.” That framing is one platform version behind, and if you’re architecting enterprise AI on that assumption, you are building on a misunderstanding.

Since its rebranding at Ignite 2025, Foundry has become a full control-plane-centric agentic platform. Here are the three things that matter most: no fluff, no feature lists.

1. Microsoft Foundry Architecture Changed, Not Just the Name

The old way of building AI on Azure meant stitching five separate PaaS resources together: Azure OpenAI, AI Search, Container Apps, Key Vault, and Storage, with custom glue code to wire them together. You owned the networking, the monitoring, and every security configuration individually.

Foundry replaces that with a single Control Plane resource under Microsoft Cognitive Services, a kind of AI Services. Every team in your organization provisions one Foundry resource. Projects are isolated sub-boundaries inside it. The Foundry Gateway sits in front of everything and handles four things your glue code used to handle:

• Security: Identity enforcement via Entra ID — no more API keys scattered across config files
• Routing: Dynamic routing to the optimal model backend based on prompt complexity
• Observability: OpenTelemetry traces, token spend, and agent logs aggregated in one view
• Protection: Microsoft Defender scans every request for prompt injection and data exfiltration
  
  If you’re on Azure OpenAI today, your existing RBAC policies and custom Azure Policy definitions carry over, and they share the same Microsoft.CognitiveServices provider namespace. Migration is additive, not a rebuild.

2. Agents Now Have Memory And Can Wait for a Human

Two capabilities released in the last six months fundamentally change what enterprise agents can do in production.

The first is long-term agent memory. Foundry’s Agent Service now includes a fully managed four-phase memory pipeline — it extracts key context from each conversation turn, consolidates it across sessions using an LLM merge pass, retrieves relevant memories at query time using hybrid DiskANN + keyword search, and injects them into the agent’s system prompt automatically. No custom vector database. No embedding pipeline to maintain.

The second is Durable Agent Orchestration, released in February 2026. For the first time, agents can pause indefinitely for a human decision and survive process restarts while waiting. The pattern pairs Azure Durable Functions with the Microsoft Agent Framework:

# Agent analyses a vendor, then PAUSES for procurement approval 
analysis = yield context.call_activity('run_vendor_risk_analysis', vendor_id) approval = yield context.wait_for_external_event('HumanApproval') 
# Can wait hours, days — survives restarts, resumes exactly here 
if approval['status'] == 'approved':     yield context.call_activity('execute_vendor_action', analysis)

# Agent analyses a vendor, then PAUSES for procurement approval 
analysis = yield context.call_activity('run_vendor_risk_analysis', vendor_id) approval = yield context.wait_for_external_event('HumanApproval') 
# Can wait hours, days — survives restarts, resumes exactly here 
if approval['status'] == 'approved':     yield context.call_activity('execute_vendor_action', analysis)

This pattern — agent does the reasoning, human makes the call, agent continues — is the answer to the compliance question that kills most enterprise AI deployments: “Who actually approves this?”

Real use cases: vendor contract approvals, incident remediation sign-offs, clinical document flagging workflows. Anywhere a decision needs a human signature before an action is executed.

3. MCP Turns Your Entire Data Stack Into Agent Tools

Model Context Protocol (MCP) is now GA in Foundry, and the implications for data platform teams are significant. The Foundry Tools registry gives every agent in your organization access to 1,400+ enterprise systems — SAP, Salesforce, Dynamics 365, SharePoint, Fabric — through a single, governed entry point.

For those of us working on Databricks and Microsoft Fabric architectures, the two integrations that matter most are:

• Databricks Genie Spaces: Agents query your lakehouse in natural language; Unity Catalog enforces table- and column-level access at runtime. The agent never bypasses your governance layer.
• Microsoft Fabric data agents — agents invoke Fabric datasets and dataflows directly, so operational data flows into agentic reasoning without an ETL step in between.

What this means practically: the boundary between your data platform and your AI layer is dissolving. An agent that can reason over your Unity Catalog-governed lakehouse, pull vendor spend from SAP via MCP, and cross-reference contract terms from SharePoint — without you writing a single custom connector — is now a weekend prototype, not a six-month project.

Security note: Each MCP connection is RBAC-governed independently. Security teams assign tool-level access per agent identity — not per user, per agent. Audit trails flow through Azure Monitor at the Foundry resource level.

The bottom line: Foundry in 2026 is not a model playground. It is a governed, memory-capable, human-in-the-loop agentic platform that connects natively to your entire data estate. If you are still evaluating it as a place to call GPT-4, you owe yourself another look.

Have questions or building something similar on Foundry? Drop a comment, I would love to hear what you’re shipping.