# janakiram-agent-platform-portability-contract-2026-07-20

## Veille

Analyse von Janakiram MSV (The New Stack, 20. Juli 2026) über die **architektonische Konvergenz** der Enterprise-Agentenplattformen der drei Hyperscaler: Innerhalb von neun Monaten haben sich **Amazon Bedrock AgentCore**, **Microsoft Foundry** und die **Gemini Enterprise Agent Platform** auf **dieselben sechs Primitiven** geeinigt — Runtime, Memory, Tool-Gateway, Identität, Observability, Governance — unter unterschiedlichen Markennamen. Was vor 18 Monaten noch eine fragmentierte Sammlung von Bibliotheken war, wird zu einer eigenständigen **Plattformschicht**. Die These: Diese Konvergenz wiederholt die **PaaS-Wende von 2011–2016**, als **Cloud Foundry** und **Heroku** VMs, Load Balancer, Warteschlangen und Secret Stores um einen portablen **Anwendungsvertrag** herum vereinheitlichten — nur dass hier **noch kein gleichwertiger Vertrag existiert** und **kein Open-Source-Projekt ihn für sich beansprucht hat**. Konsequenz: Ein Unternehmen kann **einen Agenten nicht von einer Cloud in eine andere verschieben** (Sitzungszustand, Traces und Identität landen allesamt bei einem einzigen Anbieter; eine Migration bedeutet, alles neu aufzubauen). Der Autor schlägt eine **zeilenweise Abbildung** des Cloud-Foundry-Vertrags auf Agenten vor, formuliert drei Gestaltungsprinzipien (den Agenten als **eine einzige deploybare Einheit** verpacken, Fähigkeiten **anhängen** statt Anbieter einzubetten, die **operative** Schicht in die Abstraktion integrieren), zeigt auf, was offene Protokolle (MCP, A2A, OpenTelemetry) außen vor lassen — den **Lebenszyklus** — und liefert drei Due-Diligence-Fragen: **Governance** (neutrale Foundation vs. Anbieter), **Packaging** (dasselbe Artefakt auf zwei Clouds ohne Neuschreiben), **Zustand** (exportierbares Memory). Fazit: Wer am Ende die **Agenten-Control-Plane** besitzt, wird definieren, *was ein Agent ist*.

## Titre Article

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

## Date

2026-07-20

## URL

https://thenewstack.io/agent-platform-portability-contract/

## Keywords

Enterprise-Agentenplattformen, architektonische Konvergenz, Portabilität, Lock-in, Reversibilität, Anwendungsvertrag, Amazon Bedrock AgentCore, Microsoft Foundry, Azure AI Foundry, Foundry Agent Service, Entra Agent ID, Gemini Enterprise Agent Platform, Vertex AI, Agent Engine, Memory Bank, Agent Registry, Agent Substrate, Runtime, Memory, Tool-Gateway, Identität, Observability, Governance, Agenten-Control-Plane, PaaS, Cloud Foundry, Heroku, Buildpacks, Cloud Native Buildpacks, Service Broker, Service Binding, Korifi, Kubernetes, Twelve-Factor App, angehängte Ressource, MCP, Model Context Protocol, A2A, OpenTelemetry, GenAI-Konventionen, OCI-Images, LangGraph, LangSmith, Checkpointing, Agentic AI Foundation, Linux Foundation, goose, AGENTS.md, Strands, harness export, Due Diligence, neutrale Governance, Packaging, exportierbarer Zustand, Hyperscaler, Verhandlungsmacht, Janakiram MSV

## Authors

Janakiram MSV

## Ton

**Profil**: Architekten-/Analystenbeitrag (Infrastruktur-Vordenkertum) von Janakiram MSV — Praktiker, Analyst und Berater für Silicon-Valley-Startups — für The New Stack, adressiert an Plattform-Teams und Infrastruktur-Entscheider. Analytisches, strukturiertes Register (eine These, eine durchgehaltene historische Analogie, eine Abbildungstabelle, drei Prinzipien, drei Due-Diligence-Fragen), hohe Technizität, aber didaktisch, mittlere Länge (~1600 Wörter).

