Agent Cards: Wie sich Agenten gegenseitig finden (A2A Discovery)

Eine Agent Card ist ein maschinenlesbares JSON-Dokument im A2A-Protokoll, mit dem ein KI-Agent seine Identität, seinen Endpoint, seine Skills, Capabilities, Modalitäten und Authentifizierungsschemata veröffentlicht. Andere Agenten lesen diese Karte aus, um zu entscheiden, ob und wie sie den Agenten beauftragen. Damit ist die Agent Card der zentrale Mechanismus, über den Agenten einander finden, ohne dass jemand sie vorher fest miteinander verdrahtet.

• Was sie ist: das öffentliche Profil eines Agenten, Visitenkarte und Schnittstellenbeschreibung in einem.
• Wozu sie dient: Agent Discovery. Ein Client-Agent prüft Skills, Modalitäten und Auth, bevor er einen Auftrag (Task) stellt.
• Warum sie zählt: ohne Agent Card ist ein Agent für andere Systeme unsichtbar und nur über Custom-Integration erreichbar.

A2A, MCP und die Rolle der Agent Card

Im Protokoll-Stack 2026 haben sich zwei offene Standards durchgesetzt. Das von Anthropic entwickelte Model Context Protocol (MCP) regelt den Zugriff von Agenten auf Tools und Daten, also Agent-zu-Tool. Seit Dezember 2025 liegt MCP bei der Agentic AI Foundation unter dem Dach der Linux Foundation. Das Agent2Agent-Protokoll (A2A) regelt die Zusammenarbeit zwischen Agenten, also Agent-zu-Agent. Die A2A-Dokumentation grenzt beide so ab: Über MCP nutzt ein Agent Fähigkeiten wie Tools und Ressourcen, über A2A arbeiten Agenten als Partner an einer Aufgabe. Die beiden Protokolle ergänzen sich.

Die Agent Card ist der Capability-Discovery-Baustein von A2A. Wo ein MCP-Server einzelne Werkzeuge beschreibt, beschreibt eine Agent Card einen ganzen Agenten als potenziellen Kollaborationspartner. A2A wurde im April 2025 auf der Google Cloud Next vorgestellt und am 23. Juni 2025 an die Linux Foundation übergeben, mit AWS, Cisco, Google, Microsoft, Salesforce, SAP und ServiceNow als Gründungsmitgliedern. Über 100 Unternehmen unterstützen das Protokoll inzwischen (Stand 2026).

Aufbau einer Agent Card

Eine Agent Card ist ein JSON-Dokument, das ein Agent unter einem bekannten Pfad seines Hosts veröffentlicht. Sie enthält die folgenden Kernbestandteile:

Entscheidend ist das Designprinzip dahinter: A2A definiert, wie Agenten miteinander sprechen, nicht wie sie denken. Der interne Aufbau eines Remote-Agenten, also seine Prompts, sein Modell und sein Memory, bleibt bewusst opak. Genau das erlaubt es, dass ein Salesforce-Agent einen SAP-Agenten aufruft, ohne dass eine Seite ihre Prompts, ihr Modell oder ihre Daten offenlegt. Die Card ist der einzige Vertrag, den beide Seiten teilen.

Der Discovery-Mechanismus

Discovery über Agent Cards läuft in zwei typischen Ausprägungen.

Direkte Discovery (Punkt-zu-Punkt). Ein Client-Agent kennt die Basis-URL eines Remote-Agenten und ruft dessen Agent Card ab. Er prüft, ob die ausgeschriebenen Skills zur Aufgabe passen, ob die nötige Modalität unterstützt wird und ob er das Authentifizierungsschema bedienen kann. Erst dann öffnet er einen Task.

Verzeichnisbasierte Discovery (Registry). In größeren Estates werden Agent Cards zentral registriert. Das von Cisco gestartete Open-Source-Projekt AGNTCY stellt dafür ein Agent Directory bereit: eine föderierte Registry, in der sich A2A-Agenten und MCP-Server veröffentlichen, verifizieren und finden lassen. Skills und Attribute beschreibt es mit dem Open Agentic Schema Framework (OASF). Damit findet ein Agent passende Partner über ein Verzeichnis statt über fest verdrahtete Adressen. SAP bündelt eine vergleichbare Funktion im SAP AI Agent Hub in SAP LeanIX. Der Hub ist als herstellerunabhängige Steuerzentrale angelegt, über die Unternehmen SAP- und Fremd-Agenten sowie MCP-Server finden, inventarisieren und steuern. Im Oktober 2026 bezeichnet SAP den Hub als allgemein verfügbar.

Sobald ein Partner gefunden ist, übernimmt der A2A-Task-Lebenszyklus. Laut A2A-Spezifikation durchläuft ein Task die Zustände submitted und working, pausiert bei Rückfragen in input-required oder bei nötiger zusätzlicher Authentifizierung in auth-required und endet in completed, failed, canceled oder rejected. Im JSON der Spezifikation 1.0 heißen diese Zustände TASK_STATE_SUBMITTED, TASK_STATE_WORKING, TASK_STATE_INPUT_REQUIRED und so weiter. Der Transport läuft über JSON-RPC 2.0 und HTTPS, die Spezifikation definiert zusätzlich Bindings für gRPC und HTTP+JSON. Zwischenstände werden über Server-Sent Events gestreamt, für lange Läufe gibt es optionale Push-Benachrichtigungen. Das Ergebnis eines Tasks kommt als ein oder mehrere Artifacts zurück, Nachrichten können mehrteilig und multimodal sein.

