Poppy, das Personal Agent Protocol, liegt seit Freitag, 9. Oktober, als Entwurf 0.1 vor: Persönliche KI-Agenten sollen sich bei Unternehmen ausweisen und nur mit den Rechten handeln, die Kundinnen und Kunden freigeben. Veröffentlicht hat den Entwurf Sierra, in einem Blogpost von Bret Taylor und Clay Bavor. Angestoßen wurde das Ganze laut Sierras Launch-Teaser vom Dienstag, 6. Oktober, gemeinsam von Meta und Sierra, zusammen mit Partnern aus der Industrie.

Spoiler: Nichts davon ist ausgerollt. Es gibt keinen Agenten mit „Poppy-Ausweis“ und kein Unternehmen, das den Entwurf produktiv einsetzt. Es gibt ein Dokument, eine Partnerliste und die Ankündigung, dass Referenzimplementierung und Design-Workshops folgen sollen. Das ist trotzdem spannend genug, denn die Frage dahinter betrifft alle, die ihrer Software irgendwann das Einkaufen, Umbuchen oder Reklamieren überlassen wollen.

(Kurze Namensklärung, bevor jemand fragt: nicht zu verwechseln mit der gleichnamigen Organizer-App. Ein anderes Produkt, anderer Zweck.)

Poppy und der Bote ohne Ausweis

Stellen Sie sich vor, Sie schicken einen Boten zum Schalter einer Firma. Der Bote hat keinen Ausweis, keine Vollmacht, nicht einmal einen Zettel mit Ihrem Namen. Also tut er so, als wäre er Sie: Er nimmt Ihre Zugangsdaten, setzt sich an den Besuchercomputer im Foyer und klickt sich durch Formulare, die für Menschen gebaut wurden. Die Firma sieht einen Kunden, der sich komisch benimmt. Der Bote sieht ein Labyrinth aus Buttons, Pop-ups und Cookie-Bannern.

Das ist ein Bild, kein Erlebnisbericht. Aber es trifft ziemlich genau, was Sierra als Ausgangsproblem beschreibt. Laut Sierra muss ein persönlicher Agent oft als der Kunde selbst einloggen und durch Seiten navigieren, die für Menschen gebaut sind. Unternehmen haben demnach keinen standardisierten Weg, dem Agenten zu helfen. Das begrenze, was Kundschaft, Agent und Marke direkt zusammen tun können. Im Original heißt es dazu, Unternehmen wüssten bei diesem Vorgehen nicht, wann sie es mit einem Agenten zu tun haben. Das ist meine Zusammenfassung; wörtlich schreibt Sierra, mit Poppy wüssten Firmen, „when they’re dealing with an agent and who it represents“ (sinngemäß: wann sie es mit einem Agenten zu tun haben und wen er vertritt).

Poppy will dem Boten einen Ausweis und eine Vollmacht in die Hand drücken. Der Ausweis sagt: Ich bin ein Agent, und ich handle für diese eine Person. Die Vollmacht sagt: aber nur für diese Dinge. Klingt einfach, ist es aber nicht, und genau deshalb lohnt sich der Blick in die Details.

Das Problem: Klicken auf Seiten für Menschen

Bleiben wir kurz beim Ist-Zustand, den Sierra beschreibt. Ein Agent soll etwas kaufen oder ein Problem lösen. Die Website des Händlers kennt aber nur Menschen: Login-Masken, Bestellhistorien, Rückgabeformulare mit Dropdown-Menüs. Der Agent muss sich in dieser Welt zurechtfinden, und er tut das laut Sierra oft, indem er sich als die Person einloggt, für die er arbeitet. Das Wort „oft“ steht so in der Quelle; Sierra behauptet nicht, dass es immer so läuft.

Warum ist das ein Problem? Aus Sicht der Firma sieht ein Agent, der sich als Kunde ausgibt, aus wie ein Kunde. Es gibt keine Möglichkeit, ihn anders zu behandeln: weder großzügiger noch strenger. Aus Sicht der Kundschaft hängt alles an den Zugangsdaten, und die gelten pauschal. Wer dem Agenten Zugang gibt, gibt in der Regel das ganze Konto frei, nicht nur die eine Rückgabe.

