# A2A: Wenn Agenten zusammenarbeiten URL: https://www.mikebild.dev/de/blog/a2a-agenten-zusammenarbeit/ Ein Agentensystem braucht eine begrenzte Codeänderung in einem fremden Repository. Es könnte selbst Werkzeuge laden, den Code lesen und die Änderung entwerfen. Es kann den Auftrag aber auch an ein eigenständiges System übergeben, das in einer anderen Umgebung läuft, eigene Berechtigungen besitzt und später ein prüfbares Ergebnis zurückmeldet. A2A 1.0 – die Abkürzung steht für Agent2Agent – beschreibt für diesen zweiten Fall die Übergabe und Verfolgung eines Auftrags zwischen eigenständigen Systemen. Die veröffentlichte Spezifikation des offenen Protokolls behandelt, wie ein Auftraggeber einen entfernten Agenten findet, ihm Nachrichten übermittelt, länger laufende Aufgaben verfolgt und Ergebnisse entgegennimmt. Welches Sprachmodell, welche Programmiersprache oder welches Framework intern arbeitet, schreibt sie nicht vor. Und A2A ist keine abstrakte Zukunftsidee: Bei der Aktualisierung dieses Artikels am 18. August 2026 besitzen WorkKit und CodeKit an den geprüften Repository-Ständen konkrete, authentifizierte A2A-1.0-Schnittstellen, über die andere Agentensysteme begrenzte Aufträge übermitteln können. ## Eigenständig ist das entscheidende Wort Nicht jede benannte Rolle ist ein eigener Agent. Wenn eine Anwendung nacheinander drei Prompts ausführt und alle Werkzeuge, Zugangsdaten und Zustände zentral verwaltet, sind das aus Sicht der Architektur drei Arbeitsschritte in einem Agentensystem. A2A bringt dort wenig. Ein entfernter A2A-Agent ist dagegen ein eigenständiger Dienst. Er entscheidet innerhalb seines Auftrags selbst, wie er arbeitet. Der aufrufende Agent sieht die angebotenen Fähigkeiten und die ausgetauschten Daten, aber nicht automatisch den internen Speicher, die Überlegungen oder die Werkzeuge des anderen Systems. Diese Kapselung trennt die Berechtigungs- und Task-Grenzen beider Systeme: Der entfernte Agent arbeitet mit eigenen Zugriffsrechten, und ausgetauscht werden sollte nur, was der Auftrag vorsieht. Im Protokoll nimmt ein A2A-Client im Auftrag des Benutzers Kontakt auf. Der A2A-Server stellt den entfernten Agenten bereit. Client und Server sind Kommunikationsrollen, keine Systemklassen: Bei einem anderen Auftrag kann dasselbe System die andere Rolle einnehmen. ```mermaid flowchart LR U["Benutzer
gibt ein Ziel vor"] --> C["Aufrufender Agent
A2A-Client"] C -->|"Agent Card lesen"| S["Entfernter Agent
A2A-Server"] C -->|"Message
Auftrag und Kontext"| S S -->|"Task
Zustand und Rückfragen"| C S -->|"Artifacts
Ergebnisse"| C S --> M["Interne Modelle, Tools
und Datenquellen"] C -.->|"kein automatischer Zugriff"| M ``` ## Die Agent Card ist die Beschreibung, nicht die Berechtigung Bevor ein Client einen Auftrag sendet, muss er wissen, was der andere Agent anbietet und wie er erreichbar ist. Dafür dient die Agent Card, ein JSON-Dokument mit Metadaten. Die veröffentlichte A2A-1.0-Spezifikation beschreibt darin unter anderem Identität, unterstützte Schnittstellen und angebotene Skills; als Bezugswege nennt sie eine standardisierte Adresse (`https://{domain}/.well-known/agent-card.json`), daneben Kataloge oder eine feste Konfiguration. WorkKit veröffentlicht eine solche A2A-1.0-Agent-Card für seine Missionsdomäne. Das folgende fiktive Publishing-Beispiel ist auf die hier benötigten Felder reduziert und beansprucht keine vollständige A2A-1.0-Agent-Card. ```json { "name": "Publishing Agent", "description": "Builds previews and prepares approved releases", "supportedInterfaces": [ { "url": "https://publishing.example.com/a2a", "protocolBinding": "HTTP+JSON", "protocolVersion": "1.0" } ], "version": "1.0.0", "capabilities": { "streaming": true, "pushNotifications": true, "extendedAgentCard": true }, "defaultInputModes": ["text/plain", "application/json"], "defaultOutputModes": ["text/markdown", "application/json"], "skills": [ { "id": "prepare-publication", "name": "Prepare publication", "description": "Creates a preview from approved knowledge", "tags": ["publishing", "preview", "content"] } ] } ``` Die Agent Card ist mit einer öffentlichen Leistungsbeschreibung vergleichbar. Dass dort ein Skill aufgeführt ist, erlaubt noch keinen Aufruf. Anmeldung und Autorisierung bleiben eigene Sicherheitsentscheidungen: Der Server muss bei jedem Auftrag prüfen, wer anfragt und was dieser Auftraggeber tun darf. Eine öffentliche Agent Card sollte außerdem keine internen Fähigkeiten oder vertraulichen Endpunkte verraten. ## Message, Part, Task und Artifact Message, Part, Task und Artifact bezeichnen unterschiedliche Bausteine eines Auftrags. | Begriff | Bedeutung | Beispiel bei delegierter Arbeit | | --- | --- | --- | | Message | Ein Gesprächsbeitrag des Benutzers oder Agenten | „Analysiere diese Abhängigkeit und schlage eine Änderung vor.“ | | Part | Ein Bestandteil einer Message oder eines Artifacts | Anweisung als Text, eine Datei oder strukturierte Daten | | Task | Eine zustandsbehaftete Arbeitseinheit mit eindeutiger ID | Der Auftrag wartet auf eine Rückfrage oder arbeitet weiter | | Artifact | Ein vom Agenten erzeugtes Ergebnis | Analysebericht, vorbereitete Änderung, Vorschau-URL | Eine Message kann sofort mit einer anderen Message beantwortet werden. Das passt zu einer kurzen Unterhaltung ohne dauerhaften Arbeitszustand. Muss die Arbeit weiterlaufen oder über mehrere Gesprächsrunden erhalten bleiben, antwortet der entfernte Agent mit einem Task. Der Task ist mehr als eine technische Anfrage-ID. Er hält den Zustand einer fachlichen Arbeitseinheit. Der Client kann ihn später lesen, auf eine Rückfrage antworten oder eine Stornierung anfordern. Nach der Spezifikation können mehrere Messages über eine `contextId` zu demselben Gesprächszusammenhang gehören; eine `taskId` bezeichnet die konkrete Arbeit. Ein vereinfachtes, nicht normatives Beispiel: ```http POST /message:send HTTP/1.1 Host: agents.example.com Authorization: Bearer Content-Type: application/a2a+json A2A-Version: 1.0 { "message": { "role": "ROLE_USER", "messageId": "msg-123", "parts": [ { "text": "Prepare a limited change proposal. Do not merge it." }, { "data": { "repository": "product-service", "scope": ["dependency-upgrade"] }, "mediaType": "application/json" } ] } } ``` Die Parts trennen unterschiedliche Inhalte innerhalb derselben Nachricht: Text trägt eine Anweisung, eine Datei übergibt ein Dokument, strukturierte Daten erlauben ein vereinbartes Schema ohne erneutes Auslesen aus Prosa. Der Empfänger muss Medientyp, Größe, Herkunft und Berechtigung jedes Inhalts prüfen. Artifacts sind die Arbeitsergebnisse, nicht bloß Gesprächsbeiträge. Laut Spezifikation kann ein Task mehrere Artifacts liefern, und ein Artifact kann während eines Datenstroms schrittweise ergänzt werden. Der Client sollte deshalb Artifact-ID und Task-ID speichern, statt nur den letzten sichtbaren Text zu kopieren. Eine typische erste Antwort sieht so aus – der Server hat angenommen, aber noch nicht abgeschlossen: ```json { "task": { "id": "task-456", "contextId": "context-789", "status": { "state": "TASK_STATE_WORKING", "timestamp": "2026-08-07T10:05:00Z" }, "artifacts": [] } } ``` ## Der Lebenszyklus macht längere Arbeit sichtbar A2A ist auf asynchrone Aufgaben ausgelegt. Ein Server kann sofort einen Task zurückgeben und im Hintergrund weiterarbeiten. Für Aktualisierungen sieht die Spezifikation drei Zustellwege vor: Abfragen, einen fortlaufenden Datenstrom oder Push Notifications. ```mermaid stateDiagram-v2 [*] --> SUBMITTED SUBMITTED --> WORKING WORKING --> INPUT_REQUIRED: Rückfrage INPUT_REQUIRED --> WORKING: weitere Message WORKING --> AUTH_REQUIRED: zusätzliche Freigabe AUTH_REQUIRED --> WORKING: Berechtigung erteilt WORKING --> COMPLETED WORKING --> FAILED SUBMITTED --> REJECTED WORKING --> CANCELED COMPLETED --> [*] FAILED --> [*] REJECTED --> [*] CANCELED --> [*] ``` Das Diagramm vereinfacht den in der Spezifikation von Version 1.0 definierten Zustandsraum. `INPUT_REQUIRED` bedeutet, dass der Agent weitere fachliche Angaben braucht. `AUTH_REQUIRED` signalisiert eine während des Auftrags nötige Autorisierung; Zugangsdaten gehören dabei nicht als Klartext in eine Message, sondern laufen über einen getrennten, zuvor vereinbarten Weg. Als Endzustände definiert die Spezifikation `COMPLETED`, `FAILED`, `CANCELED` und `REJECTED`. Ein Client darf einen Endzustand nicht durch blindes Wiederholen wiederbeleben, sondern muss bewusst einen neuen Task anlegen. Polling, Streaming und Push lösen dasselbe Zustellungsproblem auf unterschiedliche Weise. Beim Polling fragt der Client in sinnvollen Abständen nach dem Task – einfach, bei langen Pausen aber verschwenderisch. Beim Streaming bleibt eine Verbindung offen und der Server sendet Status- und Artifact-Updates als Ereignisse; nach einer Unterbrechung muss der Client den gespeicherten Task erneut lesen, denn ein Datenstrom ist kein Archiv. Push Notifications ersparen die dauerhafte Verbindung, verlangen dafür einen abgesicherten HTTP-Endpunkt beim Client, inklusive Authentifizierung, Schutz vor internen Zieladressen und Behandlung mehrfacher Zustellungen. ## Delegation erzeugt keine neue Berechtigung A2A nimmt einem System keine Sicherheitsentscheidung ab. Ein aufrufender Agent sollte einer gefundenen Agent Card nicht allein deshalb vertrauen, weil sie formal korrekt ist. Vor einem Auftrag muss feststehen, welchem Anbieter das eigene System vertraut, welche Daten es verlassen dürfen und welche Wirkung der entfernte Agent auslösen kann. Der A2A-Server steht in derselben Pflicht: Er muss bei jedem Auftrag prüfen, wer anfragt und was dieser Auftraggeber tun darf, und Nachrichten als nicht vertrauenswürdige Eingaben behandeln. Der wichtigste Grundsatz dahinter: Delegation darf keine neue Berechtigung erzeugen. Wer einen Auftrag übermittelt, darf dadurch nicht mehr Rechte im Zielsystem erhalten, und der ausführende Agent darf nicht stillschweigend die Rechte seines Auftraggebers erben. Der Auftrag bleibt begrenzt. WorkKit macht diese Begrenzung explizit: Eine delegierte Mission ist an die aktive, menschlich freigegebene Assignment-Revision gebunden. Was diese Revision nicht erlaubt, kann auch ein technisch korrekter A2A-Aufruf nicht auslösen. Ein menschlicher Freigabeschritt bleibt damit eine fachliche Entscheidung im Zielsystem – ein Agent darf eine Freigabe nicht aus einer freundlichen Formulierung in einer Message ableiten. ## MCP, A2A und Cockpit sind verschiedene Zugänge, keine Etiketten MCP stellt einer Agentenanwendung Werkzeuge und Kontext bereit; die Verantwortung für die offene Aufgabe bleibt in der Anwendung. A2A verbindet eigenständige Agentensysteme: Der Auftraggeber übergibt ein Ziel, der entfernte Agent verantwortet die Ausführung und führt einen eigenen Task-Lebenszyklus. MCP und A2A modellieren damit unterschiedliche Verantwortlichkeiten und Lebenszyklen. | Frage | MCP | A2A | | --- | --- | --- | | Gegenüber | Fähigkeitsserver | Eigenständiges Agentensystem | | Auffindbare Beschreibung | Werkzeuge und Kontextquellen | Agent Card mit Skills und Schnittstellen | | Typische Arbeit | Werkzeug auswählen und aufrufen | Ziel oder Teilaufgabe delegieren | | Länger laufender Zustand | Durch die Anwendung modelliert | Task-Lebenszyklus ist Protokollkonzept | | Ergebnis | Tool-Ergebnis oder Resource | Message oder ein oder mehrere Artifacts | | Interne Umsetzung | Fähigkeit mit definiertem Schema | Entfernter Agent bleibt intern eigenständig | Dazu kommt das Web-Cockpit als Zugang für Menschen; beide Produkte besitzen eines. Diese Zugänge haben unterschiedliche Aufgaben, und ein System kann mehrere davon anbieten, ohne dass daraus mehrere Fachmodelle werden. CodeKit zeigt das konkret. Es bietet über A2A 1.0 begrenzte Analyse- und Änderungsaufträge an, und REST, MCP, A2A und Cockpit lesen denselben strukturierten Task- und Ergebnisdatensatz. ## Was WorkKit und CodeKit heute anbieten WorkKit veröffentlicht eine A2A-1.0-Agent-Card und bildet die Operationen `SendMessage`, `GetTask`, `ListTasks` und `CancelTask` auf endliche Missionsaufträge ab. Ein fremdes Agentensystem kann also eine Mission anstoßen, ihren Zustand verfolgen und sie abbrechen – innerhalb der Grenzen, die die aktive, menschlich freigegebene Assignment-Revision setzt. Auf der Gegenseite normalisiert WorkKit verbundene Systeme hinter denselben Operationen für Entdeckung, Aufruf, Status, Abbruch und Belege, während die konkrete Übertragung über OpenAPI, MCP oder A2A erfolgt. CodeKit nimmt begrenzte Analyse- und Änderungsaufträge über A2A 1.0 an. Der Auftraggeber übermittelt ein begrenztes Ziel; wie CodeKit intern arbeitet, bleibt seine Sache. Sichtbar wird der strukturierte Task- und Ergebnisdatensatz, den REST, MCP, A2A und das Cockpit gemeinsam lesen. Beide Produkte zeigen in diesen Repository-Ständen, wofür A2A gedacht ist: Ein eigenständig betriebenes System nimmt einen begrenzten Auftrag an und macht dessen Zustand und Ergebnis nachverfolgbar. Bei WorkKit begrenzt zusätzlich die aktive, menschlich freigegebene Assignment-Revision die Autorität eines Auftrags. ## Wann A2A sinnvoll ist A2A lohnt sich, wenn mehrere Bedingungen gleichzeitig zutreffen: Die beteiligten Agenten werden unabhängig entwickelt oder betrieben. Die Arbeit dauert möglicherweise länger als eine einzelne Anfrage, benötigt Rückfragen oder erzeugt mehrere Ergebnisse. Der Auftraggeber legt Ziel und zulässige Wirkung fest, der entfernte Agent verantwortet die interne Ausführung. Für eine bekannte Folge fester Schritte ist ein deterministischer Workflow meist einfacher. Bloß verschiedene Rollennamen, mehrere Sprachmodelle oder getrennte Prompts rechtfertigen noch keine verteilte Agentenarchitektur – sie erzeugen nur eine zusätzliche Netzgrenze ohne zusätzliche Verantwortungsgrenze. Die Entscheidung lässt sich daran festmachen, wer die Verantwortung für die offene Aufgabe trägt. Bleibt sie in der eigenen Anwendung und benötigt sie lediglich Werkzeuge oder Kontext, kann MCP genügen. Übernimmt ein unabhängiges System einen begrenzten Auftrag mit eigenem Task-Lebenszyklus, ist A2A der passende Vertrag. Wer diese Ebenen auseinanderhält, baut keine unnötigen Agenten – und erkennt an WorkKit und CodeKit, welche Merkmale die hier beschriebene Delegation besitzt: eine Agent Card, ein authentifizierter Aufruf, ein nachverfolgbarer Task und ein begrenzter Auftrag. ## Weiterführende Quellen - [A2A Protocol Specification 1.0](https://a2a-protocol.org/latest/specification/) - [A2A: Core Concepts](https://a2a-protocol.org/latest/topics/key-concepts/) - [A2A: Life of a Task](https://a2a-protocol.org/latest/topics/life-of-a-task/) - [A2A und MCP im Vergleich](https://a2a-protocol.org/latest/topics/a2a-and-mcp/) - [Model Context Protocol: Architektur](https://modelcontextprotocol.io/docs/learn/architecture) - [WorkKit: A2A-Oberfläche am geprüften Stand](https://github.com/MikeBild/workkit/blob/788e460670c427c4d391c898ac29e33ec1c49eb5/docs/developers/03-a2a.md) - [WorkKit: Verbundene Systeme am geprüften Stand](https://github.com/MikeBild/workkit/blob/788e460670c427c4d391c898ac29e33ec1c49eb5/docs/concepts/05-connected-systems.md) - [CodeKit: A2A-Oberfläche am geprüften Stand](https://github.com/MikeBild/codekit/blob/386248e32d6fe354bb57bca0ac118254f6ad005e/docs/developers/04-a2a.md) - [MCP, HTTP, Webhooks und A2A einfach erklärt](https://www.mikebild.dev/de/blog/mcp-http-webhooks-a2a-einfach-erklaert/)