Microsoft’s AI platform has evolved quickly. If you have worked with Azure AI Studio, Azure OpenAI, or Azure AI Foundry, you may have encountered several portals, resource types, SDKs, and overlapping terms. Microsoft Foundry is the company’s effort to bring those pieces together into a more coherent platform for building, operating, and governing production AI applications.
What is Microsoft Foundry?
Microsoft Foundry is a unified Azure platform-as-a-service for building and running AI applications and agents. It brings models, agents, tools, project assets, evaluation, monitoring, and enterprise controls under one management experience.
The name also reflects the platform’s evolution. Azure AI Studio became Azure AI Foundry, and Azure AI Foundry is now Microsoft Foundry. This is more than a branding change: Microsoft is consolidating previously separate concepts into a Foundry resource with projects, a common project endpoint, and a more consistent set of APIs and SDKs.
Foundry is not a single AI model, and it is not merely a chat playground. Think of it as an application platform where a team can discover models, build agents, connect tools and knowledge, test quality, deploy solutions, and manage them in production.
Why does Foundry exist?
Building a useful AI prototype has become relatively easy. Turning that prototype into a secure and reliable production system is still difficult. Teams must answer questions such as:
- Which model provides the right balance of quality, latency, and cost?
- How should the application connect to company data and external systems?
- How do we evaluate responses before a release?
- How do we trace failures, monitor usage, and detect regressions?
- How do we apply identity, networking, access control, content safety, and organizational policy?
Microsoft Foundry addresses these concerns as parts of one lifecycle instead of treating model access as the entire solution.
The main building blocks
1. Foundry resources and projects
A Foundry resource is the Azure management boundary for models, agents, tools, and related capabilities. Within that resource, projects give application teams an isolated workspace for code, configurations, connections, evaluations, and other assets.
This structure makes it easier to apply role-based access control, networking, and policy consistently while still separating individual applications or environments.
2. Models
Foundry Models provides a catalog of models from Microsoft, OpenAI, and other providers. Teams can explore models, compare them, evaluate them against real tasks, and select a deployment approach that fits their requirements.
This model choice matters. A smaller, faster model may be ideal for classification or high-volume extraction, while a more capable reasoning model may be appropriate for complex planning or multi-step work. Foundry gives teams a common place to make and revisit that decision.
3. Agents
An agent combines a model with instructions, tools, knowledge, and state so it can perform work rather than only generate text. For example, an agent might answer questions from internal documents, look up an order, create a support ticket, or coordinate several steps in a business process.
Foundry Agent Service supports prompt-based agents as well as hosted agents that run custom code. The platform also provides APIs for conversations and responses, tool integration, memory, and multi-agent scenarios.
4. Tools and knowledge
Models become far more useful when they can retrieve trusted information and take controlled actions. Foundry supports built-in and custom tools, retrieval from enterprise or web content, and integrations that let an agent work with external systems.
This is where a general-purpose model becomes an application tailored to a specific business domain.
5. Evaluation, observability, and governance
AI applications are probabilistic, so traditional pass-or-fail unit tests are not enough. Foundry includes facilities for evaluating response quality and safety, tracing agent activity, monitoring deployed systems, and comparing results over time.
For enterprise use, the platform also integrates with Microsoft Entra ID, Azure role-based access control, network isolation, content filters, and Azure Policy. These controls help platform teams establish guardrails without forcing every application team to invent its own operational model.
How the pieces fit together
A typical Foundry workflow looks something like this:
- Create a Foundry resource and a project for the application.
- Select and test one or more models from the catalog.
- Build an application or agent with instructions, tools, and relevant knowledge.
- Evaluate quality, safety, latency, and cost using representative scenarios.
- Deploy the solution and integrate it with the rest of the application.
- Trace, monitor, and improve the system as prompts, models, data, and user behavior change.
Developers can work through the Foundry portal, the Microsoft Foundry extension for Visual Studio Code, REST APIs, or SDKs for languages including Python, C#, JavaScript/TypeScript, and Java.
Who should pay attention to Microsoft Foundry?
- Application developers can use it to add model and agent capabilities without assembling every infrastructure component themselves.
- Data scientists and AI engineers can compare models, run evaluations, tune behavior, and manage deployments.
- Platform and security teams can provide shared controls for identity, networking, policy, observability, and cost management.
- Architects and technical leaders can use it as a common foundation for multiple AI products instead of allowing each team to create an isolated stack.
A few practical considerations
Foundry can simplify the AI application lifecycle, but it does not remove the need for sound engineering. Teams still need clear use cases, representative evaluation data, thoughtful security boundaries, human oversight where appropriate, and a plan for latency and cost.
The Foundry platform itself is available to explore without a separate platform fee, but the underlying models, agents, tools, storage, networking, and other Azure services have their own billing models. Preview features also require the usual caution before production use.
Where to start
A good first exercise is deliberately small: create a project, choose a model, send a prompt through the playground or SDK, and then add one evaluation. After that, connect a narrowly scoped source of knowledge or a single tool. This progression makes it easier to understand each layer before building a complex agent.
Microsoft’s Foundry overview and Foundry documentation are the best starting points because the platform and terminology are evolving quickly.
Final thoughts
Microsoft Foundry represents a shift from thinking about AI as a model endpoint to treating it as a complete application platform. Its value is not only access to models; it is the surrounding structure for agents, tools, knowledge, evaluation, operations, and governance.
For teams already invested in Azure, that unified approach could make the path from experiment to production considerably more manageable. In future posts, I plan to explore the platform hands-on by creating a project, calling a model from code, and building a simple agent.