The Azure AI Foundry you set up last year answers to a new name. Microsoft renamed it Microsoft Foundry, collapsed four separate resource types into one, and swapped the SDK you import, so before anyone deploys a model this series has to pin down what the platform is and how its pieces fit.

One resource, many projects

Start with the words, because Microsoft reuses them and it trips people up. A Foundry resource is a single Azure resource you create in a subscription and a region. It is the security and billing boundary. A project lives inside that resource and is the workspace where you actually build: it holds model deployments, agents, tool connections, and the endpoint your code talks to. One resource can carry many projects, and everything about access and networking is set once at the resource and inherited down.

That is the whole mental model. Role-based access control, private networking, and Azure Policy attach to the resource. Deployments and agents attach to a project. If you gave a team its own project, they get an isolated endpoint and their own agents without you minting a fresh resource, a fresh key vault, and a fresh network rule each time. In the old world that isolation meant standing up separate Azure OpenAI resources and stitching them together. Now it is a project inside one parent.

The portal for all of this is ai.azure.com, with a New Foundry toggle in the banner. Flip it on. The classic view still exists for the older project type, and mixing them up is the most common reason a walkthrough stops matching your screen.

What changed when Azure AI Foundry became Microsoft Foundry

This is not only a paint job. The rebrand from Azure AI Studio, then Azure AI Foundry, to Microsoft Foundry came with a real consolidation of resources, endpoints, and SDKs. If you learned the old names, the table below is the fastest way to translate what you already know into the current platform. The classic portal and hub-based projects still work, but Microsoft is putting new investment into the Foundry projects path, so that is where this series lives.

Read the right-hand column as your target vocabulary for the rest of the series. When Part 11 covers calling models and Part 13 covers the Agent Service, they use these current names. Where a doc still says Assistants or Threads, you are looking at classic material.

Foundry projects or hub-based projects?

There are two project types, and picking wrong is the first fork that costs you rework. A Foundry project is the new default: it gives you agents at general availability, the unified model management, and self-serve setup, all under the single Foundry resource. A hub-based project is the classic shape. A hub is a separate management layer that pools compute and quota across projects and reaches into Azure Machine Learning for open-model hosting and fine-tuning that the Foundry resource does not cover on its own.

My rule is short. New build, no legacy dependency: Foundry project. You already run hubs, or you need the Azure Machine Learning training surface those hubs expose: keep a hub-based project until the feature you rely on lands in the new path. Do not create a hub for a greenfield chatbot because a blog post from 2024 told you to. That is the single most common piece of stale advice I still see.

Your first call against a project

Here is the smallest thing worth running: authenticate with your Azure identity, get an OpenAI-style client bound to your project, and send one prompt through the Responses API. The endpoint is the project endpoint, not a resource or account URL. That single difference is where most first attempts fail.

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient

# endpoint form: https://RESOURCE.ai.azure.com/api/projects/PROJECT
PROJECT_ENDPOINT = "https://acme-foundry.ai.azure.com/api/projects/support-bot"

project = AIProjectClient(
    endpoint=PROJECT_ENDPOINT,
    credential=DefaultAzureCredential(),
)
openai = project.get_openai_client()

resp = openai.responses.create(
    model="gpt-5-mini",
    input="Reply with the single word: ready",
)
print(resp.output_text)

Expected output: ready. Failure mode: if you paste the old resource endpoint, the one ending in openai.azure.com, DefaultAzureCredential still signs you in, then the call returns 404 because the Responses route lives under the project path, not the account root.

What the platform actually gives you

A project is a container, so the value is in what you can put in it. Four things matter on day one. Models: the catalog carries more than 1,900 models from Microsoft, OpenAI, Anthropic, Mistral, xAI, Meta, DeepSeek, and Hugging Face, which Part 3 and Part 4 break down. Agents: the Agent Service builds multi-step agents with the Responses API, covered in Part 13. Tools: a catalog of more than 1,400 connections, both public and private, that agents can call. Memory: recall of context across turns so an agent does not restart cold every message.

Sitting under all of it is the Operate side: tracing, evaluations, and monitoring built into the platform rather than bolted on, plus governance through unified RBAC and Azure Policy. You do not wire those up per project. They are properties of the resource, which is the point of collapsing everything into one. Observability gets its own treatment in Part 23 and Part 25, so here it is enough to know it is present by default.

Pricing sits at the deployment, not the platform

Creating a Foundry resource and a project costs nothing. You pay when you deploy something and use it, and each product inside Foundry, a model, an agent, a tool, carries its own meter. That is worth saying plainly because people assume a platform this broad has a platform fee. It does not. The bill comes from the model deployments you run and the underlying services they touch, and deployment types, which decide whether you pay per token or reserve throughput, get their own part later in the series.

The practical upshot: you can create the resource, add a project, and browse the catalog to plan an architecture without spending a cent, then attach cost only at the moment you deploy a model. Do that exploration first. It is the cheapest way to learn the platform.

