KI-Agenten-Kommunikation: Vier Protokolle, ein Ziel – und ein ungelöstes Transportproblem

Die Ära der einheitlichen Standards in der verteilten Datenverarbeitung war selten langlebig. In den späten 1990er-Jahren konkurrierten CORBA, DCOM, RMI und frühe SOAP-Implementierungen um die Integration unternehmensinterner Systeme – bis REST mit seiner Einfachheit und HTTP-Nativität zum stillen Sieger wurde. Ähnlich fragmentiert war einst die Echtzeitkommunikation: XMPP, IRC und proprietäre Lösungen dominierten, bis MQTT und WebSockets klare Nischen besetzten. Heute wiederholt sich dieses Muster im aufstrebenden Ökosystem der KI-Agenten. Doch während die Protokollvielfalt zunächst chaotisch wirkt, zeichnet sich bereits eine Arbeitsteilung ab.

Vier Protokolle, vier unterschiedliche Aufgaben

Seit Ende 2024 wurden innerhalb von nur 18 Monaten vier zentrale Protokolle veröffentlicht, die jeweils spezifische Aspekte der Agentenkommunikation adressieren: Model Context Protocol (MCP) von Anthropic, Agent Communication Protocol (ACP) von IBM Research, Agent2Agent (A2A) von Google sowie das Agent Network Protocol (ANP) einer unabhängigen Arbeitsgruppe. Parallel dazu etablieren Gremien wie die W3C AI Agent Protocol Community Group und die IETF erste Standardisierungswege. Die Flut an GitHub-Repositories, die „das Agenten-Kommunikationsproblem lösen“, unterstreicht den Innovationsdruck – doch die meisten dieser Projekte adressieren unterschiedliche Ebenen des Stacks.

• MCP fungiert als Schnittstelle für Tool-Aufrufe und definiert, wie ein KI-Modell verfügbare Funktionen eines Servers entdeckt, aufruft und Antworten interpretiert. Als typsicheres Remote-Procedure-Call-Protokoll über HTTP hat es sich bereits als De-facto-Standard für Tool-Integration durchgesetzt. Bis April 2026 verzeichnete die Linux Foundation über 10.000 aktive öffentliche MCP-Server sowie 164 Millionen monatliche Downloads des Python-SDKs.

• A2A übernimmt die Koordination zwischen Agenten, indem es Aufgaben zwischen ihnen delegiert. Dazu führt es Agent Cards (Fähigkeitsbeschreibungen), Lebenszyklus-Zustände von Aufgaben sowie drei Interaktionsmodi ein: synchron, streaming-basiert und asynchron. Nach der Spende an die Linux Foundation im Juni 2025 wurde A2A von Enterprise-Teams übernommen, da es die Lücke füllt, die MCP offenlässt.

• ACP dient als leichtgewichtiges Nachrichtenformat für Agent-zu-Agent-Kommunikation ohne den vollen Koordinationsaufwand von A2A. Es eignet sich für Systeme, in denen einfache Nachrichtenübermittlung ausreicht.

• ANP konzentriert sich auf Identitätsmanagement und Entdeckung. Mit dezentralen Identifikatoren (DIDs) und JSON-LD-Graphen ermöglicht es dezentrale Agenten-Marktplätze, in denen keine zentrale Registrierung erforderlich ist.

Warum HTTP an seine Grenzen stößt

Alle genannten Protokolle laufen über HTTP – ein Erbe aus der Entstehungszeit der Projekte. Forschungsteams, API-Anbieter und Enterprise-Softwareentwickler setzen auf eine Technologie, die sie kennen, die ihre Server bereits unterstützen und die Demos vereinfacht. Doch in der Produktion zeigt sich ein fundamentales Problem: HTTP setzt einen erreichbaren Server voraus. Laut aktuellen Schätzungen befinden sich 88 % aller Netzwerkgeräte hinter Network Address Translation (NAT), was direkte Verbindungen ohne Relay unmöglich macht.

Für Agentenflotten, die Aufgaben direkt zwischen Peers über Cloud-Grenzen, Heimnetzwerke oder Edge-Deployments austauschen müssen, bedeutet dies: Jede Kommunikation muss über zentrale Relays geleitet werden. Diese Lösung führt zu höheren Latenzzeiten, zusätzlichen Kosten und einem zentralen Ausfallpunkt. Die Protokolle MCP, A2A, ACP und ANP lösen zwar die Semantik des Was Agenten einander mitteilen – doch das Wie der Verbindung bleibt ungeklärt. Dies ist eine Aufgabe der Session-Schicht (OSI-Modell, Layer 5), die keiner der genannten Standards abdeckt.

Technologien für direkte Peer-to-Peer-Verbindungen existieren bereits

Die notwendigen Bausteine für eine Lösung sind längst verfügbar:

• UDP Hole-Punching mit STUN ermöglicht NAT-Durchdringung in etwa 70 % der Netzwerktopologien.
• X25519 Diffie-Hellman und AES-256-GCM sorgen für authentifizierte Verschlüsselung auf Tunnel-Ebene ohne zentrale Zertifizierungsstellen.
• QUIC (RFC 9000) oder benutzerdefinierte Protokolle über UDP bieten zuverlässige Übertragung ohne TCP-typische Blockaden.

Diese Technologien kommen bereits in Anwendungen wie WireGuard (VPN-Tunnel) oder WebRTC (Browser-zu-Browser-Medienströme) zum Einsatz. Der entscheidende Unterschied im Agentenkontext liegt in der fähigkeitsbasierten Routing-Logik: Agenten müssen nicht über Hostnamen, sondern über ihre Fähigkeiten gefunden werden – etwa mit der Anfrage „Welche Agenten bieten Echtzeit-Fremdwährungsdaten?“ und einer Liste aktuell verfügbarer Spezialisten.

Pilot Protocol als vielversprechender Ansatz

Ein Projekt, das diese Puzzleteile kombiniert, ist das Pilot Protocol. Mit einer veröffentlichten Spezifikation und einem IETF-Internet-Draft setzt es auf eine erweiterte Version der ANP-Ideen, angewendet auf die Transportschicht. Pilot Protocol integriert Fähigkeitsabfragen, authentifizierte Peer-Verbindungen und direkte Kommunikation – selbst hinter NAT. Sollte sich dieser Ansatz durchsetzen, könnte er die letzte Lücke im KI-Agenten-Ökosystem schließen.

Die nächste Phase der KI-Agenten-Entwicklung wird nicht nur von semantischen Protokollen, sondern von der Fähigkeit abhängen, zuverlässige, kostengünstige und latenzarme Verbindungen zwischen Agenten herzustellen. Wer heute in Agentenarchitekturen investiert, sollte diese Entwicklungen genau beobachten – denn die Lösung des Transportproblems könnte den Unterschied zwischen experimentellen Prototypen und produktionsreifen Systemen ausmachen.