**Stil**: Baut die gesamte Argumentation auf einer **historischen Analogie** auf — der PaaS-Entwicklung 2011–2016 als Spiegel der Agenten-Wende — und führt sie bis zum Ende durch (Buildpacks, die Cloud Foundry über CNCF/Korifi überleben; Kubernetes gewinnt den Markt, erbt aber die Prinzipien). Distanzierte Analystenhaltung: bezeichnet die Konvergenz als „eher rationales Verhalten als Verschwörung“ (die Marge liegt in der vertikalen Integration), verweigert sich dem Anbieter-Cheerleading („was auch immer die Plattform-Broschüre behauptet“). Setzt **wiederverwendbare Entscheidungswerkzeuge** ein: eine dreispaltige Tabelle (PaaS-Abstraktion → Agenten-Äquivalent → wo die Portabilität heute bricht), drei benannte Gestaltungsprinzipien, drei „in einfachen Worten“ formulierte Due-Diligence-Fragen. Präzise, datierte Faktenbelege (GA-Daten, Umbenennungen, Linux-Foundation-Mitgliedschaften). Verweist auf den eigenen früheren Beitrag des Autors zu Googles Agent Substrate. Ein bewusst zukunftsgerichteter Schlusssatz („Wer am Ende die Agenten-Control-Plane besitzt … definiert, was ein Agent ist“). Redaktioneller Transparenzhinweis von TNS: Anteilseigner Insight Partners investiert in OpenAI, Anthropic, Real.

## Pense-betes

- **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**.
- **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**.
- **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.**
- **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**.
- **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.
- **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**.
- **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).
- **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.
- **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**.
- **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.**
- **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.
- **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.**
- **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.
- **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.

## RésuméDe400mots

Innerhalb von neun Monaten haben Amazon, Microsoft und Google jeweils eine Enterprise-Agentenplattform gestartet oder umbenannt, und **alle drei sind auf dieselbe Architektur konvergiert**: Runtime, Memory, Tool-Gateway, Identität, Observability und Governance finden sich nun in **Bedrock AgentCore**, **Microsoft Foundry** und der **Gemini Enterprise Agent Platform**, unter unterschiedlichen Namen. Was vor 18 Monaten noch eine fragmentierte Sammlung von Bibliotheken war, wird zu einer eigenständigen **Plattformschicht**.

Um zu verstehen, wohin das führt, greift Janakiram MSV auf die **PaaS-Wende von 2011–2016** zurück. Zuvor stellten Teams VMs, Load Balancer, Warteschlangen, Secret Stores und Monitoring-Agenten zusammen, jeweils mit eigener API. **Cloud Foundry** und **Heroku** vereinheitlichten diese Bausteine um einen **Anwendungsvertrag**: Die Anwendung deklariert, was sie benötigt, und bleibt agnostisch gegenüber dem Ort ihrer Ausführung. Entscheidend war der **Vertrag, nicht die Implementierung**. Cloud Foundry hat den Markt nicht gewonnen — das tat Kubernetes —, aber seine Prinzipien überlebten (Buildpacks → Cloud Native Buildpacks/CNCF; die Cloud-Foundry-Abstraktion auf K8s neu aufgebaut über Korifi). Das Agenten-Ökosystem nähert sich derselben Wende **ohne einen gleichwertigen Vertrag**, und kein Open-Source-Projekt hat ihn für sich beansprucht.

Die Kosten sind konkret: Sitzungszustand, Traces und Identität **landen allesamt bei einem einzigen Anbieter**; einen Agenten ein Jahr später zu verschieben erfordert, **alles neu aufzubauen**. Die Konvergenz ist keine Verschwörung, sondern rationales Verhalten — vertikale Integration, „dort liegt die Marge“ —, dessen Konsequenz auf den Kunden fällt.

Der Autor schlägt eine **Abbildung** des Cloud-Foundry-Vertrags auf Agenten vor (App-Quelle → Code+Eval; Buildpack → Packaging; Backing Service → Modell/Memory; Binding → authentifizierte Anbindung; Router → MCP/A2A; Logs → Traces/Kosten/Qualität; Promotion → Eval/Versionierung; Policy → Identität), gefolgt von drei Prinzipien: den Agenten als **eine einzige deploybare Einheit verpacken** (AWS kommt dem mit seinem *harness export* zu Strands-Code nahe, „der richtige Instinkt, gerichtet auf eine einzelne Cloud“), **Fähigkeiten anhängen statt Anbieter einzubetten** (die Lehre aus Twelve-Factor), **die operative Schicht in die Abstraktion integrieren**. Ein Agent ist keine Web-App: probabilistisches Verhalten, delegierte Befugnis, Abhängigkeiten, die das Verhalten ändern, ohne dass ein Deployment stattfindet. LangGraph demonstriert dies im Open Source, doch seine Control Plane sitzt in LangSmith (einem kommerziellen Produkt).

