Was bedeutet „Agent Descriptor Files“?

Agent Descriptor Files sind maschinenlesbare Beschreibungsdateien für KI-Agenten oder für Schnittstellen, die KI-Agenten nutzen sollen. Der Begriff bezeichnet hier kein einheitliches Dateiformat und keinen universell unterstützten Standard. Eine solche Datei kann Fähigkeiten, Endpunkte und Anforderungen an die Authentifizierung beschreiben. Die Veröffentlichung garantiert weder automatische Auffindbarkeit durch KI-Systeme noch Zugriff auf Deine Systeme.

Eine einzelne Datei heißt hier Agent Descriptor File oder Agent-Beschreibungsdatei. Die Kurzbezeichnung ADF verwenden wir ausschließlich in diesem Sinn; in anderen Fachgebieten kann die Abkürzung andere Bedeutungen haben.

Agent Descriptor Files: zwei unterschiedliche Aufgaben

Bevor Du eine Agent-Beschreibungsdatei einplanst, kläre, was die Datei beschreiben soll. Zwei Aufgaben sind zu unterscheiden:

• Einen Agenten beschreiben: Welche Aufgaben übernimmt der Agent? Welche Fähigkeiten bietet der Agent an? Über welches Protokoll kannst Du den Agenten ansprechen?
• Eine Schnittstelle beschreiben: Welche Funktionen stellt Dein Unternehmen bereit? Welche Eingaben erwartet die Schnittstelle? Welche Antworten liefert die Schnittstelle?

Ein Agent, der Anfragen bearbeitet, ist nicht dasselbe wie eine APIEine API einfach erklärt: Eine API ist eine standardisierte Programmierschnittstelle, über die zwei Softwaresysteme Daten oder Funktionen austauschen. Die Langform Application Programming Interface beschreibt... Klicken und mehr erfahren, die verfügbare Termine zurückgibt. Beide können eine maschinenlesbare Beschreibung benötigen, aber nicht zwingend dasselbe Format.

Für Dich als KMU-Entscheider lautet die erste Frage deshalb: Welchen betrieblichen Vorgang möchtest Du kontrolliert zugänglich machen? Erst danach lässt sich entscheiden, welche Beschreibung erforderlich ist.

Welche Angaben enthalten Agent Descriptor Files?

Agent Descriptor Files machen technische Eigenschaften strukturiert auswertbar. Welche Angaben erforderlich sind und wie die Felder heißen, bestimmt die jeweilige Spezifikation. Für Agentenkommunikation kann ein protokollspezifisches Format erforderlich sein; API-Beschreibungen folgen einer eigenen Spezifikation.

• Identität: Name, Beschreibung und gegebenenfalls verantwortlicher Anbieter.
• Fähigkeiten: Angebotene Aufgaben oder Funktionen mit klaren Grenzen.
• Endpunkte: Technische Adressen für die Kommunikation mit dem Agenten oder der Schnittstelle.
• Protokolle: Vereinbarte Regeln für Anfragen und Antworten.
• Versionen: Angaben zum Beschreibungsformat und zur angebotenen Schnittstelle.
• Authentifizierungsanforderungen: Angaben dazu, wie ein aufrufender Client seine Identität nachweisen muss.

Eine Beschreibung kann einem kompatiblen Client helfen, eine Integration vorzubereiten. Verständliche Feldnamen allein schaffen jedoch keine Interoperabilität. Der Client muss das konkrete Schema und das zugehörige Protokoll unterstützen.

Schematisches JSON-Beispiel

Das folgende Beispiel veranschaulicht nur die Grundidee. Das JSON entspricht weder einer A2A-Agent-Card noch einer OpenAPI-Beschreibung und ist keine Vorlage für eine produktive Integration. Der Endpunkt ist fiktiv; Zugangsdaten sind nicht enthalten.

{
  "name": "Termin-Auskunft",
  "description": "Gibt verfügbare Zeitfenster zurück.",
  "version": "1.0",
  "capabilities": [
    {
      "name": "Zeitfenster lesen",
      "readOnly": true
    }
  ],
  "endpoint": "https://example.com/api/availability",
  "authentication": {
    "required": true,
    "scheme": "Bearer"
  }
}

Der Eintrag „Bearer“ beschreibt lediglich eine Anforderung. Der Server muss das übermittelte Token prüfen und entscheiden, welche Daten der Client lesen darf. Auch die Angabe „readOnly“ ersetzt keine serverseitige Zugriffskontrolle.

Agent Descriptor Files und konkrete Formate: die Unterschiede

Agent Card, OpenAPI und AI-Plugin-Manifest sind keine austauschbaren Namen für dieselbe Datei. Für eine Umsetzung zählen die konkrete Spezifikationsversion und die dokumentierte Unterstützung durch den vorgesehenen Client. Die folgenden Erläuterungen beschreiben die Aufgaben der Formate, nicht eine getestete Produktkompatibilität.

Agent Card im A2A-Protokoll

Die Agent Card beschreibt einen Agenten im A2A-Protokoll für die Kommunikation zwischen Agenten. Eine Agent Card ist keine allgemeine Beschreibung einer Unternehmenswebsite.

• Spezifikation: Prüfe die verwendete A2A-Version und die vorgeschriebenen Angaben.
• Kompatibilität: Beide beteiligten Systeme müssen die benötigte Protokollversion und deren Funktionen unterstützen.
• Auffindbarkeit: Eine veröffentlichte Agent Card bedeutet nicht, dass jeder Assistent den Agenten automatisch findet oder nutzen kann.

OpenAPI für Schnittstellen

OpenAPI beschreibt HTTP-APIs. Im Mittelpunkt stehen Schnittstellenoperationen, Eingaben, Antworten und Sicherheitsanforderungen – nicht die Identität eines eigenständig handelnden Agenten.

• Dokumentation: Menschen und geeignete Werkzeuge können die beschriebenen Operationen nachvollziehen.
• Versionsunterstützung: Prüfe, welche OpenAPI-Version und Funktionen das Integrationswerkzeug unterstützt.
• Agentennutzung: Der Client benötigt einen vorgesehenen Integrationsweg. Die Veröffentlichung einer API-Beschreibung stellt diese Verbindung nicht automatisch her.

Wenn Du Unternehmensleistungen über eine Schnittstelle zugänglich machen möchtest, erläutert der Beitrag OpenAPI für betriebliche Services den Weg vom Prozess zur API.

AI-Plugin-Manifest

Ein AI-Plugin-Manifest beschreibt eine Integration. Eine zugehörige API-Beschreibung dokumentiert die Schnittstelle, die diese Integration verwenden kann. Manifest, Agent Card und API-Beschreibung erfüllen unterschiedliche Aufgaben.

• Historische Anleitungen: Übertrage frühere Plugin-Unterstützung nicht ungeprüft auf heutige Assistenten.
• Produktstatus: Prüfe Herausgeber, Dokumentationsdatum und den aktuell vorgesehenen Integrationsweg.
• Erkennung: Ein vorhandenes Manifest oder ein bekannter Dateiname belegt keine automatische Unterstützung.

Agent Descriptor Files: Beschreibung ist keine Berechtigung

Agent Descriptor Files beschreiben Fähigkeiten und Schnittstellen. Die Dateien erteilen keine Zugriffsrechte.

Authentifizierung prüft, wer aufruft. Autorisierung entscheidet, was der Aufrufer tun darf. Eine öffentliche Beschreibung darf diese Anforderungen erläutern, aber keine geheimen Schlüssel oder Zugangstoken enthalten.

Wenn ein Agent Termine reservieren, Bestellungen auslösen oder Kundendaten verändern soll, brauchst Du zusätzliche Kontrollen:

