Introduction

If you’ve been working with Azure AI Foundry and suddenly found yourself staring at a completely redesigned portal with a toggle switch at the top, you’re not alone. Microsoft dropped a significant update at Ignite 2025, and the platform we knew as Azure AI Foundry is now Microsoft Foundry.

But here’s the thing. It’s not just a rebrand. The underlying architecture has fundamentally changed, and if you’re building AI agents or applications, you need to understand what’s different.

Let me break this down.

What Actually Changed

The old Azure AI Foundry (now called Foundry Classic) was built around a hub-based architecture. You had AI Hubs that contained projects, and those hubs managed shared resources like compute, connections, and storage. It worked, but it required you to juggle multiple Azure resources behind the scenes.

The new Microsoft Foundry portal takes a completely different approach. It’s hub-less. Your projects now sit directly under a Foundry resource, which acts as a unified platform-as-a-service. One resource. One management layer. Less complexity.

Press enter or click to view image in full size

Here’s the practical difference. In the classic portal, when you created a project, Azure provisioned an AI Hub, a storage account, a container registry, and a Key Vault. Each of these needed separate management. In the new portal, you get a Foundry project that bundles everything under a single resource provider with unified RBAC, networking, and policies.

The Two Portal Experiences

Right now, both portals exist. You can switch between them using a toggle in the banner at the top of the screen. Microsoft Foundry (New) and Microsoft Foundry (Classic) operate on the same underlying platform, but they expose different project types and features.

Foundry Classic still supports:

• Hub-based projects (the old architecture)
• Foundry projects (the new architecture)
• Prompt Flow (currently only available in hub-based projects)
• Azure Machine Learning compatibility

Foundry New supports:

• Foundry projects only
• Foundry Agent Service in GA
• Multi-agent workflows
• Foundry IQ knowledge bases
• The new Foundry Control Plane

If you’re starting something new, Microsoft’s guidance is clear. Use the new portal with a Foundry project. The hub-based approach is legacy, and all new feature development is happening on the Foundry project model.

Press enter or click to view image in full size

What You Get in the New Portal

This is where things get interesting. Microsoft didn’t just reorganize the UI. They added substantial new capabilities that fundamentally change how you build AI agents.

Foundry Agent Service

The Agent Service is now generally available, and it’s the runtime for agentic applications. You can build prompt-based agents, workflow agents, or hosted containerized agents. Each type serves different use cases.

Prompt-based agents are declaratively defined. You specify the model, instructions, and tools in a configuration, and the service handles the rest. Workflow agents let you orchestrate multiple agents together using YAML definitions. Hosted agents give you full control through code while Foundry handles scaling, monitoring, and identity.

The SDK has changed too. If you were using hub-based projects, you connected using a connection string. Foundry projects use an endpoint instead. The API version is 2025-05-01 for GA, and you’ll need to update your code if you’re migrating.

# Old approach (hub-based)
# Used connection string from Azure AI Project

# New approach (Foundry project)
import os
from azure.ai.agents import AgentsClient
from azure.identity import DefaultAzureCredential
endpoint = os.environ["PROJECT_ENDPOINT"]
client = AgentsClient(endpoint=endpoint, credential=DefaultAzureCredential())

Multi-Agent Workflows

This is the feature that solves a real pain point. If you’ve tried to build multi-agent systems before, you know the complexity. Master-worker architectures, context passing, state management, error recovery. It’s a lot of custom code.

The new Foundry portal includes a visual workflow builder. You can drag and drop agents, connect them, and configure handoffs without writing orchestration code. Or if you prefer code, you can define workflows in YAML and version control them.

Press enter or click to view image in full size

The workflows support:

• Sequential execution (pass results from one agent to the next)
• Parallel execution
• Human-in-the-loop controls
• Group chat patterns
• Persistent state across long-running operations
• Error recovery and retries

You can author workflows in VS Code using the AI Toolkit extension, debug locally, and deploy to Foundry with a single click.

Foundry IQ

Traditional RAG implementations are painful. You build chunking logic, manage embeddings, handle different data sources, implement retrieval strategies, and repeat this for every project. Foundry IQ changes that.