Sierra formuliert das Gegenprinzip so (meine Übersetzung): Kundinnen und Kunden entscheiden, welchen Zugriff sie ihren persönlichen Agenten geben, und Unternehmen legen fest, was diese Agenten tun dürfen. Zwei Seiten, zwei Hebel. Der Mensch bestimmt, was er abgibt. Die Firma bestimmt, was sie zulässt. Dazwischen steht ein Protokoll, das beides in eine Form bringt, die Maschinen lesen können.

Ich finde, das ist der eigentlich interessante Gedanke an dem Entwurf. Nicht der Name, nicht die Partnerliste, sondern die Umkehrung: Statt dass der Agent sich unauffällig hineinschummelt, klopft er offen an und zeigt, wer er ist.

Poppy, Teil eins und zwei: Der Ausweis an der Tür, der Gast am Tresen

Sierra beschreibt Poppy als fünf Bausteine. Die ersten beiden sind Discovery und Sessions, und sie lassen sich gut mit einem Bürogebäude vergleichen.

Discovery: das Schild neben der Klingel

Unternehmen veröffentlichen laut Sierra eine einzige Datei an einer Standardadresse auf ihrer Website: /.well-known/poppy.json. Diese Datei sagt einem Agenten, wie er mit dem Unternehmen zusammenarbeiten kann, wie sich Kundschaft anmelden kann und was der Agent tun darf. Man kann sich das wie das Schild neben der Klingel vorstellen: Wer klingelt, muss nicht raten, ob man hier Pakete abgibt, Termine macht oder besser den Seiteneingang nimmt.

Der Vorteil eines festen Orts liegt auf der Hand. Ein Agent muss nicht für jede Firma eine eigene Anleitung mitbringen. Er fragt an der immer gleichen Stelle nach und bekommt die Hausordnung geliefert.

Sessions: erst mal als Gast

Der zweite Baustein: Der persönliche Agent startet im Namen seiner Kundschaft eine Session. Sie kann laut Sierra als Gast beginnen. Das reiche womöglich schon, um zu prüfen, ob ein Produkt auf Lager ist, oder um nach der Rückgabepolitik zu fragen. Wichtig ist der Satz danach: Der Agent identifiziert sich selbst, damit das Unternehmen immer weiß, wann ein Agent für einen Kunden handelt.

Im Büro-Bild: Der Bote darf im Foyer am Tresen fragen, ob die Jacke in Größe M vorrätig ist. Dafür muss niemand seine Vollmacht prüfen. Aber er trägt ein Namensschild, auf dem „Agent“ steht, und das bleibt dran.

Anmelden, ohne das Passwort zu verschenken

Spannend wird es beim dritten Baustein, dem Sign-in. Braucht eine Aufgabe das Kundenkonto, meldet sich die Person laut Sierra auf der Seite des Unternehmens per OAuth an. Das ist der entscheidende Unterschied zum Passwort-Weitergeben: Die Anmeldung findet beim Unternehmen statt, nicht im Agenten.

Danach, sofern das Unternehmen es erlaubt, kann sich der Agent mit einem Session-Token im Namen der Person anmelden. Sierra betont, dass dieses Token nur den Zugriff gewährt, den die Kundschaft freigegeben hat. Eine Art Besucherausweis mit aufgedruckten Türen: Der Schlüssel öffnet die Rückgabestelle, aber nicht den Tresor.

Was in den Quellen steht und was nicht, will ich sauber trennen. Die Spezifikation beschreibt drei Anmeldearten: Direct Sign-In (die Person meldet sich auf der Seite des Unternehmens im eigenen Browser an), Device Sign-In (der Agent zeigt einen Link und einen Code, die Person meldet sich auf einem beliebigen Gerät an) und Mediated Sign-In (der Agent schickt die Zugangsdaten der Person stellvertretend an das Unternehmen). Letzteres ist kein OAuth-Ablauf. Die Spezifikation räumt selbst ein, dass es dem Unternehmen mehr Verantwortung auflädt als die direkte Anmeldung. Unternehmen, die es anbieten, müssen deshalb Versuche begrenzen, und Agenten dürfen die Zugangsdaten an keine andere Adresse schicken.

