Veröffentlicht am
Sierra hat am 6. Oktober 2026 das Personal Agent Protocol angekündigt. Gemeinsam mit Meta und weiteren Partnern entwickelt das Unternehmen einen offenen Standard für Kontakte zwischen persönlichen KI-Agenten und Unternehmen. Die Spezifikation in Version 0.1 soll erst später im Oktober erscheinen. Die Nachricht beschreibt deshalb ein Vorhaben und dessen vorgesehenen Ablauf, keinen bereits abgeschlossenen Standard. Sierra: Ankündigung des Protokolls
Ein gemeinsamer Zugang für persönliche Agenten
Nach dem beschriebenen Konzept entdeckt ein Agent auf der Unternehmenswebsite, welche Funktionen verfügbar sind. Er beginnt anschließend eine Sitzung im Auftrag seines Nutzers. Allgemeine Auskünfte können als Gast erfolgen; für Kontozugriffe ist eine Anmeldung vorgesehen. Nutzer bestimmen, ob sie Lese- oder Schreibzugriff gewähren.
Die Sitzung soll auf OAuth aufbauen und über mehrere Kanäle hinweg bestehen bleiben. Unternehmen können ihre Website, Schnittstellen auf Basis etwa von MCP oder OpenAPI sowie einen eigenen Agenten anbieten. Sie legen fest, welche Wege und Funktionen zugänglich sind. Sierra nennt außerdem geplante Workshops und eine Referenzimplementierung. Feinere Aktionsrechte, Benachrichtigungen und Zahlungserweiterungen beschreibt der Beitrag als mögliche Weiterentwicklungen. Vorgesehener Ablauf und nächste Schritte
Der Kontext: Unternehmen erwarten agentische Kunden
Im Rückblick auf seinen Summit ordnet Sierra das Protokoll in eine breitere Produktentwicklung ein. Dort kündigt der Anbieter unter anderem das Modell Fleming an, das erkennen soll, wenn am Telefon ein anderer Agent statt eines Menschen anruft. Das Protokoll soll dagegen einen vereinbarten Zugang zu Unternehmensfunktionen schaffen. Beides zeigt die Richtung der Anbieterstrategie: Unternehmen sollen auf persönliche Agenten als Kontaktpartner reagieren können. Das sind Anbieterangaben, keine von KI-AGT gemessenen Fähigkeiten. Sierra: Summit-Rückblick vom 6. Oktober
Unsere Einordnung: Berechtigungen müssen zur Aufgabe passen
Für Händler, Reiseanbieter und Kundenservice-Teams ist vor allem die Trennung zwischen Auskunft und Änderung interessant. Ein Agent, der einen Lieferstatus abfragt, benötigt andere Befugnisse als ein Agent, der eine Lieferadresse verändert. Eine gemeinsame Verbindung allein beantwortet noch nicht, wie diese Unterschiede im konkreten Dienst durchgesetzt werden.
Als ersten Praxisschritt würden wir einen eng begrenzten Testfall vorbereiten: ausschließlich den Status einer Testbestellung lesen, anschließend eine nicht freigegebene Änderung versuchen und die Ablehnung kontrollieren. Dabei sollte sichtbar sein, für welches Kundenkonto der Agent handelt und welche Freigabe verwendet wurde. Im nächsten Schritt ließe sich prüfen, ob ein Widerruf weitere Aktionen tatsächlich beendet.
Was vor einer Einführung offenbleibt
Zum Recherchezeitpunkt lässt sich aus den Ankündigungen keine fertige Interoperabilität zwischen beliebigen Agenten und Shops ableiten. Für eine technische Bewertung bleiben die veröffentlichte Spezifikation und überprüfbare Implementierungen abzuwarten. Ein eigenes Urteil über Sicherheit oder Zuverlässigkeit erfordert Tests.
Unsere Empfehlung für interessierte Teams: zunächst die erlaubten Kundenaktionen, notwendige Daten und Zuständigkeiten dokumentieren. Änderungen mit erheblichen Folgen sollten einen nachvollziehbaren Freigabeweg erhalten. Danach lässt sich ein konkreter Entwurf gegen diese Anforderungen prüfen. Grundlagen erläutern unsere Beiträge zu Berechtigungen und Human-in-the-Loop.
Quelle: Offizielle Quelle