Instead of wiring retrieval logic into every agent, you create a knowledge base around a topic. Employee policies, product documentation, support content, whatever. That knowledge base connects to multiple sources like SharePoint, Fabric OneLake, Azure Blob Storage, and even web content. Then any agent in your project can query that knowledge base through a single API.

The retrieval engine is agentic. It doesn’t just do single-shot retrieval. It plans, searches across sources, reflects on the results, and synthesizes answers. You can configure the “retrieval reasoning effort” based on your accuracy and latency requirements.

And because it’s integrated with Purview, access controls are enforced at the document level. Your agents only see what the user is authorized to see.

Press enter or click to view image in full size

Foundry Control Plane

As you scale from one agent to many, governance becomes critical. Who can deploy agents? What data can they access? How do you monitor their behavior? What happens when something goes wrong?

The Control Plane centralizes all of this. Every agent gets a Microsoft Entra Agent ID, treating it like a directory principal. You can apply unified guardrails across inputs, outputs, tool calls, and tool responses. Task adherence, sensitive data detection, groundedness checks, prompt injection mitigation. It’s all configurable in one place.

Observability is built in. You get OpenTelemetry-based tracing, integration with Azure Monitor, and continuous evaluation runs. When something breaks at 2 AM, you have the traces to figure out why.

Press enter or click to view image in full size

Migrating from Hub-Based Projects

If you have existing hub-based projects, you have options. You can continue using them in the Classic portal, but you won’t get access to new features like Foundry Agent Service GA, multi-agent workflows, or Foundry IQ.

To migrate, the process is:

1. Find your Foundry resource (it was created automatically when you created your AI Hub)
2. Create a new Foundry project under that resource
3. Recreate your connections to tools and data sources
4. Update your SDK code to use the new endpoint-based authentication
5. Deploy your models to the new project
6. Test and validate

Your existing model deployments, fine-tuning jobs, and files stay intact in the Foundry resource. You’re essentially creating a new project type that can access those same resources through a cleaner interface.

Important: Don’t delete your Foundry resource (the CognitiveServices/account/kind=AIServices resource). That contains all your existing state. You’re deleting the hub and hub-based project, not the underlying Foundry resource.

When to Use Each Approach

Use Foundry New with a Foundry Project when:

• You’re starting a new project
• You need the Agent Service in GA
• You want multi-agent workflows
• You need Foundry IQ for knowledge retrieval
• You want the Control Plane for governance

Use Foundry Classic with a Hub-Based Project when:

• You need Prompt Flow (not yet available in Foundry projects)
• You have heavy Azure Machine Learning dependencies
• You’re maintaining existing systems that work fine
• You’re following older tutorials that reference the hub architecture

For most new development, especially anything involving AI agents, the new portal is the right choice.

The Model Catalog Got Bigger

One thing worth mentioning. The model catalog in Foundry now includes over 11,000 models. More importantly, Azure is now the only cloud offering both OpenAI and Anthropic models. You can deploy GPT-5, Claude Opus 4.5, Cohere models, Meta Llama, Mistral, and more from the same platform.

The Model Router, now generally available, can dynamically select the best model for each prompt based on your cost, performance, and quality requirements. For multi-agent systems where different agents have different needs, this is powerful.

What This Means for Enterprise Development

Microsoft is positioning Foundry as the “AI app and agent factory.” Not just a place to call models, but a complete platform for building, deploying, and governing AI systems at scale.

The pieces that were bolted on before, like observability, security, and governance, are now built in. The pieces that were separate, like models, agents, tools, and knowledge, are now unified under one resource provider.

For teams building serious AI applications, this matters. You’re not just getting a prettier UI. You’re getting a platform architecture that treats agents as first-class citizens with proper identity, lifecycle management, and operational tooling.

The transition from Azure AI Foundry to Microsoft Foundry isn’t just about changing the name. It’s about changing how we think about AI development. From calling models to operating agent fleets. From building features to building systems.

And honestly, that’s a shift worth making.

About the author

AI & Community | Microsoft MVP | AI/ML Architect.

Izuafa, A (29/04/2026) Building in the New Microsoft Foundry Portal: A Developer’s Guide to the Transition. Building in the New Microsoft Foundry Portal: A Developer’s Guide to the Transition | by Abdulrafiu Izuafa | Medium