Mitte 2026 sind MCP und A2A das Bindegewebe des Agenten-Ökosystems geworden — unter neutraler Governance der Linux Foundation mit 146 Mitgliedern. Damit verschiebt sich der entscheidende Hebel: Interoperabilität wird zur Voreinstellung, und die Kosten eines Anbieterwechsels brechen ein. Eine Analyse, warum das die technische Grundlage jeder ernsthaften Multi-Model-Strategie ist.
Mitte 2026: Offene Protokolle sind das Bindegewebe geworden
Stand Mitte 2026 gibt es zwei Standards, die das Agenten-Ökosystem zusammenhalten: Anthropics Model Context Protocol (MCP) und Googles Agent-to-Agent Protocol (A2A). Beide sind keine Produkte mehr, die einem einzelnen Anbieter gehören, sondern offene, herstellerübergreifende Protokolle. Verwaltet werden sie von der Agentic AI Foundation der Linux Foundation — einem neutralen Gremium mit inzwischen 146 Mitgliedsorganisationen.
Das klingt nach Infrastruktur-Bürokratie. Es ist aber die wichtigste strukturelle Veränderung im KI-Stack seit der Verfügbarkeit von Frontier-Modellen über APIs. Denn diese Protokolle erlauben es Agenten und Werkzeugen unterschiedlicher Hersteller, über gemeinsame, offene Standards zusammenzuarbeiten — statt über proprietäre Eins-zu-eins-Integrationen, die jeder Anbieter für sich definiert.
Der Punkt, der dabei oft untergeht: Wer den Lock-in im KI-Zeitalter verstehen will, muss aufhören, nur auf das Modell zu schauen. Der eigentliche Hebel lag schon immer eine Ebene tiefer — in der Art, wie Systeme miteinander reden.
Klingt interessant?
Lock-in lag nie beim Modell, sondern an der Integrationsschicht
Jahrelang wurde Anbieterbindung an der Integrationsschicht durchgesetzt, nicht am Modell selbst. Der Mechanismus war simpel: Jeder Anbieter lieferte seine eigenen Konnektoren, sein eigenes Format, seine eigene Art, Werkzeuge und Datenquellen anzubinden. Wer einen Anbieter verlassen wollte, verliess nicht nur ein Modell — er warf sämtliche Integrationsarbeit weg, die er um dieses Modell herum gebaut hatte.
Das machte den Wechsel teuer. Nicht, weil das Zielmodell schlechter war, sondern weil die gesamte Verdrahtung neu entstehen musste: Werkzeuganbindungen, Datenzugriffe, die Kommunikation zwischen Agenten. Ein Anbieterwechsel war faktisch ein Neubau. Genau diese Reibung war das Geschäftsmodell — sie hielt Kunden im System, lange nachdem die rein technischen Gründe verschwunden waren.
Offene Protokolle drehen diese Logik um. Wenn MCP definiert, wie ein Agent ein Werkzeug oder eine Datenquelle anspricht, und A2A definiert, wie Agenten untereinander kommunizieren, dann ist die Integration nicht mehr anbieterspezifisch. Sie ist standardisiert. Ein Werkzeug, das gegen MCP spricht, funktioniert mit jedem Agenten, der MCP versteht — unabhängig davon, welches Modell oder welcher Anbieter dahintersteht.
Entscheidend ist dabei die neutrale Governance. Solange ein Protokoll einem einzelnen Unternehmen gehört, ist es nur ein eleganterer Lock-in: Der Eigentümer kann es ändern, verteuern oder schliessen. Erst unter einem neutralen Dach wie der Linux Foundation — getragen von 146 Mitgliedern — wird aus einem Protokoll ein echter Standard, auf den man sich verlassen kann. Interoperabilität wird zur Voreinstellung, nicht zum Verhandlungsergebnis.
Was das für CTOs und Tech-Leads bedeutet
Drei Konsequenzen, die ich für relevant halte:
Erstens: Multi-Model wird von der Ambition zur Praxis. "Wir setzen auf mehrere Anbieter" war lange ein Vorsatz, der an der Integrationsarbeit scheiterte. Wenn aber Werkzeuge und Agenten über offene Protokolle sprechen, ist der Wechsel des Modells dahinter keine Migration mehr, sondern eine Konfiguration. Die Multi-Model-Strategie, die in Architektur-Diagrammen immer schön aussah, wird endlich betriebsfähig.
Zweitens: Die Wechselkosten brechen ein — aber nur, wenn ihr auf den Standards baut. Hier liegt der Haken. Der Vorteil offener Protokolle entsteht nicht automatisch. Er entsteht nur, wenn eure Plattform tatsächlich auf MCP und A2A aufsetzt — und nicht im Hintergrund doch wieder proprietären Klebstoff zwischen den Komponenten giesst. Eine Plattform, die offene Standards bewirbt, sie aber durch eigene, geschlossene Zwischenschichten ersetzt, reproduziert exakt den Lock-in, den die Standards eigentlich abschaffen.
Drittens: Souveränität wird konkret. Wenn Werkzeuge, Agenten und Modelle über offene, neutral verwaltete Protokolle komponieren, ist die Abhängigkeit von einem einzelnen Anbieter keine Architektur-Eigenschaft mehr, sondern eine bewusste Entscheidung. Ihr könnt Anbieter mischen, ersetzen oder europäisch betreiben — ohne dass das den Rest des Systems berührt. Das ist digitale Souveränität, technisch verankert statt politisch behauptet.
Die Frage, die ihr euch stellen solltet, ist deshalb nicht "Unterstützt das MCP und A2A?" — sondern "Baut das auf den offenen Standards auf, oder werden sie nur an der Oberfläche durchgereicht?"
Und genau hier kommt nopex ins Spiel
nopex ist auf offenen, herstellerübergreifenden Standards gebaut — nicht als Etikett, sondern als Architekturprinzip. Agenten und Werkzeuge komponieren bei uns frei über genau die Protokolle, auf die sich das Ökosystem gerade standardisiert: MCP für die Anbindung von Werkzeugen und Datenquellen, A2A für die Kommunikation zwischen Agenten. Das darunterliegende Modell und der Anbieter bleiben austauschbar.
Das ist der praktische Kern: Ihr erbt die Interoperabilität, die die Branche unter neutraler Governance vereinheitlicht — auf europäischer Infrastruktur, ohne harte Single-Vendor-Abhängigkeit. Fällt ein Modell weg oder taucht ein besseres auf, wechselt der Stack, ohne dass eure Integrationsarbeit verloren geht. Werkzeuge, die ihr heute anbindet, funktionieren auch mit dem Agenten von morgen.
Lock-in hat sich jahrelang an der Integrationsschicht versteckt. Offene Protokolle holen ihn ans Licht und machen ihn zur Wahl. Eine Plattform zu nutzen, die wirklich auf diesen Standards aufsetzt, heisst: Ihr trefft diese Wahl selbst — statt sie euch von einem Anbieter abnehmen zu lassen.
