Wie unabhängige KI-Agenten zusammenarbeiten: eine A2A-Brücke für Hermes Agent

Was das für Ihr Unternehmen bedeutet

• Ihre Agenten arbeiten ohne Neuschreiben zusammen. Das Agent2Agent Protocol (A2A) ist ein offener Standard, mit dem sich KI-Agenten gegenseitig entdecken, Arbeit delegieren und Ergebnisse streamen. Eine schlanke Brücke lässt einen vorhandenen Agenten diesen Standard sprechen, ohne sein Inneres zu ändern — die bereits getätigte Investition bleibt erhalten.
• Keine Anbieterbindung. Da die Brücke zwischen Standard und Agent sitzt, können Sie das zugrunde liegende Agenten-Framework später austauschen, ohne die darauf aufgebauten Integrationen zu zerstören. Andere Teams rufen weiterhin denselben Standard-Endpunkt auf.
• Ein System bedient viele Kunden oder Geschäftsbereiche — mit strikter Datentrennung. Die Mandantentrennung wird auf Datenbankebene erzwungen, nicht nur im Anwendungscode, sodass ein Programmierfehler die Daten eines Kunden nicht an einen anderen weitergeben kann. Das ist der Unterschied, der eine Sicherheitsprüfung besteht.
• Menschen behalten die Kontrolle über sensible Aktionen. Wenn ein Agent eine Freigabe benötigt — einen Einkauf, eine Datenzugriffsentscheidung, die Freigabe eines Angebots —, erscheint die Anfrage als standardisierter Zustand „wartet auf Freigabe", der bis zu der Person oder dem Agenten zurückreicht, die die Kette gestartet haben, sogar über Framework-Grenzen hinweg.
• Es ist real und getestet, keine Folie. Das Ganze ist als Open-Source-Deployment (docker-a2a-hermes-agent-gateway) verpackt, mit einer automatisierten Testsuite, die jede Fähigkeit nachweist, bevor Sie sich darauf verlassen.

Das Problem: Agenten, die nicht miteinander sprechen können

Die meisten Organisationen übernehmen nicht „einen KI-Agenten". Sie häufen mehrere an. Hier ein Angebots-Agent, dort ein Katalog-Abfrage-Agent, dazu ein Bestands-Agent eines anderen Teams — oft auf verschiedenen Frameworks, mitunter von verschiedenen Anbietern, zu verschiedenen Zeiten gebaut. Einzeln funktionieren sie. Der Engpass ist, sie zur Zusammenarbeit zu bringen: einem anderen Arbeit zu übergeben, auf ein Ergebnis zu warten und die Kontrolle zurückzugeben.

Das per Hand zu lösen, indem man jeden Agenten mit jedem anderen verdrahtet, ist langsam, brüchig und wird mit jedem neuen Agenten schlimmer. Es führt zudem still in eine Bindung: Sobald Integrationen fest auf die Schnittstelle eines Anbieters codiert sind, bedeutet ein Anbieterwechsel, sie alle neu zu machen.

Das Agent2Agent Protocol (A2A) ist der offene Standard, der diesen Engpass beseitigt. Es definiert eine gemeinsame Sprache, mit der sich Agenten entdecken, Aufgaben delegieren, Fortschritt streamen und Abschluss melden — unabhängig davon, worauf jeder aufbaut. Übernehmen Sie den Standard einmal, und jeder neue Agent spricht dieselbe Sprache wie die übrigen.

Der Haken: Ihre vorhandenen Agenten sprechen A2A nicht nativ. Hermes Agent von Nous Research etwa stellt seine eigene Schnittstelle bereit. Einen funktionierenden Agenten neu zu schreiben, um ein neues Protokoll hinzuzufügen, ist genau die Art teures, riskantes Projekt, das Teams vermeiden möchten.

Die Antwort ist eine Brücke — eine kleine Übersetzungsschicht, die nach außen A2A spricht und nach innen mit dem Agenten in dessen eigener Sprache kommuniziert. Der Agent selbst ändert sich nie. Das Projekt docker-a2a-hermes-agent-gateway ist ein funktionierendes, quelloffenes Beispiel dieser Brücke, verpackt als eine einzige bereitstellbare Einheit.