Meine Lesart: Der saubere Weg ist der, bei dem die Person selbst beim Unternehmen anklopft. Der vermittelte Weg ist ein Zugeständnis an die Realität. Ob Firmen ihn überhaupt anbieten, entscheiden sie laut Entwurf selbst, denn die Typen stehen in der poppy.json des jeweiligen Unternehmens.

Eine Session, alle Kanäle

Baustein vier heißt bei Sierra „One session across every channel“. Dasselbe Token gilt für die APIs des Unternehmens, für seine Website und für Gespräche mit seinem Agenten. Eine Frage vor der Anmeldung und eine Bestelländerung danach gehören laut Sierra zum selben Besuch. Die Person muss nicht von vorn anfangen, und das Unternehmen sieht die ganze Reise statt zusammenhanglose Bruchstücke.

Das klingt nach Komfort, ist aber auch ein Ordnungsprinzip. Wer schon einmal erlebt hat, dass ein Chatbot nichts von der Bestellung weiß, über die man gerade am Telefon gesprochen hat, versteht den Reiz. Hier würde alles an einer Session hängen, und diese Session hat einen Namen: den des Agenten, der sie eröffnet hat.

Der fünfte Baustein, „Getting the job done“, überlässt dem Unternehmen die Wahl der Kanäle. Es entscheidet, was am besten zu seiner Kundschaft passt. Sierra nennt drei Wege:

Website: Der Agent surft über die normalen Seiten, und das Unternehmen wendet auf jeder die Berechtigungen der Kundschaft an.
APIs: Der Agent verbindet sich über Schnittstellen, die auf Standards wie OpenAPI und MCP beruhen.
Eigener Agent des Unternehmens: für Aufgaben, die ein Gespräch brauchen, etwa eine Garantiefrage oder einen Umtausch. Antworten können laut Sierra gestreamt werden, und Unternehmen können eine Anfrage offen halten, bis es Neuigkeiten gibt.

Der Clou: Ein Unternehmen kann laut Sierra mit dem anfangen, was es schon hat, und später mehr ergänzen. Es soll sich einmal über Poppy anbinden, statt für jeden persönlichen Agenten eine eigene Verbindung zu bauen. Ob das in der Praxis so aufgeht, kann ein Entwurf nicht beantworten. Das ist ein Versprechen aus dem Blogpost, keine Erfahrung.

Drei Szenen: Jacke, Flug, Hypothek

Sierra bringt drei Beispiele, die jeweils einen der drei Kanäle zeigen. Bei allen gilt: Es sind Illustrationen aus dem Blogpost, keine Protokollregeln.

Die Jacke (Website)

Eine Kundin bittet ihren persönlichen Agenten, eine Jacke zurückzugeben. Der Agent findet den Händler über das Protokoll und weist sich aus, die Person meldet sich einmal an. Dann nutzt der Agent die normale Rückgabeseite des Händlers. Der Händler weiß, dass ein Agent für eine angemeldete Kundin handelt, und lässt ihn eine Rückgabe starten, aber nicht die hinterlegten Zahlungsdaten ändern.

Das ist die Szene, die den Gedanken am besten transportiert. Aber lesen Sie genau: Dass Zahlungsdaten tabu sind, ist das Beispiel eines Händlers in Sierras Blogpost. Das Protokoll schreibt es nicht vor. Wo die Grenze verläuft, entscheidet jedes Unternehmen für sich.

Der Flug (APIs)

Ein Flug wird gestrichen, und die Person bittet ihren Agenten um Umbuchung. Der Agent verbindet sich per MCP mit den Buchungswerkzeugen der Airline, mit dem freigegebenen Zugriff. Er findet den nächsten freien Flug und bestätigt den Sitzplatz mit der Person, bevor er bucht.