Set up a Foundry resource

Creating the resource takes a couple of minutes, and you can do it in the portal or from the command line. In the portal, open ai.azure.com, confirm the New Foundry toggle is on, choose Create, then pick a subscription, a region, and a name. Region matters more than it looks. A model you want may not be offered everywhere, so choose a region where your target model family is listed rather than defaulting to the one nearest you. Part 8 covers regions and quotas in full; for now, pick a region that lists the model you plan to deploy.

Resource creation also stands up your first project, or you add one with a click. Naming deserves a moment of thought, because the project name becomes part of your endpoint. Keep it short, lowercase, and tied to the app rather than the team. Teams get renamed and reorganised. Endpoints hard-coded in a dozen services do not move so easily. A name like support-bot ages better than team-alpha.

From a script, the same thing is one create command against the Azure CLI, which is what you want when the resource should live in source control rather than in someone’s click history. Whichever path you take, the result is identical: one resource, one project, one endpoint, and a role assignment that lets your identity call it. Assign yourself the Azure AI User role at the resource scope, or you will authenticate cleanly and still get an authorization error on the first request. That mismatch, signed in but not permitted, catches people who assume owner on the subscription is enough. It is not, because data-plane calls check the AI role, not the resource-management role.

What breaks when you move from classic?

Most migration pain is not conceptual. It is four concrete swaps, and each one throws a different error if you miss it. First, the endpoint. Classic code points at RESOURCE.openai.azure.com. New code points at RESOURCE.ai.azure.com/api/projects/PROJECT. Paste the old form and you get a 404 on the Responses route, the same failure I flagged with the code sample above, and it is worth repeating because it is the first wall almost everyone hits.

Second, the SDK. Classic apps import some mix of azure-ai-inference, azure-ai-generative, azure-ai-ml, or a raw AzureOpenAI client. New apps import azure-ai-projects 2.x and pull an OpenAI-style client from the project. If your requirements file still pins the old packages, the new endpoint form will not line up with the client you built, and the errors you get will point at the wrong layer.

Third, the agent surface. Assistants, Threads, Messages, and Runs are classic names. The current platform uses Responses, Conversations, Items, and Agent Versions. Code written against the Assistants API keeps running on the classic path, so nothing breaks the day of the rename. New agent work should target the Responses API anyway, so you are not building on a surface Microsoft has stopped extending.

Fourth, API versioning. Classic calls carried a monthly api-version query parameter you had to bump on a schedule. The new v1 stable routes under /openai/v1/ drop that treadmill. If you have automation that rewrites api-version strings across a fleet, you can retire it once every service is on the new routes. The real trouble comes from doing this half way, where the endpoint is new but the SDK is old, or one service moved and a teammate is still calling Assistants. Move one app all the way over before you start the next, and keep classic and new cleanly separated while you do.

How Foundry connects to the rest of Azure

Foundry is not an island, and the parts it leans on are Azure services you may already run. Identity comes from Microsoft Entra ID, which is why DefaultAzureCredential in the code sample worked without an API key: the call authenticates as your Entra identity and the AI role decides what you can do. Logs and metrics flow to Azure Monitor, so the observability built into the Operate view is not a separate silo, it lands where your other telemetry lives. Part 25 goes deep on that path.

Two more connections matter early. Grounding an agent in your own documents runs through Azure AI Search, the retrieval layer Part 12 builds out, wired to a project as a connection rather than a bolt-on. Safety filtering runs through Azure AI Content Safety, which Part 14 covers, and it sits in the request path so you configure it once per deployment. Private networking, when you need it, uses the same Private Link and virtual-network machinery as the rest of Azure, applied at the resource. The pattern holds across all of these: the capability is an Azure service, and the Foundry project is where you connect it and call it. You are not learning a parallel universe, you are wiring familiar services to one endpoint.

My default, a Foundry project, and when a hub still earns its place

If you are starting fresh in 2026, create one Foundry resource, add a Foundry project, and ignore hubs until a specific workload forces the question. Hubs earn their place in exactly two situations: you already operate them and migrating now buys you nothing today, or you need the Azure Machine Learning training and open-model surface that a hub still fronts. Everything else, a chatbot, a RAG service, an agent, is cleaner on a Foundry project with its own endpoint and its own deployment-level quota.

The reason I am blunt about this is cost of reversal. Choosing a Foundry project and later adding a hub for one workload is easy. Building everything on hubs and unwinding it after is not. Pick the lighter default and add weight only where a workload asks for it.

Next, open ai.azure.com, flip the New Foundry toggle, and create one resource with one empty project. That is all you need before Part 3, where we open the model catalog and choose what to actually deploy. For the AWS reading of this same platform question, see the AWS stack overview.

References

• What is Microsoft Foundry (Microsoft Learn)
• Microsoft Foundry product page (Azure)
• Foundry Models overview (Microsoft Learn)

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts