Welche Referenz gehört zu welchem Agenten?

Kurzfassung: Eine überprüfbare Agentenidentität zeigt, wer handelt. Sie beweist nicht, dass der Agent vergleichbare Arbeit erfolgreich erledigt hat. Wer fremde Agenten beauftragt, sollte Leistungsreferenzen dem konkreten System, seiner Konfiguration und überprüften Ergebnissen zuordnen. Sonst wird aus einer gültigen Anmeldung vorschnell ein Gütesiegel.

Ein Anbieter stellt einen Agenten vor, der Kundenanfragen selbstständig bearbeiten soll. Als Referenz nennt er tausend abgeschlossene Vorgänge. Für den Einkauf klingt das nach Betriebserfahrung. Offen bleibt jedoch, ob diese Vorgänge mit dem angebotenen Modell erledigt wurden, welche Werkzeuge beteiligt waren und wie viele Antworten Menschen korrigieren mussten. Dieses hypothetische Beschaffungsbeispiel macht eine wichtige Unterscheidung sichtbar: Die Herkunft eines Systems und seine nachgewiesene Arbeitsleistung sind zwei verschiedene Informationen. Für die Beauftragung wird erst ihre Verbindung aussagekräftig.

Herkunft lässt sich prüfen, Eignung nicht daraus ableiten

IBM beschreibt in seinem Rückblick auf die Think 2026 eine eindeutige, kryptografisch abgesicherte Identität für jeden produktiv eingesetzten Agenten. Ebenso fordert der Hersteller eine nachvollziehbare Kette vom ursprünglichen Nutzerauftrag über die Delegation bis zur Wirkung im angeschlossenen System. Gemeint ist nicht bloß ein Name im Chatfenster: Einzelne Handlungen sollen einem bestimmten maschinellen Akteur und seinem Auftrag zugeordnet werden können.

Der Bericht enthält dafür eine Bankanwendungs-Demonstration. Ein Agent handelt nach ausdrücklicher Zustimmung des angemeldeten Nutzers. Sein Zugriff ist auf einen begrenzten Umfang und eine Sitzung gebunden; der Datenbankzugang wird auf die eigenen Datensätze des Nutzers beschränkt. Das ist eine Herstellerdarstellung eines konkreten Sicherheitsansatzes, kein unabhängiger Nachweis allgemeiner Agentenzuverlässigkeit.

Die Trennung ist für die Anbieterbewertung entscheidend. Ein gültiger Identitätsnachweis kann die Aussage stützen, dass eine Anfrage von einem bestimmten System stammt. Ein dokumentiertes Mandat beschreibt, was dieses System tun durfte. Keines von beiden beantwortet, ob eine Reklamation fachlich richtig beurteilt oder ein Ersatzteil korrekt ausgewählt wurde. Authentizität, Befugnis und Leistung benötigen unterschiedliche Belege.

Ein signierter Auftrag ist kein Arbeitszeugnis

Auch Googles Beschreibung des Agent Payments Protocol, kurz AP2, vom September 2025 verdeutlicht diese Grenze. Das Protokoll sieht kryptografisch signierte Mandate als Nachweis von Nutzeranweisungen vor. Bei einem begleiteten Kauf wird zunächst die Absicht erfasst; die Zustimmung zum konkreten Warenkorb hält Artikel und Preis fest. Für einen späteren unbeaufsichtigten Kauf beschreibt Google ein vorab erteiltes Mandat mit Bedingungen wie Preisgrenze und Zeitpunkt.

Solche Belege helfen bei der Frage, welcher Kauf tatsächlich beauftragt war. Sie ersetzen keine Prüfung, ob das gekaufte Produkt den fachlichen Bedarf erfüllt. Ein Agent kann den erlaubten Preis einhalten und trotzdem das falsche Zubehör bestellen. Ebenso wenig lässt sich aus der Protokollbeschreibung eine allgemeine rechtliche Haftungsregel oder eine flächendeckende Nutzung ableiten.

Für Unternehmen folgt daraus eine Beschaffungsfrage jenseits des sicheren Zugangs: Welche nachprüfbare Arbeit gehört zu genau dem Agenten, den wir einsetzen wollen? Die Antwort sollte nicht nur Aktivitäten zählen. Zehntausend Werkzeugaufrufe sind keine zehntausend gelösten Kundenfälle. Selbst ein als abgeschlossen markierter Vorgang kann später wieder geöffnet oder außerhalb des Systems nachgebessert worden sein.