Dieser letzte Halbsatz ist mir wichtig. Der Agent fragt zurück, bevor Geld fließt oder ein Platz fest vergeben wird. Ob und wann ein Agent zurückfragt, ist allerdings eine Frage der Agenten-Software, nicht des Protokolls. Der Blogpost beschreibt es als Ablauf, nicht als Pflicht.

Die Hypothek (Agent des Unternehmens)

Die dritte Szene fand laut Sierra live auf dem Sierra Summit am Dienstag statt. Alex McGillis, VP of Product bei Rocket, zeigte das Protokoll mit Metas persönlichem Agenten Muse. Er bat Muse, eine Hypotheken-Vorabzusage zu besorgen. Muse ging auf die Website von Rocket, fand über Poppy den Agenten von Rocket und bat Alex um Erlaubnis, sich zu verbinden. Alex meldete sich an und gab die Kredit- und Einkommensdaten frei, die für eine Hypothek nötig sind. Die beiden Agenten arbeiteten Kaufpreis, Anzahlung und Zinssatz durch, und laut Sierra lag innerhalb kurzer Zeit ein Vorabzusage-Schreiben vor. Alex habe jederzeit die Kontrolle behalten, während die Agenten die Arbeit erledigten.

Das ist die Darstellung von Sierra zu einer Live-Demo auf der eigenen Veranstaltung. Ein unabhängiger Test liegt nicht vor, und ein produktiver Einsatz ist damit nicht belegt. Wir bei digital-magazin.de haben bei Muse schon gefragt, wie prüfbar Freigaben, Ersatz-Tokens und Bounty sind. Genau diese Prüfbarkeit würde auch hier zählen, sobald aus der Demo mehr wird.

Übrigens bemerkenswert: Sierra nennt als Reichweite des Protokolls Aufgaben „vom Kauf eines Pullovers bis zum Hypothekenantrag“. Das ist der Anspruch. Der Entwurf selbst zeigt zunächst nur, wie sich Agent und Unternehmen finden und verständigen.

Nichts Neues erfunden: Die Bausteine unter Poppy

Poppy-Prinzip: Person gibt am Laptop Berechtigungen für einen KI-Agenten frei — Rechte gezielt freigeben (Symbolbild)

Poppy ist laut Sierra auf OAuth, JSON Web Tokens (JWTs), HTTPS, OpenAPI und MCP aufgebaut. Das ist eine bewusste Entscheidung: Weil diese Standards offen und weit verbreitet sind, können Teams den Entwurf nach Sierras Darstellung mit Bibliotheken und Werkzeugen umsetzen, die sie ohnehin haben. Der Kern sei außerdem erweiterbar angelegt, damit Branchen eigene Schichten darauf bauen können. Die Spezifikation führt dafür eine Extensions-Seite.

Ein Satz zur Abgrenzung, weil er in Sierras Post steht: Protokolle wie das Universal Commerce Protocol (UCP) konzentrieren sich laut Sierra aufs Einkaufen, vom Produktfinden bis zum Bezahlen und Verwalten von Bestellungen. Poppy sei ergänzend und beschreibe, wie sich ein persönlicher Agent ausweist, die Erlaubnis der Kundschaft einholt und mit einem Unternehmen über beliebige Aufgaben hinweg zusammenarbeitet. Mehr Vergleich gibt es hier nicht, und mehr würde ich auch nicht behaupten.

Warum ist die Standard-Auswahl bemerkenswert? Weil sie ein Gegenmodell zum Bastelprojekt ist. Jede Firma könnte natürlich eine eigene Agenten-Schnittstelle erfinden. Dann hätte aber jede Firma eine andere. Wer sich auf bekannte Bausteine stützt, spart den Leuten das Neulernen. Ob das am Ende reicht, hängt davon ab, wie viele Unternehmen mitziehen. Womit wir bei der Liste wären.

Poppy-Partnerliste: 35 neue Namen und ein Befund

