Introduction
If you've been working in the Azure AI ecosystem, you've likely noticed a seismic shift happening at ai.azure.com. What was once Azure AI Studio, then became Azure AI Foundry, and has now been rebranded as Microsoft Foundry β but the rebrand is the least interesting part. The architecture, portal experience, agent capabilities, and developer workflows have been fundamentally redesigned.
Microsoft now ships two portal experiences side by side β Foundry (New) and Foundry (Classic) β accessible via a toggle in the portal banner. But this isn't just a UI facelift. Under the hood, the resource model, project hierarchy, agent framework, tool ecosystem, and governance surface have all changed in meaningful ways.
This article breaks down every major difference across every layer of the stack so you can make an informed decision about when to migrate, what you'll gain, and what still requires the Classic experience.
1. The Branding & Naming Evolution
|
Era |
Name |
Portal URL |
|
Pre-2024 |
Azure AI Studio |
ai.azure.com |
|
Mid-2024 to Late 2025 |
Azure AI Foundry |
ai.azure.com |
|
2026 (Current) |
Microsoft Foundry |
ai.azure.com |
π‘ Key Point: "Azure AI Foundry" is now "Microsoft Foundry." Screenshots across Microsoft Learn documentation are still being updated. Both portals live at the same URL β a toggle in the top banner lets you switch between (New) and (Classic).
2. Portal Philosophy: When to Use Which
|
Portal |
Best For |
|
Foundry (Classic) |
Working with multiple resource types: Azure OpenAI resources, Foundry resources, hub-based projects, and Foundry projects. Use this when you need features not yet available in the new experience (e.g., Prompt Flow, open-source model deployments on managed compute, Azure ML workloads). |
|
Foundry (New) |
A streamlined, agent-first experience for building, managing, and scaling multi-agent applications. Only Foundry projects are visible. Hub-based projects, Azure OpenAI standalone resources, and legacy project types are not shown. |
The new portal is not a superset of the classic portal β it is a focused reimagining for the agentic AI era. If you need legacy ML capabilities, you still switch back to Classic.
3. Resource Architecture & Project Hierarchy
Foundry (Classic): The Hub-Based Model
Classic supports two project types:
- Hub-Based Projects β Built on the Microsoft.MachineLearningServices resource provider. A "Hub" (Azure AI Hub) acts as the parent resource, and projects are children of that hub. Hubs required provisioning extra resources: Azure Storage, Azure Key Vault, and optionally Azure Container Registry as mandatory sibling resources.
- Foundry Projects β A newer project type introduced under the Microsoft.CognitiveServices provider. These are child resources of a Foundry Resource (kind: AIServices).
Foundry (New): One Project Type to Rule Them All
The new portal only surfaces Foundry Projects. The resource hierarchy is simplified:
Foundry Resource (Microsoft.CognitiveServices/account, kind: AIServices)
βββ Foundry Project (Microsoft.CognitiveServices/account/project)
βββ Project Assets (agents, evaluations, files, indexes)
|
Aspect |
Classic (Hub-Based) |
New (Foundry Project) |
|
Resource Provider |
Microsoft.MachineLearningServices |
Microsoft.CognitiveServices |
|
Parent Resource |
AI Hub |
Foundry Resource (AIServices) |
|
Required Sibling Resources |
Storage Account, Key Vault (mandatory) |
None required by default |
|
Project Isolation |
Via Hub RBAC |
Native project-level RBAC |
|
Agent Service GA |
Preview only |
General Availability |
|
Foundry SDK & API |
Limited |
Full support |
|
ML Training (AutoML, Pipelines) |
Yes |
No (use hub-based project) |
|
Prompt Flow |
Yes |
No |
|
Managed Compute (HuggingFace) |
Yes |
No |
π‘ Critical Takeaway: New generative AI and model-centric features are available only through the Foundry Resource and its Foundry projects. Hub-based projects will not receive new agent or model features.
4. Resource Provider Unification
One of the most impactful architectural changes is the consolidation under the Microsoft.CognitiveServices provider namespace:
|
Resource |
Provider |
Kind |
|
Microsoft Foundry |
Microsoft.CognitiveServices/account |
AIServices |
|
Foundry Project |
Microsoft.CognitiveServices/account/project |
AIServices |
|
Azure Speech |
Microsoft.CognitiveServices/account |
Speech |
|
Azure Language |
Microsoft.CognitiveServices/account |
Language |
|
Azure Vision |
Microsoft.CognitiveServices/account |
Vision |
This means:
- Unified RBAC: The same Azure RBAC actions work across Foundry, Azure OpenAI, Speech, Vision, and Language.
- Unified Azure Policy: Existing custom Azure Policies continue to apply if you're upgrading from Azure OpenAI to Foundry.
- Unified Networking: Private Link, VNet configuration, and network isolation share the same management patterns.
In contrast, hub-based projects under Microsoft.MachineLearningServices had a completely separate RBAC model, networking stack, and policy surface.
5. Security & Governance: Separation of Concerns
Foundry (New) β Clear Control Plane vs. Data Plane Separation
|
Layer |
Scope |
Who |
Examples |
|
Control Plane |
Foundry Resource (top-level) |
IT Admins |
Create deployments, configure networking, manage projects, set encryption |
|
Data Plane |
Foundry Project (child) |
Developers |
Build agents, run evaluations, upload files, test in playground |
This means IT can set up governance once at the resource level, and developers can self-serve by creating projects as isolated workspaces without needing admin intervention.
Starter RBAC Assignments:
- Azure AI User for each developer at the Foundry Resource scope
- Azure AI User for each project managed identity at the Foundry Resource scope
Foundry (Classic) β Hub-Centric Governance
In Classic, hub-based projects relied on the Hub as the governance boundary. This worked but required IT to manage the Hub and its dependent resources (Storage, Key Vault). Foundry projects under Classic had the same new governance model as above, but the portal experience was merged with hub-based projects, adding confusion.
6. Agent Service: The Biggest Leap Forward
The Foundry Agent Service is arguably the reason Microsoft rebuilt the portal experience. Here's how agent capabilities differ:
Foundry (Classic) β Agent Service in Preview
- Agents available in preview only within hub-based projects
- Agents in GA within Foundry projects (accessed through Classic portal)
- Single-agent interactions primarily
- Limited tool selection
- Basic observability
- Required connection strings for SDK authentication
Foundry (New) β Agent Service, Fully Realized
a) Multi-Agent Orchestration & Workflows
Build advanced automation with the visual workflow builder using SDKs for C# and Python. Supports:
- Sequential workflows β Agent A β Agent B β Agent C in defined order
- Group Chat β Dynamic control passing between agents based on context
- Human-in-the-loop β Approval steps, clarifying questions mid-workflow
- Visual YAML editor β Edit workflows visually or in YAML; changes sync in real-time
- Power Fx integration β Excel-like formulas for conditional logic, variable handling, data transformations
- Versioning β Every save creates an immutable version with full history
b) Agent Types
|
Type |
Kind |
Description |
|
Prompt Agent |
prompt |
LLM-backed agent defined declaratively with model config, instructions, tools, and prompts |
|
Hosted Agent |
hosted |
Containerized agent running custom code, deployed and managed by Foundry |
|
Workflow |
YAML-based |
Orchestrates multiple agents together using agentic patterns |
c) Memory (Preview β New Only)
Long-term agent memory is a brand-new capability:
- User Profile Memory: Stores preferences, dietary restrictions, language preferences β persists across sessions
- Chat Summary Memory: Distilled summaries of conversation topics for cross-session continuity
- Three Phases: Extraction β Consolidation β Retrieval
- Memory search tool or low-level Memory Store APIs
- Supports up to 10,000 memories per scope, 100 scopes per store
d) Foundry IQ β Knowledge Integration (Preview β New Only)
A managed, multi-source knowledge base for enterprise content:
- Connects to Azure Blob Storage, SharePoint, OneLake, and public web
- Automated document chunking, vector embedding generation, metadata extraction
- Agentic retrieval engine: Decomposes complex questions into subqueries, executes in parallel, semantically reranks, returns unified responses with citations
- Permission-aware: Synchronizes ACLs, honors Microsoft Purview sensitivity labels, enforces permissions at query time
- One knowledge base can serve multiple agents
e) Expanded Tool Catalog (Preview β New Only)
The new portal introduces a Foundry Tool Catalog with 1,400+ tools:
|
Tool Category |
Examples |
|
Built-in |
Azure AI Search, Code Interpreter, File Search, Grounding with Bing, Image Generation, Computer Use, SharePoint, Microsoft Fabric, Browser Automation, Web Search |
|
MCP Servers (Remote) |
Publisher-hosted servers using Model Context Protocol |
|
MCP Servers (Local) |
Self-hosted MCP servers connected to Foundry |
|
Custom |
OpenAPI 3.0 specs, Agent-to-Agent (A2A) endpoints, custom MCP endpoints |
|
Private Catalog |
Organization-scoped tools visible only to your team |
Classic had a much smaller tool surface: primarily Azure AI Search, File Search, Code Interpreter, and custom functions.
f) Integration & Publishing Capabilities
The new portal supports:
- Publish agents to Microsoft 365, Teams, and BizChat
- Containerized deployments for portability
- Open protocol support: MCP and A2A with full authentication
- AI Gateway integration (Azure API Management)
- Azure Policy integration for agent governance
7. Model Deployment: What Changed?
The model deployment story is shared across both portals but the new portal streamlines the experience significantly.
Deployment Types (Available in Both)
|
Deployment Type |
SKU |
Data Processing |
Billing |
|
Global Standard |
GlobalStandard |
Any Azure region |
Pay-per-token |
|
Global Provisioned |
GlobalProvisionedManaged |
Any Azure region |
Reserved PTU |
|
Global Batch |
GlobalBatch |
Any Azure region |
50% discount, 24-hr target |
|
Data Zone Standard |
DataZoneStandard |
Within data zone (EU/US) |
Pay-per-token |
|
Data Zone Provisioned |
DataZoneProvisionedManaged |
Within data zone |
Reserved PTU |
|
Data Zone Batch |
DataZoneBatch |
Within data zone |
50% discount |
|
Standard (Regional) |
Standard |
Single region |
Pay-per-token |
|
Regional Provisioned |
ProvisionedManaged |
Single region |
Reserved PTU |
|
Developer |
DeveloperTier |
Any Azure region |
Fine-tuned eval only, no SLA |
Key Differences by Portal
|
Capability |
Classic |
New |
|
Models sold directly by Azure (Azure OpenAI, DeepSeek, xAI) |
Via connections in hub-based; native in Foundry projects |
Native |
|
Partner/Community Models (via Marketplace) |
Via connections in hub-based; native in Foundry projects |
Native |
|
Models on Managed Compute (HuggingFace etc.) |
Hub-based projects only |
Not supported |
|
Serverless API Endpoints |
Hub-based projects |
Standard deployment only |
|
Model Catalog Browsing |
Available without sign-in |
Requires project context |
8. Observability & Monitoring
|
Capability |
Classic |
New |
|
Azure Monitor metrics |
Scoped to resource level |
Scoped to resource + project level |
|
Application Insights integration |
Manual setup |
Built-in for Agent Service |
|
Conversation-level tracing |
SDK-based (manual) |
Real-time in portal with built-in metrics |
|
Evaluation workflows |
Available (preview) |
Available with continuous evaluation via Python SDK |
|
Agent monitoring dashboard |
Not available |
Built-in "Operate" section |
|
Model tracking |
Basic |
Enhanced with centralized AI asset management |
The new portal introduces a dedicated "Operate" section for centralized AI asset management β agents, models, and tools in one place. You can register agents from other clouds, get alerts when agents or models need attention, and manage fleet health at scale.
9. SDK & API Experience
|
Aspect |
Classic |
New |
|
Authentication |
Connection strings |
Project endpoint + DefaultAzureCredential |
|
SDK |
azure-ai-projects (preview) |
azure-ai-projects (GA), unified Foundry SDK |
|
Languages |
Python, C# (GA); JS/TS, Java (preview) |
Same |
|
API Surface |
Foundry API (limited for hub-based) |
Full Foundry API β agents, evaluations, models, indexes, data |
|
VS Code Extension |
Available |
Available (enhanced) |
Migration Example
Classic (Hub-Based, Preview SDK):
# Used connection strings
client = AIProjectClient.from_connection_string(
conn_str="your_connection_string",
credential=DefaultAzureCredential()
)
New (Foundry Project, GA SDK):
from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
project = AIProjectClient(
endpoint="your_project_endpoint",
credential=DefaultAzureCredential()
)
10. Data Storage & Encryption
|
Feature |
Classic |
New |
|
Default Storage |
Microsoft-managed (logical separation) |
Microsoft-managed (logical separation) |
|
Bring Your Own Storage |
Supported |
Supported |
|
BYOS for Agent State |
Standard setup available |
Standard setup available |
|
Customer-Managed Key Encryption |
Supported (FIPS 140-2, 256-bit AES) |
Supported (same) |
|
Bring Your Own Key Vault |
Supported |
Supported |
|
BCDR for Agents |
Customer-provisioned Cosmos DB |
Customer-provisioned Cosmos DB |
The storage layer is largely unchanged between portals β both support the same bring-your-own patterns for compliance.
11. Networking & Private Access
|
Feature |
Classic |
New |
|
Private Link |
Fully supported |
Supported (some limitations for end-to-end isolation) |
|
VNet Integration (Container Injection) |
Supported |
Supported |
|
End-to-End Network Isolation |
Fully supported (SDK, CLI, Portal) |
Partially supported β use Classic, SDK, or CLI for fully isolated deployments |
π‘ Important: If you require end-to-end network isolation in production, Microsoft currently recommends using the Classic experience, SDK, or CLI until the new portal reaches full parity.
12. Navigation & UX Differences
Classic Portal
- Left pane navigation organized by development stages: Define & Explore β Build & Customize β Observe & Improve
- Customizable left pane per project, per user (pin/unpin items)
- Management Center β centralized hub for projects, quotas, permissions, usage metrics
- Breadcrumb navigation showing project type (Hub vs. Foundry)
- Supports browsing model catalog without signing in
New Portal
- Top menu bar with Build/Operate sections
- Project selector in upper-left corner β switch between recently used projects
- "Operate" section for centralized AI asset management (agents, models, tools)
- Streamlined navigation with redesigned interface
- Faster load times with dynamic prefetching
- Only shows default project per Foundry resource; "View all resources" opens Classic portal
13. Foundry Local β Runs Everywhere
A capability that works across both experiences: Foundry Local lets you run LLMs on your own device for free. Integrates with inference SDKs, supports HuggingFace model compilation, and provides a local development loop.
14. Feature Availability Matrix (Comprehensive)
|
Feature |
Classic β Hub-Based |
Classic β Foundry Project |
New β Foundry Project |
|
Agents (GA) |
Preview only |
GA |
GA |
|
Multi-Agent Workflows |
No |
No |
Yes |
|
Memory (Long-Term) |
No |
No |
Yes (Preview) |
|
Foundry IQ Knowledge Base |
No |
No |
Yes (Preview) |
|
Tool Catalog (1,400+ tools) |
No |
No |
Yes (Preview) |
|
MCP & A2A Protocol Support |
No |
No |
Yes |
|
Publish to M365/Teams/BizChat |
No |
No |
Yes |
|
Centralized AI Asset Mgmt |
No |
No |
Yes |
|
Models (Azure OpenAI, etc.) |
Via connections |
Native |
Native |
|
Models on Managed Compute |
Yes |
No |
No |
|
Prompt Flow |
Yes |
No |
No |
|
AutoML / ML Pipelines |
Yes |
No |
No |
|
Evaluations |
Yes |
Yes (Preview) |
Yes (Preview) |
|
Playgrounds |
Yes |
Yes |
Yes |
|
Content Understanding |
Yes |
Yes |
Yes |
|
Fine-Tuning |
Yes |
Yes |
Yes |
|
Datasets & Indexes |
Yes |
Yes |
Yes |
|
Full Foundry SDK & API |
Limited |
Full |
Full |
|
E2E Network Isolation |
Full |
Full |
Partial |
|
RBAC (Resource + Project) |
Hub-level |
Resource + Project |
Resource + Project |
|
Azure Policy Integration |
Yes |
Yes |
Enhanced |
|
Disable Preview Features |
RBAC or Tags |
RBAC or Tags |
RBAC or Tags |
15. Migration Path: Classic β New
Microsoft provides a clear migration guide:
- Step 1: Locate your existing Foundry resource (the AIServices kind resource created alongside your hub)
- Step 2: Create a new Foundry project under that resource
- Step 3: What transfers automatically: Model deployments, data files, fine-tuned models, assistants, vector stores
- Step 4: What doesn't transfer: Preview agent state (threads, messages, files), open-source model deployments, hub project access
- Step 5: Update SDK code β replace connection strings with project endpoints
- Step 6: Optionally recreate connections for tools and data sources
- Step 7: Optionally clean up hub-based projects (keep them if you still need ML training or Prompt Flow)
Estimated migration time: 5β10 minutes for project creation; additional time for agent code migration depending on complexity.
16. When Should You Move to Foundry (New)?
Move now if:
- You're building agentic applications and want GA Agent Service
- You need multi-agent orchestration (workflows, sequential, group chat)
- You want the Tool Catalog, Memory, or Foundry IQ
- You want to publish agents to Microsoft 365/Teams
- You're starting greenfield and want simplified governance
Stay on Classic (for now) if:
- You depend on Prompt Flow for orchestration
- You deploy open-source models on managed compute (HuggingFace, etc.)
- You need Azure Machine Learning features (AutoML, ML Pipelines, training)
- You require fully isolated end-to-end networking in the portal (not just SDK/CLI)
- You have extensive hub-based project investments you're not ready to migrate
Final Thoughts
Microsoft Foundry (New) isn't just a portal redesign β it's a platform pivot from "AI Studio for building chatbots" to "the enterprise AI agent factory." The introduction of multi-agent workflows, long-term memory, Foundry IQ knowledge bases, a 1,400+ tool catalog with MCP/A2A support, and centralized fleet management represents a generational leap.
But it's also an honest work-in-progress. Network isolation parity, Prompt Flow, and managed compute for open-source models are still reasons to keep the Classic experience bookmarked. The good news is that both portals coexist at the same URL, and switching between them is a single toggle.
The direction is clear: Foundry (New) is the future. Start building there. Fall back to Classic only when you must.
Useful Links
- What is Microsoft Foundry?: https://learn.microsoft.com/en-us/azure/foundry/what-is-foundry
- Microsoft Foundry Architecture: https://learn.microsoft.com/en-us/azure/foundry/concepts/architecture
- Foundry Agent Service Overview: https://learn.microsoft.com/en-us/azure/foundry/agents/overview
- Migrate from Hub-Based to Foundry Projects: https://learn.microsoft.com/en-us/azure/foundry-classic/how-to/migrate-project
- Foundry Tool Catalog: https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/tool-catalog
- Foundry IQ Knowledge Base: https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/what-is-foundry-iq
- Agent Memory: https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/what-is-memory
- Workflow Builder: https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/workflow
- Deployment Types: https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/deployment-types
- Microsoft Foundry Portal: https://ai.azure.com
Note: All information sourced from Microsoft Learn documentation as of March 2026. Feature availability may change as Microsoft continues updating both portal experiences.