What Is Microsoft Foundry?

One platform for agents, models, and tools

Before any service name, it helps to know what problem Foundry solves. Building an AI app used to mean stitching together a model service, a vision or speech service, a place to run agents, and separate security settings for each. Microsoft Foundry unifies agents, models, and tools under a single management grouping with built-in enterprise-readiness capabilities, including tracing, monitoring, evaluations, and customizable enterprise setup configurations.

It provides management through unified role-based access control, networking, and policies under one Azure resource provider namespace. In practice, that means one place to decide who can do what, which networks can reach it, and which policies apply, instead of one set of rules per service.

Some of these platform capabilities are in preview, such as the built-in monitoring dashboards, so check the status of a feature before you depend on it in production.

Three kinds of things are built on Foundry:

Read in order: Agents include declarative prompt agents, managed voice-based prompt agents, and hosted agents that run your own code. Models give access to more than 10,000 models from Microsoft, OpenAI, Anthropic, Meta, and others. Tools and knowledge extend agents with built-in tools, memory, and retrieval through a Foundry Toolbox.

Not every project needs an agent. If you only need to send prompts to a model, with no tools or orchestration, a single model call is the place to start.

Choose your build surface

Foundry is reachable from several developer surfaces, and many developers combine them, for example prototyping in the portal and then moving to code. The choice depends on who is building and how much code they want to write.

The same table, said out loud:

• The Foundry portal is best for exploring models, prototyping prompts, and building prompt agents without writing code.
• The SDKs are for building applications in Python, C#, JavaScript, or Java.
• The Azure Developer CLI, called azd, is for scaffolding, running, testing, and deploying hosted agent projects from the command line.
• Visual Studio Code with the Foundry extension is for building and debugging agents in your editor.
• Coding agents and MCP let coding agents such as GitHub Copilot drive Foundry through the Foundry Skill and MCP server.

For AI-103 the SDK path is Python. In code, the current model is a unified project client, the azure-ai-projects 2.x package, plus an OpenAI() client against one project endpoint, instead of several packages against five or more endpoints. One endpoint per project is the idea to remember.

Resource, projects, and connected services

Now the part that shapes every later design decision: how a Foundry deployment is organized. There are four layers, and each has a different owner.

• The Foundry resource is the top-level Azure resource where you manage governance settings such as networking, security, and model deployments.
• A project is the development boundary inside the Foundry resource where teams build and evaluate use cases, reusing existing model deployments and connections without repeated IT setup.
• Project assets are the files, agents, evaluations, and related artifacts scoped to a project.
• Connected resources, such as Storage, Key Vault, and Azure AI Search, are Azure services that the Foundry resource references through connections.

The point of the split is that IT applies central controls at the resource level while development teams work within project boundaries.

The last layer is where people slip. Connected resources have their own governance boundaries, so you manage their networking and access policies independently of the Foundry resource. A connection is a pointer, not a transfer of ownership.

Picture a compliance review that asks you to block public network access to the Key Vault your agents use. Changing the Foundry resource does not do it. You open the Key Vault itself and apply the rule there, and you repeat the exercise for Storage and Azure AI Search.

What lives at which scope

The resource layers map onto Azure Resource Manager types. In Azure Resource Manager, the Foundry resource is Microsoft.CognitiveServices/accounts with the kind AIServices. A project is Microsoft.CognitiveServices/accounts/projects, a subresource of the Foundry resource.

Foundry resources share the Microsoft.CognitiveServices provider namespace with Azure OpenAI, Speech, Vision, and Language. Sharing a namespace means the same management APIs, similar RBAC actions, networking configuration, and Azure Policy aliases.

Scope also decides where an API can be called. Most new APIs are available at the project scope. Some capabilities, however, are available only at the Foundry resource level; for example, the Translator API is available only from the Foundry resource level. Plan the deployment structure around the scopes your workload needs.

Access follows the same split. Control plane actions, such as creating deployments and projects, are distinct from data plane actions, such as building agents, running evaluations, and uploading files. You can scope RBAC assignments at both the top-level resource and the individual project level.

A common least-privilege starter assignment is Foundry User for each developer at the Foundry resource scope. That role was previously named Azure AI User, and its role ID and core permissions are unchanged by the rename, so you may still meet the old name.

Picking the starting shape

Different teams need different shapes, and three of them come up again and again.

• When multiple teams need isolated projects with shared model deployments and centralized governance, the Foundry resource model fits: one Foundry resource, one project per team.
• For single-developer exploration, a Foundry resource with one project is the recommended default.
• If a workload only requires Azure OpenAI completions without agent hosting or evaluation, a standalone Azure OpenAI resource might be sufficient.

The first case is the one exams like. Three teams, shared deployments, and central IT control describe one resource with three projects: the projects give isolation, and the resource keeps deployments and governance in one place. Three separate resources would isolate the teams too, but then nothing is shared and IT manages three sets of settings.

The single-developer case works because one Foundry resource bundles model access, agent hosting, and evaluation tooling. A standalone Azure OpenAI resource might be sufficient when the workload only needs completions. Foundry is the recommended starting point when you also want agent hosting and evaluations.

There is also an older shape you will still see. Hub-based projects remain available in the Foundry (classic) portal, and new investments are focused on Foundry projects in the new portal. A new solution should start with a Foundry resource and its projects.

Old names and the upgrade path

Foundry consolidates several earlier Azure AI services and tools, so older names still appear in blogs, scripts, and portal screens. The ones worth recognizing:

Said in sentences: the platform was previously branded Azure AI Studio and then Azure AI Foundry, and the services once called Azure AI Services are now called Foundry Tools. The agent API moved from the Assistants API to the Responses API, and the terms threads, messages, runs, and assistants became conversations, items, responses, and agent versions.

Many teams arrive from Azure OpenAI, and the move is an upgrade rather than a rebuild. If you upgrade from Azure OpenAI to Foundry, your existing custom Azure policies and Azure RBAC actions continue to apply. The upgrade also preserves your endpoint, API keys, and existing state.

That continuity comes from the shared provider namespace you met earlier: Azure OpenAI and Foundry both live under Microsoft.CognitiveServices, so the policies and role actions you wrote still match.