Google bringt über 200 Modelle, einschließlich Claude, in eine einzige Agent-Plattform. Der Single-Model-Lock-in ist vorbei.

Vor zwei Jahren bedeutete der Kauf einer „Enterprise-KI-Plattform“ die Auswahl des Modells eines einzelnen Anbieters und den Aufbau dahinter über dessen API. Die Wette, die Sie am ersten Tag eingegangen sind, war die Wette, an die Sie gebunden waren. Diese Definition ist gerade in sich zusammengefallen. Google, der weltweit drittgrößte Cloud-Anbieter, bietet nun eine Agent-Plattform mit mehr als 200 Modellen direkt aus der Box an, und das wegweisende Modell eines Mitbewerbers befindet sich direkt neben dem eigenen im Katalog. Modellunabhängigkeit ist keine Außenseiterposition mehr. Es ist das Produkt.

Dieser Wandel zeigte sich auf der Google Cloud Next 2026, die vom 22. bis 24. April im Mandalay Bay in Las Vegas stattfand. Google präsentierte dort in drei Keynotes rund 32.000 Teilnehmern 260 Produktankündigungen. Die wichtigste Nachricht für Unternehmenskäufer war kein größeres Modell. Es war ein weitaus gewichtigeres Argument für die Architektur.

Was Google tatsächlich konsolidiert hat

Google hat Vertex AI in ein einheitliches Angebot namens Gemini Enterprise Agent Platform integriert. Laut Googles eigener Ankündigung werden „alle Vertex AI-Dienste und Roadmap-Entwicklungen ausschließlich über die Agent Platform bereitgestellt und nicht mehr als eigenständiger Dienst.“ Die eigenständige Modell-API ist verschwunden. Alles läuft jetzt über eine Agent-Ebene.

Die Plattform bietet Entwicklern über den Model Garden erstklassigen Zugriff auf mehr als 200 Modelle. Diese Liste umfasst die Google-eigenen Gemini- und Gemma-Familien, offene Modelle wie Llama sowie wegweisende Modelle von Drittanbietern. Google erklärt unmissverständlich, dass Kunden „Unterstützung für Drittanbieter-Modelle wie Claudes Opus, Sonnet und Haiku von Anthropic“ erhalten. Die Claude-Familie von Anthropic läuft nativ innerhalb desselben Katalogs wie Gemini, abgerechnet und verwaltet als serverlose API, ohne dass separate Infrastrukturen bereitgestellt werden müssen.

Hier ist der Vorher-Nachher-Vergleich in einfachen Worten.

Die Elemente rund um die Modelle sind ebenso wichtig wie deren Anzahl. Es gibt einen verwalteten Remote-MCP-Server, der jetzt allgemein verfügbar ist, damit Agenten auf externe Tools und Daten zugreifen können, ohne dass dafür spezielle Anpassungen erforderlich sind. Es gibt einen Web-Browsing-Agenten, Project Mariner, der in Cloud-Sandboxes agiert. Und es gibt das Agent2Agent-Protokoll, das Google und seine Partner als produktionsbereit statt als Pilotprojekt beschreiben – mit 150 Organisationen, die reale Aufgaben zwischen Agenten auf unterschiedlichen Plattformen koordinieren. (Wir haben A2A und MCP an anderer Stelle ausführlich behandelt; der Fokus hier ist enger gefasst.)

Der entscheidende Punkt hier ist, was der Katalog über die Strategie aussagt.

Warum Claude im Google-Katalog das eigentliche Signal ist

Dass ein Cloud-Anbieter ein wegweisendes Drittanbieter-Modell in seine Flaggschiff-Agent-Plattform integriert, ist keine Randnotiz. Es ist ein Zugeständnis an die Art und Weise, wie Unternehmen tatsächlich einkaufen.

Google würde es bevorzugen, wenn Sie Gemini durchgängig nutzen. Die vertikale Integration ist das Hauptargument, angefangen von den TPUs der achten Generation bis hin zur Agent-Laufzeitumgebung. Dennoch macht derselbe Launch Claude zu einem erstklassigen Partner, da die Käufer, die Google gewinnen möchte, sich bereits entschieden haben, dass sie Optionen auf der Modellebene wünschen. Wenn das Unternehmen mit dem größten Interesse daran, ein einziges Modell zu pushen, stattdessen 200 anbietet, hat sich die These des Single-Modells als Standard erledigt.

Das deckt sich mit dem, was Unternehmen ohnehin schon getan haben. Wie wir in unserem Artikel Warum ein einziges Modell nicht zu jedem Unternehmen passt dargelegt haben, lautet die ehrliche Antwort auf die Frage „Welches Modell nutzen Sie?“ in den meisten großen Organisationen: „Alle.“ Unterschiedliche Aufgaben erfordern unterschiedliche Modelle. Ein logikintensiver Prüfungsschritt bei Versicherungen und ein hocheffizienter Klassifizierungsschritt haben keinen Grund, sich dieselbe Engine zu teilen – und auch die Kosten- und Latenzkalkulation geht dabei selten auf.