Forschungsseitig zeigt das MIT-Media-Lab-Projekt NANDA, wohin Discovery langfristig gehen könnte: ein dezentraler Agent-Index mit kryptografisch verifizierbaren AgentFacts und Zero Trust Agentic Access. Das ist Stand 2026 jedoch research-grade und keine Grundlage für Produktionsentscheidungen.

Beispiel: Discovery zwischen zwei Agenten

Angenommen, ein CRM-Agent in Salesforce soll eingehende Lieferanten-Rechnungen vorprüfen lassen und dafür einen spezialisierten Rechnungs-Agenten einer Agentur beauftragen.

Die Agent Card des Rechnungs-Agenten, gekürzt und mit den Feldnamen der A2A-Spezifikation 1.0:

• "name": "Invoice-Triage-Agent", "version": "2.0.0"
• "supportedInterfaces": [{ "url": "https://agents.example.com/a2a", "protocolBinding": "JSONRPC", "protocolVersion": "1.0" }]
• "capabilities": { "streaming": true, "pushNotifications": true }
• "defaultInputModes": ["text/plain", "application/pdf"], "defaultOutputModes": ["application/json"]
• "securitySchemes": { "oauth": { "oauth2SecurityScheme": { "flows": { … } } } }
• "skills": [{ "id": "klassifiziere_rechnung", "name": "Rechnung klassifizieren", "description": "Liefert Kategorie und Konfidenz (0 bis 1)", "tags": ["rechnung"] }]

Der Ablauf:

1. Der CRM-Agent ruft die Card ab: GET https://agents.example.com/.well-known/agent-card.json
2. Er prüft: Der Skill passt, Eingabeformat und OAuth 2.0 werden unterstützt.
3. Er öffnet einen Task per POST https://agents.example.com/a2a, der Task startet im Zustand TASK_STATE_SUBMITTED.
4. Der Task durchläuft TASK_STATE_WORKING und endet in TASK_STATE_COMPLETED. Als Artifact kommt zurück: { "kategorie": "Wareneingang", "konfidenz": 0.94 }

Der CRM-Agent musste nichts über das interne Modell oder die Prompts des Rechnungs-Agenten wissen. Er hat allein anhand der Card entschieden, dass dieser Agent die Aufgabe erfüllen kann, und ihn dann über den standardisierten Task-Vertrag beauftragt. Genau diese Entkopplung macht herstellerübergreifende Workflows zwischen Agentforce, Joule und Copilot Studio möglich. Für Joule hat SAP im Mai 2026 angekündigt, die bidirektionalen A2A-Funktionen im vierten Quartal 2026 allgemein verfügbar zu machen.

Sicherheit und Governance

Jede neue Agenten-Verbindung ist eine neue Vertrauensgrenze und damit eine neue Angriffsfläche. Vier Risiken sind dabei besonders relevant: Trust-Boundary-Verletzungen, weil jeder A2A-Peer für die anderen opak ist; Capability-Drift, wenn eine Card mehr verspricht, als der Agent tatsächlich sicher leisten kann; Lücken im Audit-Trail, sobald Nachrichten Prozessgrenzen überschreiten; und Prompt-Injection-Verstärkung, weil jeder zusätzliche Agent-Kontext eine weitere Bypass-Gelegenheit ist. Das Risiko indirekter Prompt Injection (XPIA) wächst mit jedem Agenten, der nicht vertrauenswürdige Inhalte verarbeitet.

Praktische Konsequenzen für DACH-Deployments: scope-limitierte, kurzlebige Tokens je Task, Least-Privilege bei den in der Card ausgeschriebenen Skills, durchgängige Correlation-IDs für jeden A2A-Task, und keine proprietären Erweiterungen der Card- oder Task-Semantik, die genau die Portabilität untergraben, derentwegen man A2A wählt. Für regulierte Workflows gehört zur Reproduzierbarkeit, die verwendeten Agent Cards je Lauf zu protokollieren und Modellversionen zu pinnen.

Für Agenturen und B2B

Für Marketing- und Digitalagenturen im DACH-Raum ist das Veröffentlichen von Agent Cards der wichtigste Produkt-Hebel 2026. Nur ein Agent, der per A2A discoverable ist, lässt sich aus den Salesforce-, SAP-Joule- oder Copilot-Studio-Estates deiner Kunden direkt aufrufen, ohne dass für jeden Kunden eine eigene Integration nötig ist. Wer Agent Cards überspringt, landet dauerhaft hinter einer manuellen Integration. Unsere Empfehlung: Card-Disziplin ab Tag eins, getypte Output-Verträge (etwa via Pydantic oder JSON Schema) erzwingen und für jeden produktisierten Agenten eine Card vor dem Go-live verlangen.

Für B2B-Entscheider ist die Procurement-Frage entscheidend: Garantiert dein Agentforce-, Joule- oder Copilot-Studio-Vertrag A2A-Interoperabilität und MCP-Standardkonformität? Und sind Klauseln zur Veröffentlichung von Agent Cards sowie zum Exit enthalten? Blck Alpaca unterstützt dich dabei, Agenten A2A-konform zu konzipieren, Agent Cards sauber zu modellieren und in eine governance-fähige Discovery-Architektur einzubetten.