A2A-Protokoll: Warum KI-Agenten HTTP für vernetzte KI-Systeme nutzen

Die größte Herausforderung im KI-Zeitalter ist nicht die Auswahl des richtigen Sprachmodells, sondern die sichere und effiziente Vernetzung intelligenter Systeme. Unternehmen stehen vor einer architektonischen Frage: Wie lassen sich autonome KI-Agenten nahtlos miteinander verbinden, ohne die Kontrolle über Datenflüsse und Sicherheitsprotokolle zu verlieren?

Die Antwort liegt in einem neuen Standard, der die Prinzipien klassischer verteilte Systeme mit den Anforderungen moderner KI-Architekturen vereint: dem Agent-to-Agent-Protokoll (A2A). Entwickelt unter dem Dach der Linux Foundation, wird A2A zum Rückgrat für die Kommunikation zwischen KI-Agenten – ähnlich wie HTTP einst die Vernetzung von Microservices revolutionierte. Mit Unterstützung von über 150 Unternehmen, darunter Branchengrößen wie Microsoft, SAP und Salesforce, etabliert sich A2A als offener Standard für eine neue Generation verteilter Intelligenz.

A2A und MCP: Zwei Protokolle für eine vernetzte KI-Architektur

Ein zentraler Irrtum bei der Planung von KI-Systemen ist die Annahme, ein einzelnes Protokoll könnte sowohl die Kommunikation zwischen Agenten als auch die Anbindung von Tools abdecken. Diese Überlegung führt zu komplexen, unwartbaren Architekturen. Die Lösung liegt in der klaren Trennung beider Schichten:

• Model Context Protocol (MCP): Verantwortlich für die Agent-zu-Tool-Kommunikation. MCP standardisiert, wie ein KI-Agent sicher auf Unternehmensdatenbanken, Speicherlösungen oder Entwicklungsumgebungen zugreift. Es handelt sich um eine vertikale Integration, die eine einzelne Instanz mit externen Ressourcen verbindet.
• Agent-to-Agent Protocol (A2A): Standardisiert die horizontale Kommunikation zwischen autonomen KI-Agenten. Hier geht es um die Vernetzung unabhängiger intelligenter Systeme, die Aufgaben delegieren, Zustände austauschen oder Workflows über Abteilungs- und Technologiegrenzen hinweg koordinieren.

Beide Protokolle sind komplementär, nicht konkurrierend. Gemeinsam bilden sie das Fundament für moderne Multi-Agenten-Systeme in Unternehmen.

Technische Grundlagen: Wie A2A aufgebaut ist

A2A verzichtet bewusst auf die Neuerfindung bekannter Webstandards. Stattdessen nutzt es etablierte Technologien, um maximale Kompatibilität und Sicherheit zu gewährleisten:

• HTTP/HTTPS als Transportschicht: Alle Kommunikation erfolgt über standardisierte Webprotokolle. In Produktionsumgebungen ist HTTPS mit modernen TLS-Versionen zwingend vorgeschrieben.
• JSON-RPC 2.0 für strukturierte Daten: Die Interaktion zwischen Agenten basiert auf diesem etablierten Format, das strukturierte Anfragen und Antworten ermöglicht.
• Server-Sent Events (SSE) für Echtzeit-Updates: Einseitige Datenströme erlauben Agenten, kontinuierlich Informationen an Clients zu senden, ohne auf Polling-Anfragen angewiesen zu sein.

Jeder A2A-Agent veröffentlicht eine Agent Card unter der standardisierten URL /.well-known/agent.json. Dieses kleine JSON-Dokument enthält:

• Identität und Fähigkeiten des Agenten
• Endpunkt-URL für die Kommunikation
• Authentifizierungsanforderungen

Diese Datei ermöglicht eine Null-Konfigurations-Entdeckung, bei der Agenten automatisch erkennen können, welche Dienste ihnen zur Verfügung stehen – ohne proprietäre Registries oder zentrale Koordinationsstellen.

Sicherheit ist integraler Bestandteil des Protokolls. A2A unterstützt moderne Authentifizierungsmechanismen wie OAuth 2.0 und API-Key-Autorisierung via HTTP-Header, die direkt in die OpenAPI-Sicherheitsschemata integriert sind.

Vier Kommunikationsmuster: Blockierend, asynchron, streaming und eventgesteuert

A2A definiert vier klar abgegrenzte Kommunikationsmuster, die sich an bewährte Konzepte verteilter Systeme anlehnen. Die Wahl des richtigen Musters hängt von der spezifischen Use-Case ab:

1. Synchronous (Blockierend)

Ein Agent sendet eine Aufgabe und wartet, bis der empfangende Agent eine vollständige Antwort zurückliefert. Dieses Muster eignet sich für zeitkritische Operationen, bei denen die Antwort direkt in die weitere Verarbeitung einfließen muss.

