Amazon, Microsoft und Google nähern sich derselben Agenten-Architektur an

Drei große Cloud-Anbieter, eine Richtung

Die eigentliche Nachricht ist nicht, dass AWS, Microsoft und Google jetzt auch „etwas mit Agenten“ anbieten. Die größere Verschiebung ist, wie sie diese Systeme bauen. Alle drei rücken Agenten weg vom reinen Modellzugang und hin zu einer Betriebsplattform: mit Laufzeit, Identität, Governance, Tool-Anbindung und Überwachung.

Google beschreibt seine Gemini Enterprise Agent Platform explizit als zentrale Plattform, um Agenten zu bauen, zu skalieren, zu steuern und zu optimieren. Microsoft stellt mit seinem Agenten-Stack ebenfalls nicht nur Modelle, sondern eine Verwaltungs- und Kontrollschicht in den Vordergrund. AWS positioniert Bedrock AgentCore als Baustein für sicheren Betrieb, Sessions, Identitätsweitergabe und Observability. Genau darin liegt die Konvergenz: Nicht das Chatfenster wird vereinheitlicht, sondern die Betriebsschicht dahinter.

Für Unternehmen ist das strategisch wichtiger als ein einzelner Modellvergleich. Wer heute Agenten produktiv einführt, baut nicht nur Prompts. Er baut Rechteketten, Freigaben, Connectoren, Protokolle, Logs und Eskalationspfade. Darum passt zu diesem Thema auch die Vertiefung Warum KI-Agenten nicht am Modell scheitern, sondern am Kontext: Der Engpass verschiebt sich vom Modell zur umgebenden Architektur.

Woran sich die Plattformen angleichen

Am einfachsten lässt sich die Annäherung lesen, wenn man die üblichen Marketingnamen ignoriert und stattdessen nach denselben Architekturfragen sucht.

Erstens: Runtime. Agenten brauchen eine Laufzeitumgebung, in der Aufgaben gestartet, Zustände gehalten, Aufrufe koordiniert und Aktionen abgesichert werden. AWS dokumentiert das besonders greifbar über Sessions, Laufzeitverhalten und Identitätsweitergabe in AgentCore. Google spricht von einer einheitlichen Plattform zum Bauen und Skalieren produktionsreifer Agenten. Microsoft ordnet Agenten ebenfalls als steuerbare Systeme mit Ausführungskontext und Plattformanbindung ein.

Zweitens: Identity. Ein Enterprise-Agent darf nicht einfach „irgendetwas“ tun. Er handelt mit Rechten. Deshalb wird Identität zur Kernfrage: Wer ruft den Agenten auf? Mit welchen Rollen darf er Daten lesen, Tools ausführen oder andere Systeme anstoßen? Sobald Anbieter diese Schicht prominent machen, zeigen sie, dass Agenten nicht mehr als Demo, sondern als Unternehmenssoftware gedacht werden.

Drittens: Governance und Schutz. Alle drei Anbieter betonen auf ihre Weise, dass Agenten überwacht, registriert, kontrolliert und abgesichert werden müssen. Das ist ein deutlicher Reifeindikator. Denn sobald ein Agent nicht nur antwortet, sondern Tickets anlegt, Daten abruft, Dateien bewegt oder Workflows ausführt, wird aus einer KI-Funktion eine Betriebs- und Compliance-Frage.

Viertens: Tool- und Modellvielfalt. Google hebt ein breites Modell- und Tool-Ökosystem hervor. Microsoft baut seinen Agenten-Hub klar als Schicht über Tools und Plattformdienste. AWS wiederum beschreibt eine Runtime, in der Identität, Konversation, Speicher und Werkzeuge zusammenspielen. Das ist wichtig, weil die Portabilität in der Praxis oft eher an Tools und Policies scheitert als am Modell selbst.

Aus dieser Sicht ist die Marktthese belastbar: Ja, es entsteht gerade eine ähnliche Enterprise-Agenten-Architektur. Aber nein, daraus folgt noch kein offener Standard.

Was das für Lock-in und Portabilität bedeutet

Die verlockende Fehlinterpretation wäre: Wenn alle dieselben Bausteine nennen, müssten Agenten bald leicht zwischen AWS, Microsoft und Google verschiebbar sein. So weit tragen die Quellen nicht.

Portabel sind am ehesten die oberen Schichten: Teile der Prompt-Logik, bestimmte Frameworks, manche Tool-Wrapper und in Grenzen auch die Modellabstraktion. Schwieriger wird es darunter. Denn genau dort sitzen die harten Lock-in-Faktoren:

• Identitäts- und Berechtigungsmodelle bleiben cloud-spezifisch.
• Audit- und Logpfade hängen an den jeweiligen Kontrollflächen.
• Registrierung, Freigaben und Richtlinien sind an Herstellerlogik gebunden.
• Monitoring und Betrieb folgen dem Ökosystem des Anbieters.
• Abrechnung und Ressourcennutzung sind ebenfalls nicht neutral.

Deshalb ist „Portabilität“ hier kein Ja-nein-Kriterium, sondern eine Schichtfrage. Ein Team kann seine Agentenidee, Teile seiner Orchestrierung oder einzelne Tools mitnehmen. Es kann aber trotzdem tief im Governance- und Betriebsmodell eines Anbieters festhängen. Gerade Procurement- und Architekturteams sollten sich nicht von gemeinsamer Begriffswahl täuschen lassen.

Was Unternehmen jetzt prüfen sollten