Eine brauchbare Referenz verbindet deshalb einen abgegrenzten Auftrag mit seinem tatsächlich geprüften Ergebnis. Sie benennt auch, wer dieses Ergebnis beurteilt hat und welche menschliche Unterstützung erforderlich war. Das ist eine eigene Anforderung an die Lieferantenqualifikation, keine durch AP2 zugesagte Funktion.

Der Name bleibt, die Arbeitsfähigkeit kann wechseln

Ein Agent ist für die Leistungsbewertung mehr als sein Modell. Im beispielhaften Kundendienst hängen die Ergebnisse auch von Wissensbestand, Suchfunktion, erlaubten Aktionen und Anweisungen ab. Ein erfolgreich bearbeiteter einfacher Auskunftsfall sagt wenig über die selbstständige Entscheidung bei einem Gewährleistungsstreit aus. Werden beide unter derselben Erfolgszahl zusammengefasst, verliert die Referenz ihren betrieblichen Wert.

Dasselbe gilt nach Änderungen. Eine gleichbleibende Produktbezeichnung beweist nicht, dass eine frühere Referenz dieselbe heute angebotene Konfiguration betrifft. Ein neues Modell, ein anderer Suchzugang oder zusätzliche Schreibrechte können eine neue Prüfung notwendig machen. Das bedeutet nicht, jede kleine Änderung mit einem vollständigen Neutest zu beantworten. Der Anbieter sollte aber erklären können, welche Änderung die belegte Fähigkeit berührt und welche Vergleichsfälle erneut geprüft wurden.

Daraus lässt sich ein überschaubares Referenzformat ableiten: eingesetzte Version und Konfiguration, Art der Aufgabe, Zahl und Auswahl der geprüften Fälle, Abnahmekriterium sowie Korrekturen und spätere Rücknahmen. Entscheidend ist die Zuordnung, nicht die Länge des Berichts. Eine kleine, nachvollziehbare Fallserie kann für eine enge Aufgabe hilfreicher sein als eine große unaufgeschlüsselte Gesamtzahl.

Vertrauliche Kundenakten müssen dafür nicht an jeden Interessenten weitergereicht werden. Möglich sind abgegrenzte Testfälle, anonymisierte Ergebnisbelege oder eine Einsicht durch eine vereinbarte Prüfstelle. Welcher Weg geeignet ist, hängt von Datenrechten und Schutzbedarf ab. Eine vermeintlich lückenlose Arbeitshistorie, die fremde Kundendaten offenlegt, wäre selbst ein Beschaffungsproblem.

Referenzen sollen den nächsten Auftrag begrenzen

Für einen mittelständischen Servicebetrieb wäre ein sinnvoller Einstieg beispielsweise die Prüfung von Ersatzteilanfragen ohne Bestellbefugnis. Der Anbieter zeigt nicht nur eine überzeugende Antwort, sondern ordnet sie der angebotenen Konfiguration zu. Anschließend bearbeitet dieses System eigene, repräsentative Fälle des Betriebs. Bewertet werden passende Teile, erkannte Unklarheiten und der tatsächliche Nachbearbeitungsaufwand.

Damit verändert sich die Arbeitsteilung bei der Beschaffung. Der Einkauf vergleicht nicht nur Funktionslisten, sondern die Reichweite belegter Fähigkeiten. Der Fachbereich legt fest, wann eine Anfrage wirklich gelöst ist. Die IT prüft, ob die dafür nachgewiesene Konfiguration der eingesetzten entspricht. Zusätzliche Befugnisse werden nicht aus dem Ruf des Anbieters abgeleitet, sondern gesondert bewertet.

Die drei praktischen Konsequenzen sind eng verbunden: Herkunft und Leistung getrennt nachweisen lassen, Referenzen auf vergleichbare Aufgaben und Konfigurationen beziehen und den ersten eigenen Auftrag innerhalb dieser belegten Reichweite halten. Besteht der Agent den Test für Teilevorschläge, ist damit noch keine autonome Bestellung abgenommen. Die nächste Investitionsentscheidung betrifft dann genau diese zusätzliche Fähigkeit – nicht erneut das Vertrauen in einen bekannten Produktnamen.