In den letzten zwei Jahren folgte das AI-Engineering einem einfachen Skript: Einem Agenten einen Prompt, einige Tools und eine Memory-Schicht geben.

In den letzten zwei Jahren folgte das AI-Engineering einem einfachen Skript. Man gab einem Agenten einen Prompt, einige Tools und eine Memory-Layer. Man sah zu, wie er ein Meeting plante, einen Vertrag zusammenfasste oder ein Skript debuggte. Das gesamte Ziel bestand darin, einen einzelnen Agenten für sich allein nützlich zu machen.

Dieses Ziel hat sich geändert.

Wir beobachten nun, wie sich die Branche von Solo-Agenten hin zu Agenten-Teams verschiebt. Ein Triage-Bot für den Kundenservice identifiziert eine Rückerstattungsanfrage und leitet den Fall an einen Zahlungs-Agenten weiter. Ein Research-Agent, der Webdaten scrapt, stößt auf eine Nische und delegiert die Aufgabe an einen Spezialisten, der auf einer proprietären Datenbank sitzt. Ein Logistik-Agent, der eine Sendung plant, benötigt ein Echtzeit-Frachtangebot und fragt daher einen Pricing-Agenten nach einem Wert.

Auf dem Papier klingt das einfach. In der Praxis ist es jedoch instabil.

Die neue Herausforderung ist die Interoperabilität. Teams bauen Agenten in unterschiedlichen Frameworks. Verschiedene Anbieter liefern Agenten mit unterschiedlichen Schnittstellen aus. Wenn ein Unternehmen mit einem anderen zusammenarbeiten muss, vergrößert sich die Lücke. Wir haben nun eine Landschaft voller fähiger Mitarbeiter, denen es an einer gemeinsamen Sprache fehlt. Ein Agent kann einen anderen Agenten nicht in einem Verzeichnis nachschlagen. Er kann keine Beschreibung dessen lesen, was sein Kollege tut. Und er kann eine sensible Aufgabe nicht übergeben, ohne das Risiko von Datenlecks, Kontextverlust oder doppelter Ausführung einzugehen.

Genau das ist das Problem, das A2A zu lösen versucht. Es bietet Agenten ein gemeinsames Protokoll für Discovery, Delegation und sichere Zusammenarbeit.

Von Einzel-Agenten zu Agenten-Silos

Die erste Welle der Agenten-Frameworks betrachtete die Systemgrenze als die Grenze des Agenten. Man baute einen Reasoning-Loop, gab ihm ein Tool-Belt und hoffte, dass er sich seinen Weg durch einen Workflow denken konnte. Das funktionierte gut genug, solange der Agent innerhalb einer Codebase, eines Cloud-Accounts oder einer Anbieterplattform blieb.

Reale Unternehmen arbeiten nicht innerhalb von Monolithen. Eine Rückerstattungsanfrage kann in einem CRM beginnen, zu einem in Python geschriebenen internen Zahlungsdienst springen und in einer von einem Drittanbieter gehosteten Betrugsprüfung enden. Wenn man jeden dieser Dienste als Agenten modelliert, erkennt man schnell, dass auf unterschiedlichen Stacks aufgebaute Agenten einander nicht nativ verstehen. Enterprise-Agenten, die auf proprietären Frameworks basieren, kommunizieren ihre Fähigkeiten nicht an die Außenwelt.

Ohne einen Standard wird jede Integration zu einem Individualprojekt. Ingenieure schreiben einmaligen Glue-Code. Kontext geht bei der Übersetzung verloren. Sicherheitsrichtlinien werden inkonsistent, da jede Übergabe maßgeschneidert ist.

Agent Cards: Ein öffentlicher Lebenslauf

A2A führt Agent Cards ein, als eine Möglichkeit für Agenten, bekannt zu geben, wer sie sind und was sie können.

Betrachten Sie eine Agent Card als einen maschinenlesbaren Lebenslauf. Ein Agent veröffentlicht eine Card, die seinen Fachbereich, seine erforderlichen Inputs, seine erwarteten Outputs und etwaige Einschränkungen für die akzeptierte Arbeit beschreibt. Ein Zahlungs-Agent könnte erklären, dass er Rückerstattungsanfragen unter einem bestimmten Betrag verarbeitet, sofern ihm eine Bestell-ID und ein Grundcode übergeben werden, und dass er entweder eine Bestätigungsnummer oder einen Fehler zurückgibt. Ein Datenspezialist könnte angeben, dass er strukturierte Dateien bis zu einer bestimmten Größe akzeptiert und bereinigte Zeitreihendaten innerhalb eines vorhersehbaren Zeitfensters zurückgibt.

Bevor er Arbeit delegiert, liest der anfordernde Agent die Card. Er versteht, ob der Ziel-Agent überhaupt in der Lage ist, den Job zu erledigen. Er erfährt, welches Format der Payload benötigt. Er weiß, ob er eine synchrone Antwort oder eine asynchrone Aufgabe erwarten sollte, die erst später abgeschlossen wird.

Dies macht das Raten überflüssig. Anstatt Integrationen für jeden möglichen Partner hart zu codieren, kann ein Agent verfügbare Fähigkeiten durchsuchen und dynamisch den richtigen Teamkollegen auswählen.

Tasks: Strukturierte Arbeit, nicht nur API-Aufrufe

Agenten müssen nicht wie Menschen chatten. Sie müssen Aufgaben sauber übergeben können. A2A modelliert diesen Austausch als eine Task.

Eine Task ist mehr als