Wie die Teile zusammenpassen

Es gibt drei bewegliche Teile, und nur eines davon ist der Außenwelt ausgesetzt:

1. Die Eingangstür (das Gateway). Alles kommt durch einen einzigen kontrollierten Zugangspunkt herein. Es entscheidet, wer hinein darf, zu welchem Kunden eine Anfrage gehört, wie schnell Aufrufer vorgehen dürfen und wie Live-Fortschritt zurückgestreamt wird. Nichts anderes ist direkt erreichbar.
2. Der Übersetzer (die Brücke). Er empfängt Anfragen im offenen A2A-Standard und wandelt sie in das um, was Ihr Agent tatsächlich versteht — und die Antwort wieder zurück. Dies ist das einzige Teil, das etwas über den konkreten Agenten weiß, und genau deshalb lässt sich der Agent später austauschen.
3. Der Agent und sein Arbeitsprotokoll. Ihr vorhandener Agent leistet das eigentliche Denken. Alles, was er tut, wird festgehalten — jede Aufgabe und jede Nachricht — und dabei streng nach Kunde getrennt.

Da Eingangstür und Protokoll vom Agenten selbst unabhängig sind, können Sie das Gateway in Ihrer eigenen Cloud belassen und es auf einen anderswo laufenden Agenten oder auf eine verwaltete Datenbank Ihrer Wahl richten. Nichts zwingt die drei an denselben Ort.

Den Standard übernehmen, ohne Ihre Agenten neu zu schreiben

Die wertvollste Eigenschaft hier ist, dass Ihr Agent sich nie ändert. Der Übersetzer erledigt die gesamte Arbeit, den Standard an seiner Stelle zu sprechen.

Das hat zwei unmittelbare geschäftliche Folgen:

• Sie schützen die bereits getätigte Investition. Das Team, das den Angebots-Agenten gebaut hat, hält nicht inne, um ihn für ein neues Protokoll umzubauen. Es fügt eine Brücke hinzu und macht weiter.
• Sie vermeiden Bindung in beide Richtungen. Aufrufer hängen allein vom offenen Standard ab, nicht von Ihrem Agenten-Anbieter. Ersetzen Sie den Agenten später — ein besseres Modell, ein günstigerer Anbieter, eine Eigenentwicklung —, ändern Sie den Übersetzer, und alle darauf aufgebauten Integrationen laufen unangetastet weiter. Umgekehrt kann ein einziges Gateway die Fassade mehrerer verschiedener Agenten zugleich sein: rechenintensive Denkarbeit zum einen, routinemäßige Workflow-Schritte zum anderen geleitet, für den Aufrufer identisch aussehend. Die Wahl der Engine wird zu einem Implementierungsdetail, das Sie kontrollieren, nicht zu einer Festlegung, die Sie bindet.

Viele Kunden oder Geschäftsbereiche bedienen — mit einer Datentrennung, die eine Prüfung übersteht

Dasselbe Deployment kann viele Mandanten — verschiedene Kunden oder verschiedene interne Geschäftsbereiche — aus einem einzigen laufenden System bedienen. Jeder erhält eigene Agenten, eigene Aufgabenhistorie und eigenen Nachrichtenspeicher.

Was das nicht nur bequem, sondern sicher macht, ist, wo die Trennung erzwungen wird. Jede Anfrage wird mit dem Kunden markiert, zu dem sie gehört, und die Datenbank selbst weigert sich, die Zeilen eines Kunden an einen anderen zurückzugeben — eine Kontrolle auf der Datenebene, unterhalb des Anwendungscodes. In der Praxis bedeutet das, dass ein Fehler oder ein vergessener Filter in der Software Daten nicht kundenübergreifend preisgeben kann, weil das Sicherheitsnetz die Datenbank ist, nicht die Anwendung. Das ist der Unterschied, nach dem ein Sicherheits- oder Compliance-Prüfer sucht, und der, der es Ihnen erlaubt, mehrere Kunden auf gemeinsame Infrastruktur zu legen, ohne ihre Daten zu gefährden.