Beispiel aus der Praxis: Ein Orchestrierungs-Agent fragt einen Compliance-Agent nach einer Risikobewertung, bevor er eine Kundenanfrage beantwortet. Das Ergebnis ist deterministisch und muss sofort vorliegen.

Vergleich: Entspricht einem klassischen REST-API-Aufruf wie GET /resource.

2. Asynchronous (Nicht-blockierend)

Der sendende Agent delegiert eine Aufgabe und setzt seine Arbeit fort, ohne auf eine sofortige Antwort zu warten. Der empfangende Agent verarbeitet die Anfrage im Hintergrund und benachrichtigt den Absender im späteren Verlauf.

Einsatzszenario: Langlaufende KI-Aufgaben wie die Analyse eines 400-seitigen Vertragsdokuments durch einen Rechtsagenten oder die Klassifizierung großer Datensätze durch einen Datenagenten.

Analogie: Vergleichbar mit Message-Queue-Systemen wie Kafka oder RabbitMQ.

3. Streaming

Hier fließen Daten kontinuierlich und in Echtzeit zwischen Agenten. Anstatt auf eine abgeschlossene Antwort zu warten, werden Teilergebnisse oder Tokens sofort an den Empfänger übertragen.

Anwendungsfall: Echtzeit-Sprachtranskription, bei der ein Transkriptionsagent fortlaufend Text an einen Analyseagenten sendet, der diesen direkt verarbeitet. Auch interaktive Chat-Schnittstellen profitieren von diesem Muster.

Technische Basis: Server-Sent Events (SSE) oder gRPC-Streaming.

4. Push Notifications (Eventgesteuert)

Agenten registrieren sich für bestimmte Ereignisse und erhalten nur dann eine Benachrichtigung, wenn ein relevanter Zustand eintritt. Diese Push-Nachrichten erfolgen als asynchrone HTTP-POST-Anfragen an eine vom Agenten bereitgestellte Webhook-URL.

Praktisches Beispiel: Ein Compliance-Agent wird nur aktiv, wenn ein Vertragsagent einen Deal mit einem Volumen über 1 Million Euro bearbeitet. Der Compliance-Agent muss in seiner Agent Card die Unterstützung für Push-Benachrichtigungen deklarieren.

Vergleich: Entspricht Webhooks oder Event-Bus-Systemen in klassischen Microservice-Architekturen.

Ein ausgereiftes Multi-Agenten-System nutzt nicht nur ein einziges Muster, sondern kombiniert alle vier Ansätze. Ein zentraler API-Gateway-Layer übernimmt dabei die Steuerung des Datenverkehrs, die Routing-Entscheidungen und Fallback-Mechanismen.

Der Paradigmenwechsel: Von deterministischen zu semantischen Schnittstellen

In klassischen Microservice-Architekturen sind API-Verträge streng deterministisch: Ein spezifisches Eingabeformat führt zu einem vorhersagbaren Ausgabeformat. Die Schnittstelle zwischen KI-Agenten funktioniert jedoch semantisch: Statt exakter Byte-Folgen wird ein Kontext oder eine Absicht übertragen, auf die der empfangende Agent mit einer begründeten, kontextabhängigen Antwort reagiert.

Anstatt eine feste API-Spezifikation zu pflegen, wird der intent zum neuen Vertrag. Ein Agent formuliert eine Anfrage wie: „Analysiere dieses Dokument auf regulatorische Risiken“ – und erhält eine Antwort, die nicht nur die Analyseergebnisse, sondern auch eine Begründung enthält.

Dieser Wechsel von deterministischen zu semantischen Schnittstellen erfordert ein Umdenken in der Systemgestaltung. Unternehmen müssen:

• Klare Intentionsmodelle für ihre Agenten definieren
• Kontextmanagement implementieren, um relevante Informationen zwischen Agenten zu übertragen
• Sicherheitsmechanismen etablieren, die mit probabilistischen Antworten umgehen können

Ausblick: A2A als Grundlage für die nächste Generation verteilter KI

Das Agent-to-Agent-Protokoll markiert einen Wendepunkt in der Entwicklung unternehmensweiter KI-Systeme. Ähnlich wie HTTP einst die Vernetzung von Webanwendungen demokratisierte, wird A2A die Grundlage für eine neue Ära verteilter Intelligenz. Die Kombination aus MCP für Tool-Integration und A2A für Agentenkommunikation schafft ein robustes, skalierbares Ökosystem, das Unternehmen die Freiheit gibt, KI-Agenten nach Bedarf zu kombinieren – ohne vendor-lock-in oder proprietäre Silos.

Die Herausforderungen der nächsten Jahre liegen nicht mehr in der Technologie selbst, sondern in der strategischen Orchestrierung dieser Agentennetzwerke. Unternehmen, die frühzeitig mit der Implementierung von A2A beginnen, werden nicht nur technologische Vorteile erzielen, sondern auch die Grundlage für eine neue Generation intelligenter, autonomer Systeme legen.