So Microsoft went and renamed everything again.
What was Azure AI Studio, then became Azure AI Foundry, is now just "Microsoft Foundry." I had to update my workshop slides three times in one year — which, if you have done corporate training, you know that pain. But okay, naming aside, the thing itself is actually worth understanding because it solves a real problem that I am seeing every week with clients.
The part where I explain what it actually is
Microsoft Foundry is basically a platform where you build AI apps and agents without stitching together fifteen different Azure services yourself. That's it. That's the core idea.
Before this, you had Azure OpenAI as one thing, Azure AI Services as another thing, Azure ML Studio doing its own thing, and then like five different SDKs to talk to all of them. I remember one project where we had azure-ai-inference, azure-ai-generative, AND AzureOpenAI() client all in same codebase. Different endpoints, different auth patterns. It was mess.
Foundry takes all of that and puts it under one resource, one endpoint, one SDK (azure-ai-projects 2.x), and one portal at ai.azure.com. You create a Foundry resource, you get a project, and everything lives there — your models, your agents, your tools, your monitoring. Makes sense, right?
What you can actually build with it
Three things, mainly:
First — agents. And not just simple chatbots. Foundry has multi-agent orchestration now, which means you can have multiple agents working together on complex workflows. They have a tool catalog with over 1,400 connectors, memory so agents can remember context across conversations, and something called Foundry IQ which basically grounds your agent responses in your enterprise data with citations. You can publish these agents directly to Teams, Microsoft 365, or containerized deployments.
Second — model deployments. They have what they call "Foundry Models" which is their model catalog. You get OpenAI models obviously, but also DeepSeek-R1, models from Meta, Mistral, and other partners. You can deploy them, fine-tune them, evaluate them — all from same place.
Third — the governance and monitoring piece. This is the part enterprises actually care about, honestly. RBAC, content safety, tracing, real-time monitoring dashboards, evaluation of agentic workflows. The "Control Plane" they call it. If you are shipping AI in production at a company with compliance requirements, this is where you spend most of your time.
Where this gets interesting
One thing I will say — the Foundry Local option is something people are sleeping on. You can run LLMs on your own device, for free, no cloud needed. For development and testing this is huge. I was running models locally last month for a client who had strict data residency requirements and couldn't send anything to cloud during prototyping phase. Foundry Local with HuggingFace model support saved that project.
The SDK story is also finally clean. Python, C#, JavaScript, Java — all supported. Plus a VS Code extension for exploring models and building agents right in your editor. For someone like me who started in .NET world, having first-class C# support and not being treated like second-class citizen to Python is... refreshing.
The thing that bothers me
What happened was I tried to migrate an existing Azure OpenAI resource to Foundry. Microsoft says you can upgrade while preserving your endpoint, API keys, and existing state. In theory, yes. In practice, I hit some rough edges with hub-based projects not showing up properly in new portal. The docs themselves say the portal only shows "default" project for each Foundry resource — if you had multiple projects in classic, you have to go back to classic portal to find them.
Also the terminology changes are annoying. What was "Threads" is now "Conversations." "Assistants" became "Agent Versions." "Runs" are now "Responses." If you have existing code using the Assistants API, you are basically rewriting to the new Responses API. Not a small thing.
And pricing? The platform itself is free to explore but you pay for what you deploy and consume. Each product — models, tools, agents — has its own billing model. Which means cost prediction is still complicated. I have told clients to start small, monitor costs for a week, then scale. Don't just deploy GPT-4 on a provisioned throughput plan day one.
So should you care?
Depends the use case.
If you are building AI apps on Azure and were already juggling multiple services — yes, absolutely migrate. The unified experience alone saves hours of configuration headache. If you are a startup doing one simple RAG app with OpenAI directly, maybe this is overkill for now.
For enterprise teams though, especially ones with 3-4 AI projects running in parallel, Foundry's single resource model with project-level separation, shared RBAC, and centralized monitoring — that's exactly what was missing. I am recommending it to basically every Azure client I work with at this point.
The multi-agent orchestration piece is where I am spending most of my time these days. Building agents that actually work in production, that can use tools, remember context, and not hallucinate on your enterprise data — that's the hard part. Foundry doesn't solve all of it but it gives you the infrastructure so you can focus on the actual AI logic instead of fighting with Azure resource management.
Platform is evolving fast though. Some features still in preview. JavaScript and Java SDKs both marked preview still. So keep that in mind.