• Berechtigungen: Welche Aktionen darf der aufrufende Client ausführen?
• Bestätigungen: Welche Aktionen benötigen eine menschliche Freigabe?
• Protokollierung: Wie werden ausgeführte Aktionen und Änderungen nachvollziehbar dokumentiert?

Diese Kontrollen müssen in der ausführenden Anwendung beziehungsweise serverseitig umgesetzt werden. Eine Beschreibungsdatei ersetzt keine Zugriffskontrolle.

Agent Descriptor Files, Website-Inhalte und Schnittstellen abgrenzen

• llms.txt: Eine vorgeschlagene Orientierungsdatei für InhalteContent umfasst alle gezielt veröffentlichten digitalen Inhalte auf Websites, in Shops, in Social-Media-Kanälen, in Newslettern und in anderen digitalen Umgebungen. Wenn Du wissen willst,... Klicken und mehr erfahren. Die Datei kann auf relevante Informationen verweisen, stellt aber selbst keine ausführbare Schnittstelle bereit.
• Strukturierte Daten: Beschreibendes Markup für Website-Informationen, etwa zu einem Unternehmen oder Angebot. Markup führt keine Aktionen aus.
• OpenAPI: Eine Beschreibung einer HTTP-API. Die Funktionen müssen durch eine implementierte Schnittstelle bereitgestellt werden.
• Agent-Beschreibungsdatei: Die hier verwendete Sammelbezeichnung. Für eine Integration brauchst Du ein konkretes, vom Client unterstütztes Format.

Auffindbarkeit, technische Ansprechbarkeit und Berechtigung sind drei verschiedene Eigenschaften. Ein Client kann eine Beschreibung finden, ohne das Protokoll zu unterstützen. Ein kompatibler Client kann einen Endpunkt ansprechen, ohne Zugriff auf geschützte Daten zu erhalten.

Unser Architekturansatz bei Berger+Team

Bei Berger+Team, meinem Freelancer-Kollektiv in Bozen, betrachten wir Markeninformationen, Website-Inhalte und technische Services als zusammenhängendes System mit getrennten Aufgaben. btlabs Core bezeichnet in diesem Architekturansatz unser digitales Fundament mit einer zentralen Inhaltsbasis. btlabs Core ist kein ADF-Standard und kein Nachweis universeller Agentenunterstützung.

Agent Descriptor Files sind dabei von anderen Bausteinen zu unterscheiden:

• Identitätsdateien: Beschreiben Unternehmens- und Markeninformationen.
• Inhaltsverzeichnisse: Geben Orientierung über freigegebene Inhalte.
• OpenAPI-Beschreibung: Dokumentiert die dafür vorgesehenen HTTP-Schnittstellen.
• Tools-Endpunkt: Bietet einen Zugang zu den implementierten Funktionen; Zugriff und Freigaben werden gesondert geregelt.

Diese Trennung beschreibt eine Architekturentscheidung, keine bestätigte Kompatibilität mit einem bestimmten Assistenten. Die zentrale Datenbasis erläutern wir im Beitrag strukturiertes Firmenwissen mit btlabs Core.

Buchende KI-Agenten sind eine mögliche Ausbaustufe, keine zugesicherte Standardfunktion. Für Reservierungen oder Bestellungen müssen Prozess, Schnittstelle, Client-Unterstützung und Freigaberegeln konkret umgesetzt und getestet werden.

Welche Lösung braucht Dein Unternehmen?

Aus meiner über 20-jährigen Praxis in BrandingBranding ist der bewusste, strategische Aufbau einer Marke. Branding bestimmt, wie Dein Unternehmen wahrgenommen wird, woran Menschen es erkennen und warum sie ihm Vertrauen... Klicken und mehr erfahren, Webentwicklung und Digitalstrategie ist meine Priorität klar: Erst den betrieblichen Nutzen klären, dann die technische Beschreibung auswählen. In der Arbeit mit KMU ist für mich entscheidend, dass zusätzliche Technik einen nachvollziehbaren Anwendungsfall unterstützt. Agent Descriptor Files sind kein Selbstzweck.