Menschen bei sensiblen Aktionen am Steuer halten

Autonomie ist nur akzeptabel, wenn ein Mensch in den entscheidenden Momenten eingreifen kann. Wenn ein Agent einen Schritt erreicht, der eine Freigabe erfordert — einen Einkauf autorisieren, ein Angebot freigeben, sensible Daten freigeben —, fährt er nicht einfach fort. Er hält an und wirft einen standardisierten Zustand „wartet auf Freigabe" auf.

Das Wesentliche ist, dass dieser Zustand wandert. Eine Anfrage, die mehrere Agenten zuvor begann — womöglich auf einem völlig anderen Framework, im Besitz eines anderen Teams —, erhält dasselbe Signal „Eingabe erforderlich", unverändert. Ein Mensch gibt frei (oder lehnt ab), und die Arbeit wird fortgesetzt. Governance endet nicht an der Grenze eines Agenten; der offene Standard trägt das Freigabe-Gate über die gesamte Kette. Für jeden Workflow, der Geld, Verträge oder regulierte Daten berührt, ist diese durchgängige Kontrolle das, was die Delegation zwischen Agenten vertretbar statt leichtsinnig macht.

Dort betreiben, wo Ihre Daten liegen müssen

Das Deployment ist ein einzelnes, in sich geschlossenes Paket, das für einen schnellen Start gebündelt — Agent, Datenbank und Gateway zusammen — oder für die Produktion aufgeteilt laufen kann. Sie können die kontrollierte Eingangstür in Ihrem eigenen Netzwerk belassen und sie auf eine verwaltete Datenbank (sodass Backups, Verschlüsselung und Compliance von Ihrem Cloud-Anbieter übernommen werden) sowie auf einen auf separater Hardware laufenden Agenten richten.

Für Unternehmen mit Anforderungen an Datenresidenz oder -souveränität ist das wichtig: Das Protokoll jeder Agenten-Interaktion kann innerhalb der von Ihren Richtlinien geforderten Grenze bleiben, statt in der Cloud eines Dritten, die Sie nicht kontrollieren.

Erprobt, bevor Sie sich darauf verlassen

Eine Fähigkeit, die Sie nicht überprüfen können, ist eine Belastung. Dieses Deployment wird mit einer automatisierten Testsuite geliefert, die das real laufende System durchgängig durchspielt — sie bestätigt, dass Agenten entdeckt werden können, dass Anfragen abgeschlossen werden, dass Live-Fortschritt korrekt gestreamt wird, dass ein Client, der eine Live-Aktualisierung verpasst, das vollständige Ergebnis dennoch abrufen kann, und dass Fehler und Abbrüche sich wie erwartet verhalten. Die Tests melden pro Prüfung ein klares Bestanden oder Nichtbestanden und sind darauf ausgelegt, als automatisiertes Gate zu laufen, sodass eine fehlerhafte Änderung erkannt wird, bevor sie die Produktion erreicht, nicht danach.

Der praktische Nutzen ist Risikominderung: Sie verlassen sich auf niemandes Wort, dass die Integration funktioniert. Sie wird bei jeder Änderung wiederholbar nachgewiesen.

Was der Produktivbetrieb tatsächlich erfordert

Ehrlichkeit über die Betriebskosten gehört zum geschäftlichen Argument. Einige Realitäten, die es einzuplanen gilt:

