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 ongoing operations. 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 conducted a technical comparison of 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.
Two agent concepts at Microsoft, one at Google
The most striking difference lies in the agent concepts:
The Microsoft Foundry distinguishes internally between two fundamentally different agent types:
Prompt Agents can be assembled in the Foundry interface and created via SDK. 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 automations or autonomous agent chains must rely on external Azure services like Logic Apps, which noticeably increases overall complexity.
Hosted Agents take the opposite approach: the agent is developed entirely in code, packaged as a Docker image, and operated in 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: 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.
Siloed product worlds vs. integrated architecture
Another structural difference is evident in how each AI ecosystem is built around the core platform.
Microsoft operates its AI ecosystem, primarily designed for business users, Copilot and the Microsoft Foundry, which is aimed more at technical teams, as separate product worlds. Foundry agents can only be integrated into Copilot Studio via agent-to-agent (A2A) connectivity. Through this connection, Copilot Studio gains access to specific Foundry resources, in particular Foundry IQ as a context and knowledge platform. Agent 365 complements the architecture with shared access management and compliance. This connection creates interoperability but does not merge the products into a unified platform.
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. 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 platform configuration. An additional integration layer is therefore unnecessary.
Skills, sub-agents, and the practice of tool integration
For agents intended to handle complex tasks independently, three points play a central role.
Agent skills allow reusable functional modules 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 with Microsoft Foundry is more involved: 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, in practice, significantly more complex 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 access is required.
Observability and governance
Tracing and Gateway show a clear difference in practical testing. With Microsoft, both areas function reliably and out-of-the-box. Those who need control and traceability across multiple agents 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 routed and monitored reliably, 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 via 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. In Microsoft Foundry, however, this process is somewhat fragmented 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 an API-supported custom solution with a platform backend, the Google Gemini Enterprise Agent Platform conceptually has the 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 enough options there. Tracing, gateway, and centralized permission management work out-of-the-box, which represents 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 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 considerably 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 preliminary 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 function as promised in the marketing slides?
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 greatest 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 operation. 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 in an enterprise environment as advertised?
No, in practice, connecting external services is often significantly more complex. As soon as agents require write access or need to access sensitive company data, elaborate authentication workflows become necessary. For many external data sources, hosting a dedicated MCP (Model Context Protocol) server is the only reliable approach, which entails additional development effort.
