Die großen Cloud-Anbieter bauen seit 2025 dedizierte Plattformen, die den gesamten Lebenszyklus von KI-Agenten abdecken sollen: von der Entwicklung über das Deployment bis hin zu Governance und Observability im laufenden Betrieb. Microsoft Foundry ist Microsofts Antwort darauf, strebt eine tiefe Einbettung in das Azure- und Microsoft-365-Ökosystem an. Die Gemini Enterprise Agent Platform ist Googles Pendant, auf der Google Cloud Next 2026 als Nachfolger von Vertex AI vorgestellt. Im Rahmen einer Kundenevaluation haben wir beide Plattformen sowie deren Anbindung an das weitere KI-Ökosystem der beiden Anbieter technisch miteinander verglichen. Die Plattformauswahl war dabei kundenseitig vorgegeben. Eine initiale Einschätzung auf Basis der Dokumentation wurde inzwischen durch einen vertieften Praxistest ergänzt. Die Erkenntnisse aus beiden Phasen sind in diesem Artikel zusammengeführt.
Getrennte Produktwelten vs. integrierte Architektur
Der auffälligste Unterschied liegt nicht in einzelnen Features, sondern in der grundlegenden Architekturentscheidung beider Anbieter, und darin, wie das jeweilige KI-Ökosystem um die Kernplattform herum aufgebaut ist.
Microsoft betreibt sein allgemeinbekanntes und primär für fachliche Anwender gedachte KI-Ökosystem Copilot und die sich eher an technische Teams gerichtete Microsoft Foundry als weitgehend getrennte Produktwelten. Zwar kann Copilot auf Modelle zugreifen, die in der Foundry gehostet werden, und beide Systeme lassen sich in Microsoft 365 einbinden. Copilot-Agenten können jedoch nicht direkt in der Foundry erstellt und überwacht werden, und umgekehrt. Als Bindeschicht hat Microsoft mit Microsoft 365 Agents eine zentrale Steuereinheit eingeführt, über die Agenten aus beiden Systemen gemeinsam verwaltet, zugewiesen und beobachtet werden können. Das löst das Interoperabilitätsproblem, fügt aber eine weitere Produktebene hinzu.
Google verfolgt eine direktere Integration zwischen der auf technische Nutzer ausgelegten Gemini Enterprise Agent Platform und der eher fachlich orientierten Gemini Enterprise App. Agenten können in beiden erstellt werden und sind in beiden sichtbar. Die Trennung der Verantwortlichkeiten ist klarer geregelt: Fachliche Administratoren arbeiten in der Enterprise App, wo Berechtigungen und Tool-Konfigurationen gesteuert werden. Technische Administratoren arbeiten direkt in der Gemini Enterprise Agent Platform für Security und Observability. Eine zusätzliche Integrationsschicht ist damit nicht nötig.
Zwei Agentenkonzepte bei Microsoft, eines bei Google
Die Microsoft Foundry unterscheidet intern zwischen zwei grundlegend verschiedenen Agententypen:
Prompt Agents lassen sich im Foundry interface zusammenklicken und per SDK (Software Development Kit) erstellen. Sie sind schnell gebaut, haben aber klare Einschränkungen: keine nativen Sub-Agenten, keine direkte Skill-Unterstützung, keine integrierten Event- oder Zeit-Trigger. Wer Automatisierungen oder eigenständige Agentenketten braucht, muss dafür auf externe Azure-Dienste wie Logic Apps ausweichen, was die Gesamtkomplexität spürbar erhöht.
Hosted Agents gehen in die andere Richtung: Der Agent wird vollständig im Code entwickelt, als Docker-Image paketiert und in einer Azure Container-Instanz betrieben. Die Foundry stellt Observability, Guardrails und Verwaltungsfunktionalität bereit. Das Konzept bietet maximale Flexibilität, setzt aber ein Entwicklungsteam voraus, das diesen Prozess umsetzt und dauerhaft betreibt.
Die Gemini Enterprise Agent Platform kennt diese Zweiteilung nicht. Es gibt einen Agententyp, der zwischen beiden Extremen liegt: mehr Konfigurationsfreiheit als Microsofts Prompt Agent, mit nativer Unterstützung für Sub-Agenten, Skills und Trigger. Intern setzt die Plattform dabei auf den Antigravity Harness (Googles Agent-Ausführungs-Framework) als zentralen Ausführungsmechanismus, der das vereinheitlichte Agent-Konzept trotz seiner konzeptuellen Einfachheit funktional leistungsfähig macht. Der Kompromiss bleibt: Wer auf ein vollständig eigenes Container-Image angewiesen ist, findet diesen Weg hier nicht.
Skills, Sub-Agenten und die Praxis der Tool-Anbindung
Für Agenten, die eigenständig komplexe Aufgaben erledigen sollen, spielen drei Punkte eine zentrale Rolle.
Agent Skills ermöglichen es, wiederverwendbare Funktionsbausteine plattformweit bereitzustellen. In der Gemini Enterprise Agent Platform gibt es dafür eine Skill Registry mit Suchfunktion. In der Microsoft Foundry ist die Skill-Unterstützung für Standard-Agenten zum aktuellen Stand bisher nur sehr rudimentär. Verbesserungen sind angekündigt, aber bisher nicht verfügbar.
Sub-Agenten und Agent-zu-Agent-Kommunikation sind auf der Gemini Enterprise Agent Platform ein gut dokumentierter, direkt konfigurierbarer Teil des Standard-Agentenmodells. Bei der Microsoft Foundry ist die Situation aufwendiger: Eine frühere UI-Option ("Connected Agents") wurde entfernt. Agenten lassen sich nun per Agent-zu-Agent-Konfiguration verbinden, was jedoch deutlich mehr Authentifizierungsaufwand erfordert und die Komplexität erhöht.
Tool-Anbindungen sind bei beiden Plattformen umfangreich verfügbar. Anwender sollten jedoch bedenken, dass die Anbindung externer Services in der Praxis deutlich komplexer ist, als es Marketing- und Dokumentationsseiten glauben lassen. Auch Verbindungen zu den hauseigenen Diensten der Anbieter sind mitunter keine Ausnahme: Die zuverlässige Anbindung eines Outlook-Kontos an die Microsoft Foundry ist weniger trivial als man erwarten würde. Bei externen Diensten und Datenquellen sind separat gehostete MCP-Server oft der einzige Weg. Obwohl beide Plattformen dies grundsätzlich unterstützen, kann die Einrichtung aufgrund komplexer Autorisierungsprozesse schnell aufwendig werden, insbesondere bei Zugriffen mit Schreibberechtigungen.
Observability und Governance
Tracing und Gateway zeigen im Praxistest einen klaren Unterschied. Bei Microsoft funktionieren beide Bereiche zuverlässig und out-of-the-box. Wer Kontrolle und Nachvollziehbarkeit über mehrere Agenten hinweg braucht, findet hier eine stabile Grundlage. Bei Google ist Tracing nicht durchgängig über alle Agenten verfügbar. Beim Agent Gateway ist das Bild gemischt: LLM-Aufrufe werden zuverlässig geleitet und überwacht, interne Agenten-Interaktionen innerhalb desselben Projekts sowie isolierte Sandbox-Prozesse laufen jedoch am Gateway vorbei. Google begründet das mit Latenzvorteilen, was aus Performance-Sicht nachvollziehbar ist, für Governance-Anforderungen aber eine relevante Lücke darstellt.
Berechtigungen verwalten beide Plattformen über eigene Identitätssysteme. Microsoft nutzt dafür Microsoft Entra ID, was für Unternehmen, die bereits im Microsoft-Ökosystem arbeiten, die Integration in bestehende Berechtigungsstrukturen deutlich vereinfacht. Google setzt auf Service Accounts als Agenten-Identität, die grundsätzlich ähnliche Anwendungsfälle abdecken, in der Konfiguration aber kleinteiliger und aufwendiger sind. Auf beiden Plattformen können Agenten die Berechtigungen ihrer aufrufen Nutzer erben, was für viele Enterprise-Szenarien eine wichtige Grundvoraussetzung ist. Bei der Microsoft Foundry ist dieser Prozess jedoch etwas fragmentiert und funktioniert nicht immer über einen gesamten, durchgängigen Workflow. Die Gemini Enterprise Agent Platform hat hier in diesem Punkt die Nase vorn.
Was sich aus dem Vergleich ableiten lässt
Für Entwicklungsteams, die eine API-gestützte Eigenentwicklung mit Plattform-Backend aufbauen wollen, hat die Google Gemini Enterprise Agent Platform durch die integrierte Architektur, native Skill-Unterstützung und das stärkere Sub-Agenten-Modell konzeptuell die Nase vorn. Das schlägt sich allerdings nicht uneingeschränkt in der Praxis nieder: Die Plattform ist noch jung, und das merkt man. Mehrere Aspekte wirken noch prototypisch und nicht immer zuverlässig. Das wird sich wahrscheinlich verbessern, aber zum aktuellen Stand ist es eine reale Einschränkung.
Wer bereits tief in der Microsoft-Welt ist, findet dort genug Möglichkeiten. Tracing, Gateway und zentrale Berechtigungsverwaltung funktionieren out-of-the-box, was im laufenden Betrieb einen handfesten Vorteil darstellt. Die Fragmentierung zwischen Copilot Studio, Foundry und Verwaltungsebene bedeutet dennoch Mehraufwand in der Planung. Zudem bietet Microsoft im Vergleich weniger Export-Optionen, was die Gefahr eines Vendor Lock-ins erhöht. Noch relevanter ist vermutlich, dass die einfach zu erstellenden Prompt Agents deutlich stärker eingeschränkt sind als die Agenten der Gemini-Plattform. Für beide Herausforderungen bieten Hosted Agents eine gute Lösung, erfordern allerdings erheblich mehr Eigenentwicklungsaufwand.
Die strategisch relevanteren Fragen
Plattformvergleiche auf Basis von Dokumentation und Hands-on-Tests geben eine fundierte Orientierung, aber keine endgültige Antwort. Beide Plattformen entwickeln sich schnell. Funktionen, die heute fehlen, können in wenigen Monaten verfügbar sein. Außerdem war die Plattformauswahl in diesem Fall kundenseitig vorgegeben. Es gibt weitere Anbieter, die vergleichbare Architekturen und teils andere Stärken mitbringen, deren Ausschluss aus dieser Evaluation war eine strategische Vorentscheidung, keine technische.
Die strategisch relevanteren Fragen sind oft andere: Welche Plattform passt zur bestehenden Infrastruktur? Welche Abhängigkeiten entstehen durch die Wahl eines Anbieters? Und wie hoch ist das Risiko, wenn Plattform-Features nicht so funktionieren, wie die Marketingfolien es versprechen?
Wenn Sie vor einer ähnlichen Entscheidung stehen und eine strukturierte technische Einschätzung für Ihr konkretes Szenario suchen, lassen Sie uns das gerne gemeinsam besprechen.
Häufige Fragen (FAQ)
Wann lohnt sich der Einsatz der Microsoft Foundry besonders?
Der größte Vorteil der Microsoft Foundry zeigt sich, wenn ein Unternehmen bereits tief im Azure- und Microsoft-365-Ökosystem verwurzelt ist. Besonders die nahtlose Integration von Entra ID für die Berechtigungsverwaltung sowie das zuverlässige Out-of-the-box-Tracing erleichtern den produktiven Betrieb erheblich. Teams müssen jedoch den Mehraufwand bei der Verwaltung der unterschiedlichen Agententypen einkalkulieren.
Wann bietet die Gemini Enterprise Agent Platform konzeptuelle Vorteile?
Googles Plattform punktet durch eine integrierte Architektur ohne harte Trennung zwischen der technischen Plattform und der fachlichen Enterprise App. Für Entwicklungsteams, die stark auf native Sub-Agenten, Event-Trigger und plattformweite Skills setzen, bietet Gemini das modernere Grundkonzept. In der aktuellen Praxis muss man allerdings berücksichtigen, dass einige Observability-Funktionen noch Lücken aufweisen.
Lassen sich externe Tools im Unternehmensumfeld wirklich so einfach anbinden wie beworben?
Nein, in der Praxis ist die Anbindung externer Services oft deutlich komplexer. Sobald Agenten Schreibzugriffe benötigen oder auf sensible Unternehmensdaten zugreifen sollen, werden aufwendige Authentifizierungs-Workflows notwendig. Für viele externe Datenquellen ist das Hosting eines eigenen MCP-Servers (Model Context Protocol) der einzige verlässliche Weg, was zusätzlichen Entwicklungsaufwand bedeutet.
