Enterprises deploying AI agents at scale face a nested set of decisions: which platform, which model strategy, and whether to build or buy the underlying infrastructure. Get any one wrong and you are looking at stalled pilots, rising costs, and governance gaps you only discover after production deployment.
The binding constraint on enterprise AI is reliability. Capability alone will not carry a deployment into production. There is no universal best platform. But there is a structured way to answer the question for your organisation — one that tests whether the reliability-first thesis holds up against competitors.
Let us walk through it.
Microsoft Foundry vs AWS Bedrock vs Google Vertex AI — which platform leads for enterprise AI agent deployment in 2026?
The leading platform depends on your existing cloud commitment, governance requirements, model diversity needs, and developer tooling preferences. None of the three hyperscalers leads across all dimensions.
Microsoft Foundry offers the widest multi-vendor model range: Anthropic, OpenAI, DeepSeek, Meta, Mistral, xAI, and Microsoft’s own MAI family, all behind Azure-native identity and governance. It leads on governance depth with ACS, ASSERT, and Toolboxes providing runtime safety enforcement, and its CI/CD tooling is the most developer-focused of the three. But Foundry Agent Service is the newest, and the platform ties you to Azure as the runtime environment.
AWS Bedrock hosts 30-plus foundation models with strong curation and the most mature agent service in the market. Its IAM plus CloudTrail plus Macie governance stack is solid, and for AWS-native enterprises it minimises data egress costs. Bedrock Guardrails provides content filtering and denied topics but offers less runtime enforcement depth than Foundry’s ACS and ASSERT combination.
Google Vertex AI Model Garden hosts Gemini alongside select third-party models but has the most constrained multi-vendor breadth. It leads on model training, MLOps, and Gemini-native multimodal workloads, and Vertex AI Agent Builder is strong on Google-native integration. But it is less mature for multi-model agent orchestration, and the Gemini dependency carries the deepest cloud lock-in of the three platforms.
The decision is partly a function of where your data already lives. Foundry for Azure shops, Bedrock for AWS, Vertex AI for GCP. But two factors cut across that: governance requirements (where Foundry leads) and model strategy (where the marketplace matters). Which brings us to the next question.
Single-model strategy vs vendor-agnostic multi-model approach — which is the better enterprise bet?
This is a strategic bet on how the model market will evolve.
A single-model strategy, picking one provider and optimising around that model family, gives you simpler integration, lower evaluation overhead, deeper platform expertise, and potentially lower cost through volume commitments. Deloitte deployed Claude to 470,000-plus employees and trained 15,000 staff on it. That scale only works with a single-model commitment.
The trade-off is lock-in. Companies that picked a single provider in 2023 have started regretting the dependency. When pricing structures changed, they had no leverage. When a particular model underperformed on specific tasks, they had no fallback.
A multi-model strategy preserves optionality. Claude for reasoning-heavy agent tasks, GPT for code generation and multimodal work, MAI for Azure-native cost optimisation with clean commercial data lineage. Foundry’s marketplace architecture is the expression of this bet: a unified model router, Responses API, and integrated governance across providers make multi-model viable at enterprise scale. Routing simple summarisations to a premium model is economically wasteful, and at scale that inefficiency compounds quickly.
The recommendation is conditional. Enterprises with homogeneous agent workloads and strong provider relationships may benefit from single-model. Enterprises with diverse workloads, regulatory requirements, or uncertainty about which models will lead in twelve months should adopt multi-model. As one industry architect put it: “The long-term advantage won’t go to the organisation that commits to the best model of the moment, but to the one that builds an architecture capable of evolving with the entire field.”
How does Microsoft Foundry’s governance stack compare to AWS Bedrock Guardrails and DIY approaches?
Governance is the dimension where managed platforms diverge most from DIY approaches, and it is the binding constraint that determines whether building your own infrastructure is viable.
Foundry’s governance stack combines four layers: Azure Content Safety (ACS) for prompt injection defence including cross-prompt injection attacks, ASSERT for policy-driven evaluation that converts written policies into measurable tests, Toolboxes for scoped tool access managed centrally, and Microsoft Entra ID for per-agent identity with RBAC. Every agent gets a unique Entra Agent ID, giving you visibility into all active agents across a tenant. Agent 365 extends this governance plane across AWS and GCP agents.
Bedrock Guardrails provides content filtering, denied topics, and guardrail versions. It is solid but offers less runtime enforcement depth. No SharePoint ACL mechanism. Vertex AI has safety filters and Model Armor for content safety, with VPC Service Controls for network isolation. No A2A protocol governance equivalent.
For DIY governance, you are assembling content safety (NeMo Guardrails or LlamaGuard), identity management (an Entra-equivalent), audit trails, prompt injection defences, and runtime kill switches from separate components. Each requires integration, testing, and ongoing maintenance as the agent fleet grows. Companies with governance tools get over twelve times more AI projects into production than those without. That infrastructure converts experiments into production systems.
If governance is the binding constraint that determines production readiness, then the hidden costs of building your own infrastructure are the price of closing that governance gap yourself.
What are the hidden costs of building custom agent infrastructure versus adopting Foundry?
The visible costs of building custom infrastructure (licensing, compute, framework selection) are overshadowed by what you do not see coming: ongoing maintenance, governance integration, observability instrumentation, and identity management. Organisations consistently underestimate these by six to twelve months.
Agent frameworks like LangGraph and CrewAI evolve rapidly. Each release may introduce breaking changes. Foundry abstracts this churn behind a managed interface. The governance integration burden described above is not a one-time cost. Each component (content safety, identity, audit trails, prompt injection defences, runtime kill switches) demands ongoing testing and maintenance as the agent fleet grows. Foundry provides built-in tracing plus Application Insights. DIY requires instrumenting every model call, tool invocation, and agent decision from day one.
Identity engineering is the sleeper cost. Each Foundry agent gets a dedicated Entra identity with scoped resource access. Building equivalent infrastructure compounds with agent count.
Then there is opportunity cost. Platform engineers maintaining infrastructure are not building agent logic, evaluating models, or optimising workflows. The most expensive line item is what your team is not doing.
Wakam‘s experience illustrates the pattern. A five-person data science team built a custom AI chatbot. Maintaining it required constant engineering effort, and every new feature took weeks. After pivoting to a platform, they achieved 70 percent employee adoption within two months and deployed 136 AI agents. Doctolib‘s DoctoGPT gained 800 active users, and within days the team was overwhelmed with feature requests. Their guiding principle became: build what is in your core business, buy what will be a side project.
How should enterprises evaluate whether to adopt Foundry versus building their own agent infrastructure?
The evaluation compares Foundry against the fully loaded cost of assembling and maintaining equivalent infrastructure yourself. Five dimensions matter.
Agent fleet size and diversity. A handful of agents can be managed with LiteLLM or Portkey as the model abstraction layer and the Anthropic Agent SDK or OpenAI Agents SDK for orchestration. Hundreds of agents across dozens of teams demand a platform with centralised governance, identity management, and lifecycle tooling.
Governance requirements. If you need EU AI Act compliance, NIST alignment, auditable attestation trails, and runtime safety enforcement, the integration cost of building custom governance must be weighed against Foundry’s integrated stack. The ACS partner ecosystem at launch includes Infosys, KPMG, IBM, and others, which tells you how much integration work the open standard replaces.
Model strategy. If you want multi-model optionality, Foundry’s marketplace and Responses API reduce the integration burden versus building a LiteLLM or Portkey routing layer with custom evaluation and governance per provider.
Platform team capacity. Building custom requires a dedicated team maintaining orchestration, governance, observability, and CI/CD. For a 300-developer organisation, a platform orchestrator costs approximately $2 million in year one with 14 FTEs. Foundry provides these as a managed service.
Cloud lock-in tolerance. Adopting Foundry means committing to Azure as the runtime environment. Building custom means cloud flexibility but more integration work. Neither answer is wrong. The question is which cost you prefer to pay.
After weighing all five dimensions, one pattern emerges — consistent with the reliability-first thesis shaping enterprise AI infrastructure decisions: the platform that best operationalises governance, observability, identity, and CI/CD wins, regardless of model benchmarks.
Is vendor lock-in a risk with Microsoft Foundry, given it runs on Azure?
Yes, and it is worth understanding what kind of lock-in and where it bites.
Foundry’s agent runtime is Azure-coupled. The deployment pipeline, identity integration, and observability are Azure-native. Migrating agents off Foundry would require re-platforming to a different runtime and re-integrating identity, networking, and monitoring. But all three hyperscaler platforms share this structural gap. Bedrock is AWS-coupled. Vertex AI is GCP-coupled. Foundry is not unique here, and Gemini Enterprise carries deeper lock-in due to its model dependency.
Where Foundry mitigates the risk: hosted agents support multiple orchestration frameworks (Agent Framework, LangGraph, CrewAI, Anthropic Agent SDK, OpenAI Agents SDK) and use standard container packaging. Your agent code remains portable even if the runtime is not. The model router provides access to 11,000-plus models across 12-plus providers with no single-model dependency. And Agent 365 extends governance to AWS and GCP agents, so you can keep Bedrock-hosted agents on AWS while centralising governance through Foundry.
For enterprises already within the Microsoft 365 ecosystem, the integration is seamless and procurement is consolidated. For enterprises with multi-cloud mandates, the lock-in question is a trade-off between runtime flexibility and integration burden. Building cloud-agnostic with LangGraph or CrewAI avoids Azure dependency but requires engineering identity, networking, observability, and governance for each cloud you target.
If the lock-in question pushes you toward considering a custom build, the next question is whether you can achieve multi-model optionality without Foundry, and at what real cost.
Can enterprises use multiple model providers without Microsoft Foundry — and at what cost?
Yes. But the integration cost is real, and it compounds.
You can assemble a multi-model architecture using LiteLLM (open-source) or Portkey (commercial) as the routing layer, LangGraph or CrewAI for orchestration, LangSmith or Langfuse for observability, and NeMo Guardrails or LlamaGuard for content safety. Each component requires separate deployment, monitoring, and maintenance. The integration challenge is acute because agents need real-time access to current data, not historical snapshots, and every API evolution across every provider means maintenance work.
What Foundry provides that DIY does not is unified governance across all model providers. The same ACS content safety, ASSERT runtime enforcement, and Entra identity apply regardless of which model handles the request. Audit trails span every provider. Cost management is centralised. In a DIY build, each of these must be engineered and maintained separately, and teams spend months building on frameworks before confronting the production gap.
DIY multi-model makes sense if you already have a mature platform engineering team, existing observability infrastructure, and strong opinions about cloud independence. The Claude Agent SDK paired with Temporal is identified as the strongest build-your-own reference architecture for teams that meet all five build conditions. For organisations without that foundation, Foundry’s managed integration is typically faster and cheaper over a three-year horizon.
The article opened by telling you there is no universal best platform. If the argument has done its job, you now see the real question was never “which platform?” but “do I have the platform engineering capacity to build and maintain the governance, observability, and identity infrastructure that Foundry bakes in?”
The build path is not wrong. It is right for organisations with mature platform engineering teams, existing observability infrastructure, and the capacity to maintain governance integration across a growing agent fleet. The real trap is building without accounting for what Foundry provides as a managed service, and discovering the gap six to twelve months into production.
Enterprise AI battles are won on governance, observability, and operational rigour — the broader question of how enterprises should approach AI agent infrastructure. That thesis, applied systematically, leads to the evaluation framework you now have. Every decision is conditional: if your constraints are X, then Y. The article has given you the dimensions on which the answer depends, rather than a single platform recommendation.
Frequently Asked Questions
How do I get started with Microsoft Foundry if my organisation is already heavily invested in AWS?
You do not need to migrate everything at once. Foundry’s Agent 365 governance plane is designed to overlay existing infrastructure, so you can begin by extending Entra identity and Purview compliance to a pilot set of AWS-hosted agents without relocating your core workloads. The practical starting point is a single agent fleet where governance gaps hurt most (typically customer-facing automation or regulated data processing), then expanding scope as the integration proves its value.
Is Microsoft Foundry only suitable for large enterprises, or can mid-market organisations benefit?
Mid-market organisations can benefit from Foundry, but the value proposition shifts. Large enterprises justify Foundry through governance scale (hundreds of agents, dozens of teams, multi-jurisdiction compliance). Mid-market buyers typically justify it through reduced platform engineering headcount: if your team cannot afford three dedicated platform engineers to maintain orchestration, governance, and observability layers, Foundry’s managed service replaces that full-time equivalent cost with a subscription. The threshold is operational complexity, not revenue.
What types of agent workloads gain most from Foundry versus a custom build?
Workloads with high governance exposure (customer-facing automation, regulated data processing, multi-jurisdiction compliance) gain most from Foundry’s integrated safety enforcement and audit trails. Prototype-stage agents, experimental research workflows, and internal tools with narrow blast radius are reasonable candidates for custom builds using LiteLLM and LangGraph. The dividing line is not technical complexity but the cost of getting governance wrong. If a model jailbreak or unauthorised data access would trigger a regulatory filing, Foundry’s runtime enforcement justifies the platform commitment.
Can I use exclusively open-source models on Microsoft Foundry, or am I pushed toward Microsoft’s MAI family?
You can use exclusively third-party and open-source models on Foundry. The model catalogue includes Anthropic, DeepSeek, Meta (Llama), Mistral, xAI, and others alongside Microsoft’s MAI family, and the model router treats them as first-class providers. There is no architectural preference for MAI models in the routing or governance layers. The commercial incentive toward MAI is pricing and Azure-native optimisation, not platform restrictions, and enterprises running fully on Claude or Llama on Foundry face no functional penalty.
How long does a realistic evaluation-to-production timeline look on Foundry versus a custom build?
A typical Foundry pilot reaches production in 8 to 12 weeks, assuming the enterprise already operates on Azure with Entra ID in place. A custom build with equivalent governance, observability, and identity infrastructure typically takes 6 to 12 months before reaching production readiness, though a stripped-down prototype can ship faster (at the cost of the governance gaps the article documents). The timeline difference is driven less by agent logic development and more by the infrastructure assembly custom builds require.
What if I want Foundry’s governance layer but need to keep my agent runtime on AWS?
Agent 365 provides exactly this capability. It extends Microsoft’s governance plane (Entra identity, Purview compliance, Defender security) to agents running on AWS and GCP, so you can keep your Bedrock-hosted agents on AWS while centralising governance through Foundry. The trade-off is that runtime-level enforcement (ACS, ASSERT, Toolboxes) applies only to agents running within the Foundry Agent Service on Azure. AWS-hosted agents get identity and compliance governance but not Azure-native runtime safety enforcement without additional integration work.
Does Foundry’s agent service support streaming and real-time agent interactions?
Yes. Foundry’s Agent Service supports streaming responses through its hosted agents tier, and the Responses API handles real-time interaction patterns including tool-use streaming and multi-turn conversations. The architecture is designed for the latency profile enterprises expect from chat and copilot interfaces. For custom builds, equivalent streaming support requires engineering effort across the orchestration framework, model router, and observability layers, which Foundry bundles into a single managed interface.
What developer skills does my team need to be effective on Foundry versus a custom LangGraph build?
A Foundry team primarily needs agent design skills (prompt engineering, tool definition, evaluation design) and familiarity with the Azure ecosystem. A custom LangGraph build requires those same agent design skills plus Python infrastructure engineering (graph state management, checkpointing, streaming, deployment pipelines) and operational SRE capabilities for maintaining the orchestration layer in production. Foundry abstracts the infrastructure role; custom builds demand a platform engineering function alongside the agent development team, effectively doubling the skills requirement.
How does data residency work when routing requests across multiple model providers on Foundry?
Foundry lets you constrain which model providers process your data through regional deployment controls, so you can route European workloads exclusively to models hosted in Azure EU data centres while directing other regions to different providers. Each model provider in the marketplace operates under Microsoft’s data processing terms when accessed through Foundry, which simplifies the DPA management burden compared to negotiating separate agreements with each provider in a DIY multi-model setup. However, some providers may not be available in all Azure regions, limiting residency options.
What happens if Microsoft deprecates a Foundry feature or API version my agents depend on?
Microsoft provides standard Azure deprecation timelines (typically 12 months for GA services and 90 days for preview features) with migration tooling and documentation for version transitions. The more practical risk mitigation is architectural: because Foundry’s hosted agents support multiple orchestration frameworks (Agent Framework, LangGraph, CrewAI, Anthropic Agent SDK, OpenAI Agents SDK) and use standard container packaging, your agent code remains fundamentally portable. The runtime is Foundry-coupled, but the agent logic and framework choice are not.
Can I start with a custom build and migrate to Foundry later without rebuilding everything?
Yes, but with friction. If your custom build uses one of the orchestration frameworks Foundry’s hosted agents support (Agent Framework, LangGraph, CrewAI, Anthropic Agent SDK, or OpenAI Agents SDK), the agent logic migrates largely intact within container packages. The migration cost concentrates in three areas: re-integrating identity from your custom solution to Entra ID, migrating observability instrumentation to Foundry’s tracing, and adapting tool definitions where they depend on cloud-native services that differ between your custom runtime and Azure. Plan for a 4 to 8 week migration window for a moderate fleet.