Es lohnt sich, präzise zu definieren, warum dies ein Zugeständnis und nicht nur Großzügigkeit ist. Google stellt die Nutzung von Claude auf dieselbe Weise in Rechnung wie die Nutzung von Gemini, sodass das Hosting eines Konkurrenten durchaus umsatzrelevant ist. Der tiefere Grund ist jedoch die Kundenbindung. Ein Unternehmen, das Google Cloud verlassen muss, um Claude zu nutzen, ist ein Unternehmen, das sich am Ende vielleicht ganz verabschiedet. Indem das Konkurrenzmodell auf der Plattform bleibt, bleibt auch der Kunde auf der Plattform. Das ist nur dann logisch, wenn der Kunde das Konkurrenzmodell ohnehin verlangt hätte, und genau das ist der Punkt.

Was das bedeutet, wenn Sie bereits Vertex AI nutzen

Wenn Ihr Team mit Vertex AI gearbeitet hat, sollten Sie als Erstes wissen, dass es nicht abgeschaltet, sondern integriert wird. Google formuliert es so, dass die Vertex-Dienste fortgeführt und über die Agent Platform statt als separates Produkt bereitgestellt werden. Ihre bestehenden Modellaufrufe funktionieren also weiterhin.

Was sich ändert, ist die Einheit, die Sie bereitstellen und betrachten. Was Sie jetzt implementieren, ist ein Agent mit einer Routing-Richtlinie und kein reiner Modell-Endpunkt. Für die meisten Teams ist dies eine kleinere Code-Änderung, als es klingt, aber ein weitaus größerer mentaler Wandel. Der Inferenzaufruf sieht vertraut aus. Die Annahmen drumherum – dass „das Modell“ das Projekt ist, dass man es einmal auswählt, dass die Bereitstellung ein Modell hinter einem Endpunkt ist –, das sind die Aspekte, die der Vergangenheit angehören.

Die praktische Konsequenz ist, diese Konsolidierung als Anlass zu nehmen, zwei Entscheidungen voneinander zu trennen, die Sie bisher vielleicht als eine einzige getroffen haben: Welches Modell führt einen bestimmten Schritt aus und was steuert den Agenten, der es aufruft. Google hat die erste Entscheidung gerade kostengünstig und revidierbar gemacht. Die zweite Entscheidung – Steuerung und Orchestrierung – ist der Bereich, in den sich die eigentliche Arbeit verlagert.

Die Zahlen hinter diesem Schritt

Der Marktkontext erklärt, warum Google seinen gesamten KI-Stack auf Agenten statt auf Chats ausgerichtet hat. Gartner prognostiziert, dass bis Ende 2026 40 % der Unternehmensanwendungen aufgabenspezifische KI-Agenten enthalten werden, verglichen mit weniger als 5 % im Jahr 2025. Das ist ein achtfacher Sprung in rund einem Jahr, und Plattformen werden dort aufgebaut, wohin sich die Nachfrage entwickelt, nicht dort, wo sie aktuell verweilt.

Der Wert, um den es geht, ist die andere Hälfte der Geschichte. McKinsey schätzt, dass generative KI in 63 Anwendungsfällen jährlich einen wirtschaftlichen Nutzen von 2,6 bis 4,4 Billionen US-Dollar generieren könnte. Ein Stück dieses Kuchens sichert man sich nicht dadurch, dass ein einzelnes Modell geringfügig besser wird. Es entsteht vielmehr dadurch, dass viele Modelle verlässlich und gemeinsam nützliche Arbeit in realen Geschäftsprozessen leisten. Eine Plattform, die auf Agenten statt auf ein einzelnes Modell ausgerichtet ist, setzt genau darauf – und es ist eine Wette, die der Rest des Marktes zeitgleich abschließt.

(Wenn Sie diese Art von Analysen lieber direkt in Ihrem Posteingang erhalten möchten, anstatt Keynote-Zusammenfassungen zu lesen, abonnieren Sie unseren wöchentlichen Bericht darüber, wohin sich Enterprise-KI tatsächlich entwickelt.)

Was sich dadurch für Ihren Einkauf ändert

Die Logik der Anbieterbindung hat sich umgekehrt. Vor einem Jahr galt die Standardisierung auf ein einziges Modell noch als Disziplin. Heute sieht es nach einem Risiko aus, da sich die technologische Spitze alle paar Monate verschiebt und der Anbieter, auf den Sie sich standardisiert haben, beim nächsten Benchmark vielleicht nicht mehr führt. Anthropic, OpenAI und Google wechseln sich so oft an der Spitze ab, dass eine Wette des gesamten Stacks auf einen von ihnen eine Wette gegen Ihre eigene Flexibilität ist.

