Agenten beauftragen Agenten

Warum ein gemeinsames Protokoll überhaupt etwas spart

Bei Punkt-zu-Punkt-Verbindungen wächst der Aufwand mit dem Quadrat der Beteiligten: Jeder Agent braucht einen Adapter für jeden anderen. Einigen sich alle auf dasselbe Vorgehen, sinkt das auf eine Schnittstelle je Agent. Das ist derselbe Effekt, den Unternehmen bei Schnittstellen zwischen Fachsystemen längst kennen, nur dass er hier innerhalb weniger Monate eintritt, weil Agenten schnell gebaut sind.

Der zweite Gewinn ist die Unabhängigkeit vom Innenleben. Ein Agent, der über ein Protokoll angesprochen wird, darf sein Modell wechseln, sein Werkzeug austauschen oder komplett neu geschrieben werden, solange die Beschreibung seiner Fähigkeiten gleich bleibt. Das ist der eigentliche Grund, warum sich der Umweg lohnt, sobald zwei Teams unabhängig voneinander arbeiten.

Fähigkeiten müssen auffindbar sein

Damit ein Agent einen anderen beauftragen kann, muss er wissen, was der andere kann. Dafür veröffentlicht jeder Agent eine maschinenlesbare Beschreibung mit Name, Zweck, Endpunkt, Anmeldeverfahren und einer Liste seiner Fähigkeiten. Diese Karte liegt unter einer festen, vorab bekannten Adresse, damit die Verbindung nicht von Hand eingetragen werden muss.

Die genaue Adresse dieser Beschreibung hat sich zwischen Fassungen der Spezifikation bereits geändert. Verlass dich deshalb nicht auf den Pfad, sondern führe im eigenen Haus ein Verzeichnis, in dem für jeden Agenten steht, wo seine Beschreibung liegt und welche Protokollfassung er spricht.

Im Unternehmen ist dieses Verzeichnis ohnehin wichtiger als das automatische Auffinden im offenen Netz. Interessant ist dort nicht nur, welche Agenten es gibt, sondern auch, wer sie verantwortet, welche Daten sie sehen dürfen und wen man anruft, wenn einer Unsinn liefert.

Abgrenzung zu MCP und zum gewöhnlichen Schnittstellenaufruf

MCP und A2A werden oft verwechselt, obwohl sie auf verschiedenen Ebenen sitzen. MCP verbindet einen Agenten mit Werkzeugen und Datenquellen, also nach innen. A2A verbindet Agenten untereinander, also nach außen. Beides zusammen ist der Normalfall: Ein Agent nutzt intern seine MCP-Server und spricht nach außen mit anderen Agenten.

Gegen den klassischen Schnittstellenaufruf grenzt sich das Protokoll durch drei Eigenschaften ab: Der Auftrag lebt länger als der Aufruf, Inhalte reisen gemischt als Text, Datei und strukturierte Daten, und der beauftragte Agent darf zurückfragen, statt zu raten.

Daraus folgt eine nützliche Faustregel. Wenn dein Fall lautet, eine Funktion aufzurufen und einen Wert zurückzubekommen, bleibt eine gewöhnliche Schnittstelle die einfachere und robustere Antwort. Erst wenn Aufgaben dauern, Rückfragen entstehen und das Ergebnis mehr ist als ein Wert, zahlt sich der Aufwand aus.

Was im Betrieb tatsächlich wehtut

Die schwierigste Frage ist die nach der Identität. Mit wessen Rechten arbeitet der beauftragte Agent? Nimmt er seine eigene technische Kennung, sieht er im Zweifel mehr als die Person, für die er arbeitet, und liefert Daten zurück, die diese Person nie hätte öffnen dürfen. Diese Lücke fällt in der Entwicklung nicht auf, weil dort alle alles dürfen.

Die zweite Frage ist die Nachvollziehbarkeit. Wenn drei Agenten an einem Ergebnis beteiligt waren, muss die Auftragskennung über alle Sprünge hinweg mitreisen, zusammen mit Name und Version des jeweiligen Agenten. Sonst steht am Ende eine Aussage im Raum, und niemand kann sagen, woher sie stammt.

Und schließlich die Begrenzung. Agenten, die sich gegenseitig beauftragen dürfen, können Kreise bilden. Eine maximale Sprungtiefe je Auftrag, ein Budget je Auftrag und die Möglichkeit, einen laufenden Auftrag abzubrechen, sind keine Feinheiten für später, sondern gehören in die erste Fassung.