Sierra schreibt in seinem Post vom Freitag, seit der Ankündigung am Dienstag mit Meta, Genesys, Instinct, NiCE, Rocket, Shopify, Stripe und Walmart sei die Resonanz überwältigend gewesen. Deshalb veröffentliche man den Entwurf und nenne weitere 35 Designpartner. Das sind laut Sierras Post: Adyen, Atomic, Bank of America, BBVA, Chime, Cigna, Cloudflare, Comcast, DIRECTV, ElevenLabs, FOX, Gap Inc., GEICO, Hertz, Insurify, Klaviyo, Liberty Mutual, Mastercard, Nordstrom, Notion, Okta, OneSignal, OpenAI, PayPal, Plaid, SiriusXM, Synchrony, Target, United Airlines, Venmo, Visa, Wells Fargo, Zapier, Zendesk und 1Password.

Rechnen wir: 35 neue plus die 8 vom Dienstag, 6. Oktober, laut Sierras Post vom 9. Oktober, ergibt nach unserer Zählung 43. Die Summe nennt Sierra selbst nicht, das ist eine dm-Rechnung. Eine Kleinigkeit zur Genauigkeit: Sierras Launch-Teaser vom 6. Oktober führt NiCE nicht auf, der Post vom 9. Oktober dagegen schon. Ich halte mich deshalb an die jüngere Angabe.

Und jetzt das Wichtigste an dieser Liste, nämlich was dort steht. Es sind Designpartner eines Entwurfs. Laut Sierra werden diese Unternehmen am Designprozess teilnehmen und wertvolles Feedback aus ihrer jeweiligen Geschäftsperspektive beisteuern. Sie bauen Poppy nicht ein, sie setzen es nicht ein, und sie haben den Entwurf nicht als fertigen Standard übernommen. Wer „43 Firmen unterstützen Poppy“ liest, liest mehr, als dasteht.

Ein Listenbefund noch, ohne Deutung: Amazon steht nicht auf der Liste. Der Name taucht weder im Blogpost noch in der Spezifikation auf.

Mehr dazu sage ich nicht, weil die Quellen nichts dazu sagen.

Fußnoten für Nerds: Was in der Spezifikation steckt

Jetzt wird es technisch. Die Spezifikation trägt den Stand „Draft 0.1, Updated Oct 9, 2026“ und steht unter der Apache License 2.0. Die Schlüsselwörter MUST, SHOULD und MAY gelten, wenn sie großgeschrieben sind, wie in RFC 2119 und RFC 8174 beschrieben. Ein paar Dinge, die mir beim Lesen aufgefallen sind:

Draft-Vorbehalt: Die Spezifikation sagt selbst, jeder Teil könne sich vor einer stabilen Version ändern, auch auf Weisen, die nicht abwärtskompatibel sind. Das ist die ehrlichste Zeile im ganzen Dokument.
Discovery: Ein Unternehmen MUSS seine poppy.json unter https://{domain}/.well-known/poppy.json über HTTPS veröffentlichen. Die URL darf weiterleiten, etwa zu einem Dienstleister, aber jede Weiterleitung muss auf HTTPS zeigen.
Zwei Tokenarten: Das Session Token ist laut Spezifikation ein kurzlebiges Zugriffstoken. Das Account Token ist dagegen langlebig, ein OAuth-Refresh-Token, das dem Agenten erlaubt, später wieder angemeldete Session Tokens zu holen, ohne die Person erneut zu fragen. Verwendet wird es nur am Token-Endpunkt des Unternehmens.
Session-Start: Der Agent holt sich ein Session Token per JWT Bearer Grant nach RFC 7523. Die Assertion ist ein kurzlebiges JWT, das der Agent mit einem Schlüssel signiert.
Agent-Identität: Die client_id eines Agenten MUSS eine HTTPS-URL sein, die sein Metadaten-Dokument liefert. Das folgt dem OAuth-Client-ID-Metadata-Entwurf, den laut Spezifikation auch MCP nutzt.
User-ID: Der Agent vergibt je Person und Unternehmen eine eigene, undurchsichtige ID. Sie ist bei jedem Unternehmen anders, damit Firmen ihre Kundschaft nicht untereinander abgleichen können, und darf nicht aus persönlichen Daten wie E-Mail-Adresse oder Name abgeleitet sein.
Proof of Possession: Session Tokens sind an einen Schlüssel gebunden, den der Agent hält, per DPoP nach RFC 9449. Ein kopiertes Token ist ohne diesen Schlüssel nutzlos.
Die MCP-Ausnahme: MCP kann keine DPoP-Beweise nutzen, „because MCP authorization uses Bearer tokens“ (sinngemäß: weil die MCP-Autorisierung Bearer-Tokens verwendet). Für MCP beantragt der Agent deshalb ein Token ohne Beweis, und das Unternehmen stellt ein Bearer-Token aus. Dieses gilt nur an einem MCP-Server, und Bearer-Tokens dürfen Unternehmen laut Entwurf ausschließlich auf ihren MCP-APIs akzeptieren.
Rechte: Zwei breite Scopes sind definiert, poppy:read und poppy:write. Unternehmen dürfen eigene Scopes definieren, im Beispiel etwa addresses, oder die breiten Scopes weglassen und nur engere anbieten.