Wer jetzt mit Agenten startet, sollte deshalb nicht nach der besten Demo entscheiden, sondern nach dem saubersten Trennschnitt zwischen portablen und nicht portablen Schichten.

1. Identity zuerst, nicht zuletzt. Prüfen Sie, wie SSO, Rollen, Service-Identitäten und delegierte Rechte umgesetzt werden. Ein Agent ohne klaren Rechterahmen ist kein Produktivsystem, sondern ein Betriebsrisiko.

2. Tool-Freigaben separat denken. Die entscheidende Frage lautet nicht nur, welche Tools ein Agent nutzen kann, sondern wer diese Freigabe erteilt, protokolliert und wieder entzieht. Dazu passt auch die Vertiefung Warum KI-Agenten nicht am Modell scheitern, sondern an ihren Verbindungen.

3. Auditierbarkeit vor Komfort. Können Sie im Nachhinein erklären, welcher Agent welche Aktion mit welchem Kontext ausgelöst hat? Wenn nicht, wird jede Compliance- oder Incident-Frage teuer.

4. Modellwechsel realistisch bewerten. Viele Plattformen versprechen Offenheit oder Modellvielfalt. Relevant ist aber, wie viel Ihrer Logik wirklich modellneutral bleibt, wenn Guardrails, Evaluierung, Toolnutzung und Policy-Mechaniken einmal eingerichtet sind.

5. Exportpfade früh klären. Fragen Sie nicht erst bei Unzufriedenheit nach Export. Klären Sie von Anfang an, wie Agentendefinitionen, Logs, Tool-Konfigurationen, Policies und Monitoring-Daten außerhalb der Plattform nutzbar bleiben.

6. Kosten nicht mit Reife verwechseln. Eine bessere Agentenplattform macht Agenten oft zunächst kontrollierbarer, nicht automatisch billiger. Mehr Runtime, mehr Governance und mehr Überwachung bedeuten häufig auch mehr Plattformabhängigkeit und mehr Betriebsaufwand.

Pragmatisch heißt das: Unternehmen sollten ihre Agentenarchitektur in Schichten planen. Oben möglichst offen bleiben, unten bewusst entscheiden, wo man ein Ökosystem akzeptiert.

Wo die Annäherung endet

Die Konvergenz ist real, aber sie endet dort, wo Standardisierung in verbindliche Austauschbarkeit übergehen müsste. Dafür fehlen derzeit belastbare Hinweise.

Es gibt noch keinen klar belegten offenen Standard, der Runtime, Identity, Governance, Registry, Policies und Auditpfade über alle drei Hyperscaler hinweg wirklich vereinheitlicht. Selbst wenn offene Protokolle und Frameworks helfen, lösen sie nicht das Kernproblem der Enterprise-Schicht: Rechte, Kontrolllogik, Freigaben und Betriebsdaten bleiben eng mit dem jeweiligen Anbieter verbunden.

Das ist kein Gegenargument gegen Agentenplattformen. Im Gegenteil: Für viele Unternehmen ist diese neue Kontrollschicht genau das, was produktive Agenten erst möglich macht. Aber die richtige Schlussfolgerung lautet eben nicht „Warten, bis der Standard da ist“, sondern: Jetzt so bauen, dass spätere Wechsel an den richtigen Stellen möglich bleiben.

Genau deshalb ist die Debatte am Ende auch nicht rein technisch. Wer Freigaben erteilt, Risiken trägt und Grenzen setzt, ist eine Führungs- und Governance-Frage. Dazu passt die weiterführende Perspektive Warum verantwortliche KI am Ende kein Modell-, sondern ein Führungsproblem ist.

Unterm Strich entsteht also tatsächlich ein gemeinsames Muster für Enterprise-Agenten: Runtime plus Identity plus Governance plus Betrieb. Das ist ein starkes Marktsignal. Aber es ist noch keine frei portable Zielarchitektur, auf die man blind vertrauen sollte.

Welche Architektur sich für den Start lohnt

Wenn Sie heute starten, brauchen Sie keine perfekte Zielplattform. Sie brauchen eine Architektur, die spätere Beweglichkeit nicht unnötig verbaut.

Eine robuste Startlogik sieht meist so aus:

• Agentenlogik möglichst modular halten statt alles tief in eine einzelne Plattformkonsole zu verlagern.
• Tool-Zugriffe und Rechte getrennt dokumentieren, damit Governance nicht in impliziten Konfigurationen verschwindet.
• Monitoring, Evaluierung und Audit bewusst mitplanen, statt sie nach dem Pilot nachzurüsten.
• Modellwechsel als Testfall üben, auch wenn Sie kurzfristig bei einem Anbieter bleiben.
• Export- und Exit-Fragen schon im Pilot stellen, nicht erst nach Vertrags- oder Sicherheitsdruck.

Wer so vorgeht, muss nicht auf einen künftigen De-facto-Standard warten. Er profitiert trotzdem von der aktuellen Konvergenz: Die Hyperscaler machen Agenten endlich als Betriebsproblem sichtbar. Genau das hilft Unternehmen, die richtigen Fragen früher zu stellen.

Die sinnvollste Plattformstrategie lautet deshalb aktuell nicht Multi-Cloud um jeden Preis und auch nicht blinder Voll-Lock-in. Sinnvoll ist eine bewusst geschichtete Architektur: oben flexibel, unten kontrolliert, dazwischen sauber dokumentiert. Dann wird die neue Agentenplattform nicht zur Sackgasse, sondern zu einer kalkulierbaren Entscheidung.