Zusammenfassung

  • Der Chartaentwurf begrenzt Dialogkontext auf Kennungen und Lebenszykluszustand zur Korrelation von Nutzer-Agent-, Agent-Agent- und Agent-Werkzeug-Dialogen; Modellgedächtnis, abgerufene Dokumente und Prompts gehören ausdrücklich nicht dazu.
  • Eine beständige Kennung kann mehrere Schritte als einen deklarierten Interaktionsgraphen ausweisen. Sie authentisiert aber nicht jeden Teilnehmer, überträgt keine Vollmacht und belegt weder Werkzeugausführung noch Aufgabenerfolg.
  • Korrelation, Identität, Autorisierung, Herkunft, Anwendungssemantik, Aktion, Nutzerbestätigung, Widerruf und beobachtetes Ergebnis müssen getrennt erfasst und prüfbar miteinander verbunden werden.

Den Faden wiederfinden heißt nicht, den Handelnden zu bestätigen

Ein Nutzer beginnt einen Auftrag per Sprache. Ein Agent übergibt an einen anderen, ein Vermittler wechselt die Modalität, ein Werkzeug wird aufgerufen und nach einem Netzabbruch wird der Vorgang auf einem neuen Gerät fortgesetzt. Ohne stabile Korrelation drohen Wiederholungen, eine falsche Wiederaufnahme oder eine Lücke zwischen Störung und Folgeaktion. Das ist ein echtes Interoperabilitätsproblem.

Der Agentproto-Chartaentwurf 00-03 zieht eine klare Grenze. Dialogkontext besteht aus Kennungen und Lebenszykluszustand. Er enthält weder das an ein KI-Modell übergebene Gesprächsgedächtnis noch abgerufene Dokumente oder Prompts. Das geplante Protokoll würde die Weitergabe über bestehende IETF-Protokolle festlegen, aber weder MCP und A2A ersetzen noch einen neuen Transport definieren.

Die Kennung stützt damit nur eine begrenzte Aussage: Diese Ereignisse wurden demselben Dialog zugeordnet. Daraus folgt nicht, dass der letzte Agent noch die ursprüngliche Person vertreten darf, dass Vermittler alle Einschränkungen unverändert ließen oder dass eine alte Delegation bei der Wiederaufnahme noch gültig ist.

Identität und Vollmacht haben eigene Laufzeiten

Der Entwurf unterscheidet die Identität eines Agenten von der Identität des vertretenen Nutzers. Er sieht vor, Agentenrechte auf eine Teilmenge der Nutzerrechte zu begrenzen und Agentenzugriff unabhängig zu widerrufen. Diese Trennung wäre überflüssig, wenn die Dialogkennung bereits Identität und Autorität bewiese.

Ein Einkaufsagent kann eine Verhandlung von vor drei Tagen korrekt laden. Die Gegenpartei muss dennoch prüfen, welcher Agent jetzt erscheint, wen er vertritt, welche Waren und Beträge erfasst sind, wann die Vollmacht endet und ob sie widerrufen wurde. Ein fortbestehendes Gespräch erneuert keine Befugnis.

Vermittler schaffen weitere Übergänge. Sprache in Text umzuwandeln, eine Anweisung zusammenzufassen oder ein Werkzeug auszuwählen, kann ihre praktische Bedeutung verändern. Die Kennung zeigt den erklärten Weg. Sie bestätigt nicht, dass jeder Schritt Absicht, Grenzen und Zustimmung bewahrte.

Ein Dialogzustand ist kein Geschäftsergebnis

Die geplante Arbeit umfasst Einrichtung, Änderung, Beendigung und Widerruf von Weitergabebeziehungen sowie Erholung nach Ausfällen von Pfaden oder Vermittlern. Das sind Zustände des Dialogmechanismus.

Sie dürfen nicht zu allgemeinen Ergebnisbegriffen werden. eingerichtet bedeutet nicht, dass der Nutzer jede spätere Aktion genehmigt hat. beendet heißt nicht, dass eine Zahlung verbucht, ein Paket zugestellt oder eine Konfiguration angewandt wurde. widerrufen beweist nicht, dass eine Warteschlange, ein zwischengespeicherter Berechtigungsnachweis oder ein entferntes Werkzeug die alte Autorität tatsächlich ablehnt.

Auch eine erfolgreiche Werkzeugantwort kann nur die Annahme einer Anfrage anzeigen. Das Ergebnis muss dort beobachtet werden, wo der Zustand liegt: Konto, Cloud-Ressource, Netzkonfiguration, Lieferdatensatz oder anderes reales Objekt. Die letzte Dialognachricht ist Interaktionsbeleg, kein Weltzustandsattest.

Eine Belegkette statt einer allmächtigen Kennung

Der Korrelationsbeleg sollte Aussteller, Namensraum, Vorgänger, beteiligten Vermittler und Lebenszyklusübergang enthalten. Der Identitätsbeleg nennt den authentisierten Agenten und den vertretenen Nutzer. Der Delegationsbeleg hält Umfang, Bedingungen, Gültigkeit und Widerrufsreferenz fest. Herkunftsdaten sichern Anweisung und erforderliche Unterlagen. Die Anwendung definiert die Bedeutung, das Werkzeug protokolliert Operation, Ziel, Parameter und Antwort, die Nutzerbestätigung bewahrt die exakt vorgelegte Entscheidung, und ein unabhängiger Ergebnisbeleg beobachtet den externen Zustand.

Getrennte Belege müssen miteinander verknüpft bleiben. Eine folgenreiche Aktion muss auf die genaue Vollmacht und den auslösenden Dialogschritt zeigen. Fehlen die Verweise, lässt sich Ursache nicht rekonstruieren. Wird alles in eine undurchsichtige ID gepresst, entsteht eine saubere Zeitleiste, die kaum mehr als interne Konsistenz beweist.

Beständigkeit schafft außerdem ein Datenschutzrisiko. Eine stabile Kennung über Vertrauensgrenzen hinweg kann zum dienstübergreifenden Tracker werden. Zielgruppe, Rotation, getrennte Namensräume, Datenminimierung und Aufbewahrung entscheiden, ob Kontinuität dem Betrieb dient oder dauerhafte Beobachtung ermöglicht.

Noch ist es ein Vorschlag

Die IESG-Mitteilung vom 17. September sagt ausdrücklich, dass eine Arbeitsgruppe vorgeschlagen wurde, das IESG noch nicht entschieden hat und Kommentare bis 27. September erwartet werden. Im Datatracker steht Version 00-03 in externer Prüfung und auf der Tagesordnung des IESG-Telechats vom 8. Oktober. Es gibt weder eine eingesetzte WG noch einen angenommenen Entwurf, einen verabschiedeten Standard oder einen nachgewiesenen Einsatz.

Die offene Gestaltungsfrage lautet deshalb: Kontinuität interoperabel machen, ohne eine Korrelationskennung zugleich als Ausweis, Vollmacht, Ausführungsbeleg und Erfolgsmeldung erscheinen zu lassen.

Quellen

Primärquellen: IESG-Mitteilung zur WG-Prüfung, Agentproto-Chartaentwurf 00-03 und Agentproto-Gruppenseite im Datatracker.