Zwei weitere Details finde ich bemerkenswert. Erstens: Die Spezifikation verbietet Agenten ausdrücklich, ein Session Token wegzulassen, um sich gegenüber dem Unternehmen als Mensch auszugeben. Zweitens: Die Frage, ob sich eine Person wirklich selbst angemeldet hat, lässt sich nicht immer prüfen. Die Spezifikation sagt dazu, die Anmeldearten funktionierten auf Vertrauen, und Unternehmen dürfen die client_id eines Agenten widerrufen, der sich nicht daran hält.

Dazu gibt es Teile, die ich hier nur anreiße: Web-Browsing mit einem eigenen Browser-Session-Endpunkt und Cookie des Unternehmens, Gespräche zwischen Agenten mit Kennzeichnung, ob ein Mensch oder eine KI schreibt, und die Übergabe an einen Menschen im Unternehmen. Die Spezifikation verweist außerdem auf eine Seite „Open topics“, die auflistet, was der Entwurf noch nicht abdeckt.

Was bei Poppy noch Papier ist

Sortieren wir die Lage ordentlich, weil sie sich in Schlagzeilen schnell verbiegt.

Vorhanden ist ein Entwurf in Version 0.1, veröffentlicht am Freitag, 9. Oktober, mit einem Blogpost und einer Spezifikation. Vorhanden ist eine Liste von Designpartnern, die nach unserer Zählung 43 Namen umfasst. Und vorhanden ist eine Live-Demo, die Sierra auf dem eigenen Summit am Dienstag gezeigt hat.

Nicht vorhanden, soweit die Quellen es hergeben: ein Termin für eine stabile Version. Keine Angabe, welche Firma Poppy im Echtbetrieb einsetzt. Keine Aussage dazu, ob oder wann das Protokoll in Europa oder Deutschland erprobt wird. Keine Preise, keine Gebühren. Kein Wort dazu, wie Aufsichtsstellen es sehen. Alles das habe ich in den beiden Quellen nicht gefunden, und ich ergänze es nicht.

Angekündigt ist, in Sierras Worten, ein nächster Schritt: „Over the next month we will host design workshops and publish a reference implementation“ (meine Übersetzung: Im kommenden Monat will man Design-Workshops veranstalten und eine Referenzimplementierung veröffentlichen, damit Entwickelnde einen Einstieg haben). Das ist eine Ankündigung. Ob und wann sie eintrifft, wird sich zeigen, und wir bei digital-magazin.de schauen dann in die Referenzimplementierung hinein, statt nur die Ankündigung abzuschreiben.

Und Sierra sagt selbst, der Entwurf sei ein Ausgangspunkt. Man wünsche sich, dass möglichst viele Unternehmen ihn lesen und helfen, das neue Protokoll zu formen. Das ist ein offenes Angebot an die Branche, kein Abschluss.