Offene Protokolle (MCP, A2A, OpenTelemetry, OCI) liefern nahezu alle Primitiven, aber **nicht den Lebenszyklus**: Versionierung, Promotion, Rollback. Die **Linux Foundation** hat die **Agentic AI Foundation** ins Leben gerufen (Dez. 2025, Gründungsprojekte MCP/goose/AGENTS.md, Hyperscaler als Platin-Mitglieder). Drei Due-Diligence-Fragen bleiben — **Governance, Packaging, Zustand** —, die kein offenes Projekt beantwortet. Wer am Ende die **Agenten-Control-Plane** besitzt, wird definieren, *was ein Agent ist*.

## GrapheDeConnaissance

- Amazon Bedrock AgentCore —converge_avec→ Microsoft Foundry (TECHNOLOGIE, 0.95)
- Microsoft Foundry —converge_avec→ Gemini Enterprise Agent Platform (TECHNOLOGIE, 0.95)
- Janakiram MSV —affirme_que→ les trois hyperscalers ont convergé sur les mêmes six primitives d'agent (runtime, mémoire, tool gateway, identité, observabilité, gouvernance) (AFFIRMATION, 0.95)
- Janakiram MSV —affirme_que→ l'écosystème agent manque du contrat de portabilité qu'aucun projet open source n'a revendiqué (AFFIRMATION, 0.92)
- Cloud Foundry —permet→ portabilité applicative via un contrat agnostique du lieu d'exécution (AFFIRMATION, 0.9)
- plateforme d'agents d'entreprise —s_inspire_de→ PaaS (Cloud Foundry, Heroku) (TECHNOLOGIE, 0.88)
- contrat de portabilité agent —réduit→ lock-in vis-à-vis d'un hyperscaler (CONCEPT, 0.85)
- Amazon Bedrock AgentCore —utilise→ Model Context Protocol (TECHNOLOGIE, 0.9)
- Amazon Bedrock AgentCore —utilise→ OpenTelemetry (TECHNOLOGIE, 0.9)
- Microsoft Foundry —utilise→ Entra Agent ID (TECHNOLOGIE, 0.9)
- Microsoft Foundry —est_variante_de→ Azure AI Foundry (TECHNOLOGIE, 0.9)
- Gemini Enterprise Agent Platform —remplace→ Vertex AI (TECHNOLOGIE, 0.88)
- LangGraph —permet→ état d'agent durable, inspectable et portable (checkpointing, reprise après crash) (AFFIRMATION, 0.9)
- LangGraph —fait_partie_de→ LangSmith (TECHNOLOGIE, 0.82)
- Model Context Protocol —fait_partie_de→ Agentic AI Foundation (TECHNOLOGIE, 0.9)
- Linux Foundation —publie→ Agentic AI Foundation (TECHNOLOGIE, 0.92)
- protocoles ouverts (MCP, A2A, OpenTelemetry) —s_oppose_à→ plateforme de cycle de vie agent (CONCEPT, 0.8)
- harness export AWS —permet→ conversion d'un harness configuré en code Strands (modèle, prompt, outils, mémoire préservés) (AFFIRMATION, 0.88)
- Twelve-Factor App —recommande→ traiter les capacités (modèle, mémoire, outils) comme des ressources attachées par configuration (AFFIRMATION, 0.85)
- Janakiram MSV —recommande→ évaluer une plateforme agent sur trois questions : gouvernance neutre, packaging portable, état exportable (AFFIRMATION, 0.9)
- Janakiram MSV —prédit→ celui qui possèdera le control plane agent définira ce qu'est un agent (AFFIRMATION, 0.85)
- Kubernetes —a_créé→ abstractions (pods, deployments, services) façonnant la pensée de l'industrie (AFFIRMATION, 0.85)

---
Canonical: https://www.thekb.eu/de/fiches/janakiram-agent-platform-portability-contract-2026-07-20/