Amazon, Microsoft, and Google are converging on the same enterprise agent architecture

Kernpunkte

1. Kerngedanke: drei Hyperscaler, eine Architektur. In 9 Monaten sind Amazon, Microsoft und Google für Enterprise-Agenten auf dieselben sechs Primitiven konvergiert — Runtime, Memory, Tool-Gateway, Identität, Observability, Governance — unter unterschiedlichen Marken. Was vor 18 Monaten noch eine fragmentierte Sammlung von Bibliotheken war, wird zu einer eigenständigen Plattformschicht.
2. Die Lücke: kein Vertrag, also keine Portabilität. Die Konvergenz der Komponenten erzeugt keine Portabilität. Was fehlt, ist der Vertrag (im PaaS-Sinne), der einen Agenten agnostisch gegenüber seinem Ausführungsort machen würde. Heute landen Sitzungszustand, Traces und Identität allesamt bei einem einzigen Anbieter; den Agenten ein Jahr später zu verschieben bedeutet, alles neu aufzubauen.
3. Die leitende Analogie: PaaS 2011–2016. Vor Cloud Foundry / Heroku stellten Teams VMs, Load Balancer, Warteschlangen, Secret Stores und Monitoring-Agenten zusammen, jeweils mit eigener API. PaaS vereinheitlichte all das um einen Anwendungsvertrag: „Die App deklariert, was sie benötigt, und bleibt agnostisch gegenüber dem Ort ihrer Ausführung.“ Entscheidend war der Vertrag, nicht die Implementierung.
4. Die Lehre aus Cloud Foundry: Der Vertrag überlebt die Plattform. Cloud Foundry hat den Markt nicht gewonnen (das tat Kubernetes), aber seine Prinzipien reisten weiter: Buildpacks, entstanden bei Heroku (2011) → Cloud Native Buildpacks (Pivotal+Heroku, Jan. 2018, im Oktober in die CNCF aufgenommen); die Cloud-Foundry-Abstraktion auf K8s neu aufgebaut über Korifi. Unternehmen, die 2016 auf diesem Fundament standen, hatten eine Portabilität, die sich die meisten Agenten-Teams heute nicht leisten können.
5. Die drei Plattformen, ohne Marketing. (1) AgentCore (GA Okt. 2025): 7 zusammensetzbare Dienste (Runtime, Gateway, Memory, Browser, Code Interpreter, Identität, Observability); Runtime = isolierte, 8-stündige Ausführungsfenster; Gateway bindet bestehende MCP-Server ein; Observability wird über OpenTelemetry nach CloudWatch exportiert. (2) Microsoft Foundry (am 1. Januar 2026 umbenannt von Azure AI Foundry): verwaltete, pro Sitzung isolierte Runtime, Entra Agent ID als Identität, Sitzungs-/Nutzer-/Prozedur-Memory, OpenTelemetry-Tracing. (3) Gemini Enterprise Agent Platform (der Name Vertex AI wurde auf der Cloud Next 2026 fallengelassen): Agent Engine → Deployments, dazu Memory Bank, Sessions, Agent Registry, Policies, Gateways.
6. Konvergenz ist keine Verschwörung, sondern die Marge. Infrastrukturunternehmen bauen vertikal integrierte Plattformen, weil „die Integration dort liegt, wo die Marge ist“. Die Konsequenz fällt auf den Kunden zurück: Identität, Telemetrie und Deployment landen bei einem einzigen Anbieter → die operative Schicht unterhalb des Agenten ist das, was sich der Migration widersetzt.
7. Die Vertragsabbildung (Tabelle, wiederverwendbar für Due Diligence). 8 Zeilen „PaaS-Abstraktion → Agenten-Äquivalent → wo die Portabilität bricht“: App-Quelle → Code+Anweisungen+Eval-Suite (jedes Framework hat sein eigenes Paketformat); Buildpack → Framework-Erkennung+Packaging (kein gemeinsamer Build-Vertrag über SDKs hinweg); Backing Service → Modell/Memory/Retrieval/Tool (Anbieter fest in die Logik verdrahtet); Service Binding → authentifizierte Anbindung (Anmeldedaten vom Host-Cloud-Anbieter ausgestellt); Router → MCP/A2A-Endpunkt (die Protokolle existieren, der Lebenszyklus nicht); Logs → Traces/Tool-Aufrufe/Kosten/Qualität (GenAI-Konventionen noch in Entwicklung); Release-Promotion → evaluieren/versionieren/schrittweise deployen (Eval an ein Anbieter-Harness gekoppelt); Policy → Identität/Berechtigungen/Genehmigungen (Identität an das Verzeichnis des Anbieters gebunden).
8. Drei Gestaltungsprinzipien. (1) Den Agenten als eine einzige deploybare Einheit verpacken: Code, Anweisungen, Tool-Abhängigkeiten, Memory-Vertrag, Berechtigungen und Eval-Suite reisen gemeinsam oder gar nicht. AWS kommt dem mit seinem harness export nahe (ein Befehl → Strands-Code, der Modell, Prompt, Tools, Memory und Container bewahrt), „der richtige Instinkt, gerichtet auf eine einzelne Cloud“. (2) Anhängen statt Einbetten (die Lehre aus Twelve-Factor): Modelle, Memory, Retrieval, Browser, Gateways = über Konfiguration angehängte Ressourcen. „Ein Agent, der seinen Modellanbieter in seiner Anwendungslogik benennt, hat die Portabilität bereits aufgegeben.“ (3) Die operative Schicht in die Abstraktion integrieren: Die richtigen Fragen an einen Agenten sind, ob er die Aufgabe erfüllt hat, ob er die richtigen Tools gewählt hat, ob er seine Befugnis überschritten hat, zu welchen Kosten, und ob sich die Qualität nach einem Modell-Update verschlechtert hat.
9. Ein Agent ist keine Web-App mit aufgepfropftem Modell. Drei Unterschiede tragen das gesamte Gewicht: probabilistisches Verhalten (gleiche Eingaben → unterschiedliche Tool-Aufrufe); vom Nutzer delegierte Befugnis (ein Berechtigungsfehler wird zu einem echten Seiteneffekt, nicht zu einer Fehlerseite); Abhängigkeiten verändern das Verhalten ohne Code-Deployment (ein Modell-Update oder eine überarbeitete Tool-Beschreibung ändert, was der Agent entscheidet). Die Twelve-Factor-Regel des „zustandslosen Prozesses“ überlebt hier nicht: Sie erfordert entsorgbare Worker plus dauerhaften, inspizierbaren, portablen Zustand. LangGraph demonstriert dies im Open Source (Checkpointing bei jedem Schritt, menschliche Unterbrechungen, Wiederherstellung nach Abstürzen) — doch seine Control Plane sitzt im kommerziellen Produkt LangSmith: Die Fragmentierung zeigt sich innerhalb eines einzigen Projekts.
10. Was offene Protokolle außen vor lassen: der Lebenszyklus. MCP (Zugriff auf Tools/Daten), A2A (Entdeckung/Kommunikation zwischen Agenten), OpenTelemetry (GenAI-Konventionen, die meisten Attribute noch „in Entwicklung“), OCI-Images (ein Notausgang fürs Packaging): fast alle Primitiven existieren. Aber eine Foundation, die regelt, wie Agenten mit Tools sprechen, sagt nichts darüber aus, wie man einen Agenten versioniert, ihn über Umgebungen hinweg befördert oder zurückrollt, wenn ein Eval regrediert. Protokolle ≠ Lebenszyklus-Plattform.
11. Das Zugeständnis-Signal der Anbieter. Die Linux Foundation kündigte die Agentic AI Foundation an (Dezember 2025); Gründungsprojekte: MCP (Anthropic), goose (Block), AGENTS.md (OpenAI); AWS, Google und Microsoft als Platin-Mitglieder; Google brachte A2A in die Linux Foundation ein. Die Hyperscaler räumen ein, dass eine neutrale Schicht wichtig ist.
12. Drei Due-Diligence-Fragen (im Hinterkopf zu behalten bei der Wahl einer Agentenplattform). (1) Governance: Wird das Projekt von einer neutralen Foundation kontrolliert oder vom Anbieter, der die verwaltete Version verkauft? (2) Packaging: Läuft dasselbe Artefakt auf zwei Clouds ohne Neuschreiben? (3) Zustand: Liegt das Memory an einem für das Unternehmen exportierbaren Ort? Kein offenes Projekt beantwortet heute alle drei.
13. Der letzte Einsatz: Wer die Control Plane besitzt, besitzt die Definition. So wie Kubernetes Pods/Deployments/Services definierte und das Denken einer ganzen Branche prägte, ist das Agenten-Äquivalent noch nicht entschieden. Wer am Ende die Agenten-Control-Plane besitzt, besitzt nicht nur das Deployment: Er wird definieren, was ein Agent ist, welche Komponenten er enthält, was ein Plattform-Team ersetzen darf. Ein neutrales Projekt würde Unternehmen die Verhandlungsmacht zurückgeben, die Buildpacks und Service Broker ihnen einst gaben — zum Nutzen der Anbieter ebenso wie der Käufer.
14. Verwandt. „The Development Environment Is The Next Layer To Collapse“ (Greyling) und „Building for trillions of agents“ (Levie) zu Agentenschichten; Agenten-Identität (Uber-Engineering-Eintrag, Zero-Trust/SPIRE) — dasselbe Problem der delegierten Identität, von der Infrastrukturseite behandelt; die Familie Souveränität / Reversibilität / Design to Exit (ZML/LLMD-Eintrag) — dieselbe Logik, „im Voraus für die Schicht zu bezahlen, die den Anbieter ersetzbar macht“, übertragen von Silizium auf die Agenten-Control-Plane.