• Du möchtest informieren: Priorisiere verlässliche Inhalte, klare Leistungen, aktuelle Kontaktdaten und eine zugängliche Website. Eine Agent-Beschreibungsdatei ist dafür nicht automatisch erforderlich.
• Du möchtest Daten oder Funktionen bereitstellen: Plane eine dokumentierte API mit passenden Zugriffsregeln und einem konkret vorgesehenen Client.
• Du möchtest Agenten verbinden: Prüfe ein geeignetes Protokoll und dessen Unterstützung auf beiden Seiten.
• Du möchtest Aktionen ermöglichen: Definiere zusätzlich Berechtigungen, Bestätigungen und nachvollziehbare Abläufe.

Die Vorbereitung einer Website behandeln wir unter Agent-Readiness für die Nutzung durch KI-Agenten. Die geschäftliche Ausrichtung auf solche Nutzer beschreibt B2A, also Business to Agent.

Prüfliste für Agent Descriptor Files

• Ziel festlegen: Soll der Client Informationen lesen, einen Agenten kontaktieren oder eine Funktion ausführen?
• Format wählen: Nutze die Spezifikation, die der konkrete Integrationsweg verlangt.
• Unterstützung dokumentieren: Halte Client, Version, unterstützte Funktionen und Prüfdatum fest.
• Beschreibung validieren: Prüfe Schema, Pflichtfelder und Übereinstimmung mit der tatsächlichen Schnittstelle.
• Sicherheit testen: Prüfe fehlende, ungültige und unzureichend berechtigte Zugangstoken sowie Freigaben für schreibende Aktionen.
• Änderungen versionieren: Aktualisiere Beschreibung, Schnittstelle und Tests gemeinsam.

Häufige Fragen zu Agent Descriptor Files

Gibt es einen verbindlichen ADF-Standard?

Agent Descriptor Files sind in diesem Beitrag eine Sammelbezeichnung; ADF bezeichnet hier kein verbindliches Dateiformat. Für Deine Umsetzung brauchst Du eine konkrete Spezifikation, deren Version und einen Client, der das Format unterstützt.

Welche Datei braucht meine Website?

Das hängt vom Zweck ab: Für Informationen stehen gute Inhalte im Vordergrund, für API-Nutzung eine dokumentierte Schnittstelle und für Agentenkommunikation ein passendes Protokoll. Kläre zuerst, welcher Client die Datei wofür verwenden soll.

Lesen ChatGPT und andere Assistenten solche Dateien automatisch?

Setze automatische Erkennung nicht voraus. Verlange für den vorgesehenen Assistenten einen dokumentierten Integrationsweg und einen reproduzierbaren Test. Die Existenz einer Datei belegt keine Unterstützung.

Ersetzt eine Agent-Beschreibungsdatei eine API?

Nein. Eine Beschreibung implementiert keine Funktion. Wenn Dein Agent aktuelle Daten abrufen oder einen Vorgang auslösen soll, brauchst Du eine erreichbare und entsprechend abgesicherte Schnittstelle.

Darf ein Agent durch die Beschreibung Aktionen ausführen?

Nein. Die Beschreibung erteilt keine Berechtigung. Dein Server muss Identität, Zugriffsrechte und gegebenenfalls eine zusätzliche Freigabe prüfen, bevor eine Aktion ausgeführt wird.

Wie prüfe ich Kompatibilität und Aktualität?

Halte Formatversion, Clientversion und Testdatum fest und prüfe die Integration gegen die zugehörige Dokumentation. Wiederhole Tests bei Änderungen an Fähigkeiten, Endpunkten oder Sicherheitsanforderungen, damit Beschreibung und tatsächliches Verhalten übereinstimmen.