Auch die Architektur-Einheit hat sich verändert. Das Element, um das herum Sie entwickeln, ist kein Modell mehr, sondern eine Orchestrierungsebene, die entscheidet, welches Modell welchen Schritt übernimmt. Googles eigene Umstrukturierung verdeutlicht dies: Die Modell-API wurde zu einer Unterkomponente einer Agent-Plattform. Wie wir es in Das Plädoyer für Multi-Modell-Orchestrierung formuliert haben, ist das Modell jetzt eine Routing-Entscheidung und keine grundlegende Verpflichtung mehr.

Eine Routing-Ebene in einem konkreten Beispiel

Nehmen wir den Schadensprozess einer Versicherung. Der Schritt, der eine unstrukturierte Notiz des Schadensregulierers liest und entscheidet, ob ein Betrugsverdacht vorliegt, ist logikintensiv und hat ein geringes Volumen. Hierfür empfiehlt sich ein hochentwickeltes logisches Modell, und die Zahlung von Premium-Preisen dafür lohnt sich. Der Schritt, der täglich fünfzigtausend eingehende Dokumente nach Typ klassifiziert, hat ein hohes Volumen und ist latenzempfindlich. Dieses auf einem High-End-Modell laufen zu lassen, wäre Geld- und Zeitverschwendung. Ein Workflow, zwei Schritte, zwei verschiedene Modelle. Das funktioniert nur, wenn eine Instanz oberhalb beider Modelle jeden Schritt dem richtigen Modell zuweist. Diese Instanz ist die Orchestrierungsebene, und sie ist der Grund, warum das Modell zu einer Routing-Entscheidung statt zu einer Plattformbindung wird.

Zudem wird Interoperabilität zur Grundvoraussetzung. A2A im Produktivbetrieb und verwaltete MCP-Server bedeuten, dass von Agenten erwartet wird, plattform- und anbieterübergreifend zu kommunizieren. Ein Agent, der nur mit anderen Agenten desselben Anbieters kommunizieren kann, wird bald so veraltet wirken wie eine Software, die das Dateiformat eines Wettbewerbers nicht lesen konnte.

Drei Kernbotschaften für die Entscheider, die die Verträge unterzeichnen:

• Standardisieren Sie nicht auf ein Modell. Standardisieren Sie auf eine Routing-Ebene. Das Modell, das Sie heute wählen, ist unwahrscheinlich das, das Sie in zwölf Monaten nutzen wollen. Eine Architektur, die Flexibilität voraussetzt, überlebt. Eine Architektur, die ein einzelnes Modell fest codiert, nicht.

• Betrachten Sie die Unterstützung von Drittanbieter-Modellen als Basisanforderung. Wenn Google Claude auf seiner eigenen Plattform anbietet, verliert „Wir unterstützen mehrere Anbieter“ den Status eines Differenzierungsmerkmals und wird zum Standard.

• Gewichten Sie Interoperabilität bei der Evaluierung stärker. Produktionsreife, anbieterübergreifende Agent-Protokolle werden mittlerweile von den größten Anbietern ausgeliefert. Planen Sie für eine Welt, in der Ihre Agenten mit Systemen kommunizieren, die Sie nicht kontrollieren.

Das ist mittlerweile Konsens, keine Außenseitermeinung mehr

Eine Zeit lang war eine modellunabhängige, orchestrierungsorientierte Architektur eine Position, die man verteidigen musste. Genau um diesen Ansatz herum haben wir Beam AIs ModelMesh entwickelt: Leiten Sie jede Aufgabe an das Modell weiter, das sie am besten bewältigt, halten Sie die Orchestrierungsebene über jedem einzelnen Anbieter und behandeln Sie Modelle als austauschbare Komponenten statt als Fundamente. Die Plattform selbst ist bewusst modellunabhängig gestaltet, wobei Claude, Gemini und andere über eine einzige Routing-Ebene verfügbar sind.

Als wir anfingen, dieses Argument zu vertreten, wirkte es noch wie eine Absicherung gegen Anbieter-Risiken. Nach der Google Cloud Next 2026 zeigt sich, dass sich der gesamte Markt in diese Richtung bewegt. Einer der größten Cloud-Anbieter hat Multi-Modell-Ansätze und plattformübergreifende Interoperabilität zum Standardverhalten seiner führenden Agent-Plattform gemacht. Die Debatte darüber, ob sich Unternehmen an ein einziges Modell binden sollten, ist weitgehend geklärt. Die spannenden Fragen drehen sich nun darum, wie Sie über viele Modelle hinweg steuern, verwalten und orchestrieren.

Das ist die weitaus bessere Herausforderung. Sie bedeutet, dass sich der Hebel von der Wahl des richtigen Modells hin zum Aufbau des richtigen Systems um alle Modelle herum verlagert hat.