Bevor Ihr Agent zahlen darf: Fragen an die Zukunft

Nehmen wir an, der Entwurf überlebt die Workshops und wird irgendwann Praxis. Was würde ich vor dem ersten „Agent darf zahlen“ wissen wollen? Meine Liste, ausdrücklich als persönliche Einschätzung, nicht als Aussage der Quellen:

Wer hat freigegeben, und wo sehe ich das? Nach dem Prinzip des Entwurfs entscheidet die Kundschaft über den Zugriff. Ich möchte aber nachlesen können, was ich freigegeben habe, in ganzen Sätzen und nicht in Scope-Namen wie poppy:write.
Welche Grenze zieht das Unternehmen? Die Jacken-Rückgabe ja, die Zahlungsdaten nein, das war das Beispiel eines Händlers. Jeder Händler kann das anders handhaben. Ich würde wissen wollen, wo die Linie verläuft, bevor etwas schiefgeht.
Wie widerrufe ich? Die Spezifikation sieht vor, dass Personen den Agenten in den Kontoeinstellungen trennen können, wodurch seine Account Tokens widerrufen werden. Im Alltag zählt, wie leicht sich dieser Schalter finden lässt.
Fragt der Agent zurück? Im Flugbeispiel bestätigt er den Sitz, bevor er bucht. Verlassen würde ich mich darauf erst, wenn es für den konkreten Agenten feststeht.

Dahinter liegt die Vertrauensfrage. Laut einer Sapio-Umfrage im Auftrag von Shopify (online, Juli, 2.000 Befragte ab 18 Jahren in Deutschland, Selbstauskunft) wollen 73 Prozent der Verbrauchenden in Deutschland in der Weihnachtssaison KI für mindestens eine Shopping-Aufgabe nutzen, aber nur 28 Prozent vertrauen einer KI an, einen Kauf in ihrem Namen auszulösen. Das sind Angaben aus einer Herstellerumfrage und keine Poppy-Daten; sie sagen nichts darüber, wie die Befragten zu einem Ausweis für Agenten stünden. Aber sie zeigen, wo die Hürde sitzt: Zwischen „KI hilft mir beim Suchen“ und „KI darf zahlen“ liegt ein Vertrauensgraben, und ein Protokoll allein schließt ihn nicht.

Dazu passt eine These aus unserem eigenen Haus: Wir bei digital-magazin.de haben schon argumentiert, dass Agent-Safety ohne Kontrolle außerhalb des Agenten selbst nur schwer zu haben ist. Das ist unsere Position, keine Aussage von Poppy. Das Protokoll beschreibt, wie sich ein Agent ausweist und was er darf. Ob jemand außerhalb des Agenten gegenprüft, ist eine andere Schicht.

Was bleibt von Poppy?

Ein Entwurf, ein Name und eine Idee, die mir ehrlich gefällt: Der Bote bekommt einen Ausweis, und die Firma bekommt die Chance, zu sagen, was er darf. Bisher läuft vieles so, dass der Agent sich durchmogelt und alle so tun, als sei das normal. Poppy will daraus ein offenes Anklopfen machen.

Ob daraus ein Standard wird, entscheidet nicht der Blogpost. Das entscheiden die Workshops, die Referenzimplementierung, die Unternehmen, die den Entwurf lesen, und die Menschen, die ihren Agenten irgendwann tatsächlich Rechte erteilen. Dass Sierra ausdrücklich sagt, eine Version 0.1 könne sich auch inkompatibel ändern, finde ich beruhigend: Wer seine Unfertigkeit so offen benennt, tut zumindest nicht so, als wäre alles längst entschieden.

Mein Tipp bis dahin: Lesen Sie die Quellen selbst, vor allem den Abschnitt zu Sessions und Tokens, und beobachten Sie, welche Namen auf der Liste bleiben und welche dazukommen. Die Frage, die ich mir stelle, ist weniger „Wer steht drauf?“ als „Wer baut es zuerst wirklich ein?“. Die Antwort steht noch aus.