Microsoft Foundry, AWS Bedrock, Google Vertex AI: The Real Differences in Building Agentic AI
I’ve spent this week teaching AI-901, and if you’ve taken that course recently, you’ll know the syllabus has shifted towards Microsoft Foundry. Not Copilot. Not chatbots. Foundry. The platform for choosing a model, wiring up tools and data, and shipping an actual agent that does something on your behalf. Some might call that Agentic AI.
That’s the shift I’m seeing. A lot of client conversations I’m having right now aren’t “can we use AI”. It’s “which platform do we build our agents on, and why.” So let’s get into it: what Microsoft Foundry actually is, and how it stacks up against AWS Bedrock and Google Vertex AI, the two other “foundry-type” platforms doing the same job on the other clouds.
What Microsoft Foundry actually is
Microsoft Foundry (also referred to as Azure AI Foundry in older docs and exam material) is Microsoft’s unified platform for building, evaluating, and deploying AI agents and models. The pitch is straightforward: pick a model from a catalogue spanning OpenAI, Anthropic/Claude Meta, Mistral, DeepSeek, and Microsoft’s own models, ground it with your data, give it tools, and deploy it as an agent. And you can do all that within a single governed environment that plugs into the rest of your Azure estate.
What AI-901 candidates need to understand isn’t the button-clicking. It’s the architectural point: Foundry decouples the model from the agent. You’re not locked into GPT-anything. You choose the model per use case, considering a range of factors like cost, latency, capability, data residency and so on. The agent logic sits on top, largely model-agnostic. That’s the commercially interesting bit, not the model catalogue itself.
The three foundry platforms, compared
Microsoft Foundry
Strongest where the client is already an Azure and Microsoft 365 shop. The integration with Entra ID for agent identity, with Fabric for grounding data, and with Copilot Studio for the low-code end of agent building is genuinely difficult for the other two to match if your data already lives in that ecosystem. Model choice is broad and growing fast. Governance tooling, content safety, evaluation, tracing, is mature and audit-friendly, which matters more than most vendors admit once you’re past the demo stage.
AWS Bedrock
Bedrock’s equivalent play is Bedrock Agents, sitting on top of the same multi-model catalogue idea — Anthropic, Meta, Amazon’s own Titan/Nova models, Mistral, and others. Where Bedrock earns its keep is infrastructure maturity: if a client is already deep into AWS for compute, storage, and IAM, the operational fit is excellent. It’s less polished on the low-code/business-user end than Copilot Studio, and the agent orchestration tooling has historically felt more developer-first than Microsoft’s.
Google Vertex AI (Agent Builder)
Vertex AI’s Agent Builder leans hardest into Gemini natively, though it does support other models. Its genuine strength is search and retrieval grounding — Google’s heritage shows. For clients heavily invested in BigQuery and the Google data stack, or wanting best-in-class RAG out of the box, it’s a serious contender. It’s the weakest of the three on enterprise governance maturity at the time of writing, though that gap is closing fast.
The take: model catalogue isn’t the differentiator anymore
Here’s where I keep correcting people in training sessions. Everyone gets excited comparing model lists — “does it have Claude, does it have Llama, does it have DeepSeek.” Stop. All three platforms now offer credible multi-model access. That race is largely over and it’s not where the value sits.
The real decision criteria are: where does your data already live, what’s your existing identity and governance model, and who’s building the agents — developers, or business analysts using low-code tools? Microsoft wins on the third point for most of my client base, because Copilot Studio genuinely does let a competent business analyst build a working agent without a developer in the room. Bedrock and Vertex still assume more engineering capability by default.
If you’re evaluating platforms right now, don’t start with the model catalogue. Start with your data estate and governance requirements, then determine which platform incurs the least friction to get an agent into production safely.
Where to go next
If you’re weighing up which platform to build your agent strategy on. Or your team needs to get from “we’ve heard of Foundry” to “we’ve shipped a production agent”, then that’s exactly the kind of engagement I run. Have a look at the AI enablement consulting and workshops I deliver, or get in touch and we’ll talk through what fits your stack.
0 Comments