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 Model Context Protocol (MCP) von Anthropic regelt den Zugriff von Agenten auf Tools und Daten - also Agent-zu-Tool. Das Agent2Agent-Protokoll (A2A) regelt die Zusammenarbeit zwischen Agenten - also Agent-zu-Agent. Die offizielle Abgrenzung von Google, Salesforce und Microsoft lautet wörtlich: "MCP is for capabilities (agent-to-tool). A2A is for collaboration (agent-to-agent)." Beide sind komplementär, nicht konkurrierend.

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 - seine Prompts, sein Modell, 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. Cisco AGNTCY stellt dafür ein Agent Directory mit dem Open Agent Schema Framework (OASF) bereit, in dem A2A Agent Cards und MCP-Server-Beschreibungen als Eingabeformate registriert und durchsuchbar sind - "A2A agents and MCP servers are discoverable through AGNTCY directories". 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 (ehemals LeanIX) als vendor-agnostisches Command Centre zum Entdecken, Steuern und Bewerten von Agenten und MCP-Servern (GA Q3 2026, Stand 2026).

Sobald ein Partner gefunden ist, übernimmt der A2A-Task-Lebenszyklus. Ein Task durchläuft die Zustände submitted, working, input-required und endet in completed, failed oder canceled. Der Transport ist JSON-RPC 2.0 über HTTPS; 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.

```text

1. CRM-Agent ruft die Agent Card ab:
   GET https://agents.agentur.at/.well-known/agent-card.json
2. Antwort (gekürzt):
   {
   "name": "Invoice-Triage-Agent",
   "endpoint": "https://agents.agentur.at/a2a",
   "skills": [
   { "id": "klassifiziere_rechnung",
   "output": "kategorie + konfidenz (0-1)" }
   ],
   "capabilities": { "streaming": true, "pushNotifications": true },
   "modalities": ["text", "file"],
   "authentication": ["oauth2.1"]
   }
3. CRM-Agent prüft: Skill passt, OAuth 2.1 verfügbar -> Task öffnen
   POST /a2a -> task.state: submitted
4. Task durchläuft: submitted -> working -> completed
   Artifact 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 cross-vendor-Workflows zwischen Agentforce, Joule und Copilot Studio möglich.

Sicherheit und Governance

Jede neue Agenten-Verbindung ist eine neue Vertrauensgrenze und damit eine neue Angriffsfläche. Die Research dokumentiert mehrere relevante Risiken: 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 - die XPIA-Klasse skaliert linear mit der Zahl der Agenten, die nicht vertrauenswürdige Inhalte verarbeiten.

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 Ihrer Kunden direkt aufrufen - ohne dass für jeden Kunden eine Custom-Integration gebaut werden muss. Wer Agent Cards überspringt, landet dauerhaft hinter einer manuellen Integration. Die pragmatische Empfehlung der Research: 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 Ihr 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 Sie dabei, Agenten A2A-konform zu konzipieren, Agent Cards sauber zu modellieren und in eine governance-fähige Discovery-Architektur einzubetten.