Since 2025, major cloud providers have been building dedicated platforms designed to cover the entire lifecycle of AI agents: from development and deployment to governance and observability during operation. Microsoft Foundry is Microsoft’s answer to this, aiming for deep integration into the Azure and Microsoft 365 ecosystem. The Gemini Enterprise Agent Platform is Google’s counterpart, unveiled at Google Cloud Next 2026 as the successor to Vertex AI. As part of a client evaluation, we technically compared both platforms and their integration with the broader AI ecosystems of both providers. The platform selection was predetermined by the client. An initial assessment based on documentation has since been supplemented by an in-depth practical test. The findings from both phases are consolidated in this article.
Separate product worlds vs. integrated architecture
The most striking difference lies not in individual features, but in the fundamental architectural decisions made by both providers and how their respective AI ecosystems are built around the core platform.
Microsoft operates its well-known AI ecosystem, Copilot , which is primarily intended for business users, and Microsoft Foundry, which is aimed more at technical teams, as largely separate product worlds. While Copilot can access models hosted in Foundry and both systems can be integrated into Microsoft 365, Copilot agents cannot be created or monitored directly in Foundry, and vice versa. As a connecting layer, Microsoft has introduced Microsoft 365 Agents , a central control unit through which agents from both systems can be managed, assigned, and monitored together. This solves the interoperability problem but adds an additional product layer.
Google pursues a more direct integration between the Gemini Enterprise Agent Platform, designed for technical users, and the more business-oriented Gemini Enterprise App. Agents can be created in both and are visible in both. The separation of responsibilities is more clearly defined: business administrators work in the Enterprise App, where permissions and tool configurations are managed. Technical administrators work directly in the Gemini Enterprise Agent Platform for security and observability. An additional integration layer is therefore unnecessary.
Two agent concepts at Microsoft, one at Google
The Microsoft Foundry distinguishes internally between two fundamentally different agent types:
Prompt Agents can be configured within the Foundry interface and created via SDK (Software Development Kit). They are quick to build but have clear limitations: no native sub-agents, no direct skill support, and no integrated event or time triggers. Those requiring automation or autonomous agent chains must rely on external Azure services like Logic Apps, which noticeably increases overall complexity.
Hosted Agents take a different approach: the agent is developed entirely in code, packaged as a Docker image, and operated within an Azure Container Instance. Foundry provides observability, guardrails, and management functionality. This concept offers maximum flexibility but requires a development team to implement and maintain the process long-term.
The Gemini Enterprise Agent Platform does not have this dichotomy. There is one agent type that sits between these two extremes: offering more configuration freedom than Microsoft's Prompt Agent, with native support for sub-agents, skills, and triggers. Internally, the platform relies on the Antigravity Harness (Google's agent execution framework) as the central execution mechanism, which makes the unified agent concept functionally powerful despite its conceptual simplicity. The trade-off remains: those who require a fully custom container image will not find that path here.
Skills, sub-agents, and the practice of tool integration
For agents intended to perform complex tasks autonomously, three points play a central role.
Agent Skills allow reusable functional building blocks to be deployed platform-wide. The Gemini Enterprise Agent Platform features a skill registry with a search function for this purpose. In Microsoft Foundry, skill support for standard agents is currently very rudimentary. Improvements have been announced but are not yet available.
Sub-agents and agent-to-agent communication are a well-documented, directly configurable part of the standard agent model on the Gemini Enterprise Agent Platform. The situation is more complex with Microsoft Foundry: a previous UI option ("Connected Agents") has been removed. Agents can now be connected via agent-to-agent configuration, which requires significantly more authentication effort and increases complexity.
Tool integrations are extensively available on both platforms. However, users should keep in mind that integrating external services is often much more complex in practice than marketing and documentation pages suggest. Even connections to the providers' own services are sometimes no exception: reliably connecting an Outlook account to Microsoft Foundry is less trivial than one might expect. For external services and data sources, separately hosted MCP servers are often the only way. Although both platforms support this in principle, setup can quickly become time-consuming due to complex authorization processes, especially when write permissions are involved.
Observability and governance
Tracing and gateway show a clear difference in practical testing. With Microsoft, both areas work reliably and out-of-the-box. If you need control and traceability across multiple agents, you will find a stable foundation here. With Google, tracing is not consistently available across all agents. The picture is mixed for the Agent Gateway: LLM calls are reliably routed and monitored, but internal agent interactions within the same project and isolated sandbox processes bypass the gateway. Google justifies this with latency benefits, which is understandable from a performance perspective but represents a relevant gap for governance requirements.
Permissions are managed by both platforms using their own identity systems. Microsoft uses Microsoft Entra ID for this, which significantly simplifies integration into existing permission structures for companies already working within the Microsoft ecosystem. Google relies on service accounts as agent identities, which cover similar use cases in principle but are more granular and complex to configure. On both platforms, agents can inherit the permissions of their calling users, which is an important prerequisite for many enterprise scenarios. However, this process is somewhat fragmented in Microsoft Foundry and does not always work across an entire, end-to-end workflow. The Gemini Enterprise Agent Platform has the edge here.
What can be concluded from the comparison
For development teams looking to build a custom API-driven solution with a platform backend, the Google Gemini Enterprise Agent Platform has the conceptual edge due to its integrated architecture, native skill support, and stronger sub-agent model. However, this does not translate fully into practice: the platform is still young, and it shows. Several aspects still feel prototypical and are not always reliable. This will likely improve, but as it stands, it is a real limitation.
Those already deeply embedded in the Microsoft world will find plenty of options there. Tracing, the gateway, and centralized permission management work out-of-the-box, which is a tangible advantage in day-to-day operations. Nevertheless, the fragmentation between Copilot Studio, Foundry, and the management layer means additional planning effort. Furthermore, Microsoft offers fewer export options by comparison, which increases the risk of vendor lock-in. Perhaps even more relevant is the fact that the easy-to-create Prompt Agents are significantly more restricted than the agents on the Gemini platform. Hosted agents offer a good solution for both challenges, but they require significantly more custom development effort.
The more strategically relevant questions
Platform comparisons based on documentation and hands-on testing provide sound guidance, but not a definitive answer. Both platforms are evolving rapidly. Features missing today may be available in a few months. Furthermore, the platform selection in this case was predetermined by the client. There are other providers that offer comparable architectures and sometimes different strengths; their exclusion from this evaluation was a strategic decision, not a technical one.
The more strategically relevant questions are often different: Which platform fits the existing infrastructure? What dependencies arise from choosing a provider? And how high is the risk if platform features do not work as the marketing slides promise?
If you are facing a similar decision and are looking for a structured technical assessment for your specific scenario, let us discuss it together.
Frequently Asked Questions (FAQ)
When is using Microsoft Foundry particularly worthwhile?
The biggest advantage of Microsoft Foundry becomes apparent when a company is already deeply rooted in the Azure and Microsoft 365 ecosystem. In particular, the seamless integration of Entra ID for permission management and reliable out-of-the-box tracing significantly facilitate productive operations. However, teams must factor in the additional effort required to manage the different agent types.
When does the Gemini Enterprise Agent Platform offer conceptual advantages?
Google's platform scores points with an integrated architecture without a hard separation between the technical platform and the functional enterprise app. For development teams that rely heavily on native sub-agents, event triggers, and platform-wide skills, Gemini offers the more modern basic concept. In current practice, however, one must take into account that some observability functions still have gaps.
Can external tools really be connected as easily as advertised in an enterprise environment?
No, in practice, connecting external services is often much more complex. As soon as agents require write access or need to access sensitive company data, complex authentication workflows become necessary. For many external data sources, hosting your own MCP (Model Context Protocol) server is the only reliable way, which means additional development effort.