• Es ist darauf ausgelegt, schlank zu laufen und dann bewusst zu skalieren. Die Voreinstellung ist ein einzelnes, einfaches Deployment. Sehr hohes Volumen über mehrere Kopien zu bedienen, wird unterstützt, ist aber ein bewusster Schritt, kein Zufall: Es erfordert gemeinsam genutzte Infrastruktur, damit die Kopien konsistent bleiben. Planen Sie die Skalierung; nehmen Sie sie nicht als kostenlos an.
• Aktuell zu bleiben ist Routine, kein Neuschreiben. Die Bausteine werden aus ihren Open-Source-Quellen bezogen, sodass das Aktualisieren ein standardmäßiger Vorgang ist, den Ihr Team nach Zeitplan durchführt.
• Die Sicherheitshaltung legen Sie fest. Das Paket wird mit Platzhalter-Passwörtern und freizügigen Voreinstellungen geliefert, damit es einfach out of the box startet — sie sind dazu gedacht, vor der Exposition ins Internet ersetzt zu werden. Der optional mitgelieferte Agent ist mächtig und sollte nur auf Infrastruktur laufen, der Sie vertrauen. Nichts davon ist exotisch; es ist die normale Härtung, die jedes Produktivsystem benötigt, und sie gehört auf die Go-live-Checkliste.

Keiner dieser Punkte ist ein Blocker. Es sind die gewöhnlichen Pflichten des Betriebs eines echten Systems, und sie vorab zu benennen ist der Weg, Überraschungen nach dem Start zu vermeiden.

Was das ermöglicht

Zusammengenommen liefert das Brückenmuster drei Dinge, die sich von Grund auf nur schwer zusammensetzen lassen:

1. Standardbasierte Zusammenarbeit ohne Neuschreiben. Jeder Agent, der A2A spricht, kann sofort mit Ihrem vorhandenen Agenten zusammenarbeiten — ihn entdecken, an ihn delegieren und seinen Fortschritt verfolgen —, ohne dass dieser Agent verändert wird. Sie übernehmen einen offenen Standard und behalten zugleich, was bereits funktioniert.

2. Mandantenfähiger Dienst mit echter Isolation. Ein einziges Deployment bedient viele Kunden oder Geschäftsbereiche, wobei die Datentrennung auf Datenbankebene erzwungen wird. Das erlaubt Ihnen, auf gemeinsam genutzte Infrastruktur zu konsolidieren, ohne die Sicherheit zu schwächen.

3. Gesteuerte Autonomie über Grenzen hinweg. Menschliche Freigabe-Gates wandern mit der Arbeit, sodass sensible Aktionen einen Menschen in der Schleife haben — egal, durch wie viele Agenten oder wie viele Frameworks die Anfrage gelaufen ist.

Die funktionierende Implementierung ist quelloffen und vollständig dokumentiert: Die Brücke und ihr Integrationsleitfaden liegen im Repository a2a_daemon_engine (siehe den Hermes-Integrationsleitfaden), und die kontrollierte Eingangstür ist im Repository SilvaEngine Gateway dokumentiert. Das vollständige Deployment ist in docker-a2a-hermes-agent-gateway verpackt.

Weiterführende Lektüre

• MCP + A2A: die zwei Protokolle hinter jedem produktiven agentischen KI-System — wie die zwei offenen Standards die Arbeit aufteilen: MCP verbindet Agenten mit Werkzeugen, A2A verbindet Agenten untereinander
• A2A in vorhandene Agenten-Frameworks integrieren: eine Hermes-Agent-Demonstration — das allgemeine Brückenmuster und seine Anwendung über Hermes hinaus
• MCP-Modul-Codestandard — die Disziplin, die Agenten-Integrationen produktionsreif hält, während sie sich vervielfachen

---

Ein mittelständischer Distributor braucht Angebots-Agenten, die mit Katalog-Agenten sprechen, die mit Bestands-Agenten sprechen — jeder von einem anderen Team gebaut, jeder möglicherweise auf einem anderen Framework. Ein offener Standard gibt diesen Agenten eine gemeinsame Sprache. Eine Brücke lässt die Agenten, die Sie bereits betreiben, mitmachen, ohne sie neu zu bauen. Das Ergebnis ist ein System, in dem Agenten zusammenarbeiten, die Daten jedes Kunden getrennt bleiben und ein Mensch die Kontrolle über die Entscheidungen behält, die zählen.

Einen umrissenen Build anfragen

Eine Woche Discovery. Sie erhalten eine Systeminventur, eine Workflow-Karte und einen festen Umfang — ob Sie mit uns bauen oder nicht.