Das Personal Agent Protocol ist ein Standardentwurf dafür, wie der KI-Assistent einer Person Zugang zur Website, zu den APIs und zum Support-Agenten eines Unternehmens bekommt und was das Unternehmen ihm dort erlaubt. Sierra und Meta haben ihn gemeinsam mit Partnern wie Stripe, Shopify und Walmart angekündigt (Sierra-Ankündigung). Ein erster Entwurf mit dem Spitznamen Poppy wurde wenige Tage später veröffentlicht (Sierra zum Entwurf). Es ist kein Produkt, das Sie heute einschalten können.
Wenn Sie ein Unternehmen führen, lautet die nützliche Lesart: Nichts geht kaputt, und nichts ist Pflicht. Aber KI-Assistenten besuchen Websites schon jetzt im Auftrag von Kunden, und dieser Entwurf ist der erste ernsthafte Versuch, Ihnen ein Mitspracherecht zu geben, wie das abläuft. Sich die Grundzüge anzusehen kostet eine Stunde. Es zu ignorieren, könnte Sie ein paar chaotische Jahre mit improvisierten Bot-Regeln kosten.
Dieser Beitrag behandelt, was der Entwurf festlegt, worin er sich von MCP, A2A und den Commerce-Protokollen unterscheidet, wer dabei ist und wer nicht, und eine kurze Liste mit Dingen, die sich jetzt lohnen.
Was öffentlich ist und was nicht
Es gibt drei Dinge. Erstens Sierras Ankündigung, die die Partner und die Designziele nennt. Zweitens einen Spezifikationsentwurf, gekennzeichnet als Draft 0.1 und unter Apache 2.0 lizenziert (Spezifikation). Drittens das Versprechen von Design-Workshops und einer Referenzimplementierung. Beides war in den für diesen Beitrag geprüften Quellen noch nicht aufgetaucht (Sierra).
Noch nicht öffentlich sind: ein namentlich genanntes Unternehmen, das es produktiv einsetzt, ein Leitungsgremium und eine abschließende Antwort zum Thema Zahlungen. Als die Nachricht erschien, hielt ein Bericht fest, dass weder ein Leitungsgremium noch eine Lizenz erkennbar sei (FourWeekMBA). Die Lizenzfrage hat der Entwurf inzwischen selbst beantwortet. Die Governance-Frage ist es auf den geprüften Seiten nicht.
Behandeln Sie es also als Vorschlag mit gewichtigen Unterstützern. Meta beschrieb den Anspruch mit einem E-Mail-Vergleich: „E-Mail hat sich durchgesetzt, weil sich alle auf Adressierung, Nachrichtentransport und Zustellung geeinigt haben. Niemandem gehört sie, jeder kann darauf aufbauen" (VKTR). E-Mail hat aber auch Jahre gebraucht, und viele Unternehmen betrieben in der Zwischenzeit ihre eigenen seltsamen Mail-Regeln. Erwarten Sie hier denselben Flickenteppich: Frühe Anwender setzen die Konventionen, die der Rest übernimmt.
Das Problem: alles blockieren oder das Passwort herausgeben
Die Projektseite beschreibt die heutige Wahl ziemlich unverblümt. Entweder blockieren Unternehmen Agenten komplett, oder ein Agent meldet sich mit den vollen Zugangsdaten des Nutzers an und kann alles tun, was der Nutzer kann (personalagentprotocol.org). Beides ist nicht gut. Blockieren verärgert den Kunden, der den Agenten geschickt hat. Voller Zugriff ist ein Sicherheits-Review, das nur darauf wartet, stattzufinden.
Blockieren ist Realität. Eine Zusammenfassung der Ankündigung nennt Amazon, Delta, United, Zillow und eBay als Seiten, die Agenten blockieren, und erwähnt eine Anti-Bot-Richtlinie von Cloudflare, die einige versehentlich erwischt hat (AI Weekly). Kevin Miller von Stripe brachte die Kundensicht auf den Punkt: Wer einen Agenten schickt, „erwartet denselben Service, den er selbst bekäme" (Unite.AI).
Die Antwort des Entwurfs ist eine Stufenleiter. Die Website nutzt ein Hotelbeispiel: den Agenten blockieren, jeden Agenten Zimmer suchen lassen, ihn nach der Anmeldung Reservierungen einsehen lassen, ihn ein Zimmer nur mit jeweiliger Zustimmung der Person buchen lassen oder ihm vollen Zugriff geben. Sie wählen die Stufe pro Aktion.
Die mittleren Stufen sind der Kern. Die meisten Unternehmen wollen, dass Agenten frei browsen und lesen und nur etwas ändern, wenn ein Mensch zustimmt.
So läuft eine Sitzung ab
Ein Unternehmen veröffentlicht unter /.well-known/poppy.json eine Datei, die beschreibt, wie Agenten mit ihm umgehen können. Der Agent liest sie, öffnet eine Sitzung (als Gast, wenn niemand angemeldet ist) und schickt die Person, wenn er mehr braucht, durch eine OAuth-basierte Anmeldung (Sierra). Der Entwurf nennt drei Anmeldearten: direkt, bei der sich die Person auf der Seite des Unternehmens anmeldet, per Gerät, bei der sie einen Code auf einem anderen Gerät nutzt, und vermittelt, bei der der Agent die Zugangsdaten selbst übermittelt (Spezifikation).
Für Sicherheitsleute sind zwei Details wichtig. Sitzungs-Tokens sind kurzlebig und per DPoP an einen Schlüssel gebunden, und laut Entwurf dürfen Agenten Tokens nicht in einer URL senden und Unternehmen sie dort nicht akzeptieren. Der Entwurf räumt auch die Schwachstelle ein: „Accepting credentials from a Personal Agent puts more responsibility on the Company" (Spezifikation).
Die zweite wichtige Idee: Ein Token deckt alles ab. Laut Sierra funktioniert dasselbe Token für die APIs des Unternehmens, seine Website und die Gespräche mit dessen Agenten (Sierra). Eine Frage vor der Anmeldung und eine geänderte Bestellung danach zählen als ein einziger Besuch (The Next Web).
Drei Wege hinein, und Sie wählen
Sie müssen nicht alles bauen. Ein Unternehmen entscheidet, wie Agenten es erreichen: über die Website, über APIs, die mit OpenAPI beschrieben sind, oder über einen MCP-Server, oder über einen eigenen Agenten für Gespräche. Ein Händler mit guter API kann den Browsing-Weg überspringen. Ein kleiner Shop, der nur eine Website hat, kann dort anfangen.
Für den Gesprächsweg gibt es eine Regel, die Kunden gefallen wird: Jede Nachricht gibt an, ob ein Mensch oder eine KI sie geschrieben hat, und der Entwurf regelt auch die Übergabe an eine Person. Wenn Sie bereits einen Support-Agenten betreiben, etwa aus dem Customer-Support-Ranking, betrifft Sie dieser Weg zuerst.
Wie es zu MCP, A2A, ACP und AP2 passt
Es ersetzt keines davon und sollte auch nicht als Konkurrenz dazu gelesen werden. Sie erledigen unterschiedliche Aufgaben, und der Entwurf stützt sich selbst auf MCP.
| Protokoll | Entwickelt von | Aufgabe |
|---|---|---|
| MCP | Open-Source-Standard | Verbindet KI-Apps mit Tools und Daten (MCP-Dokumentation) |
| A2A | Google, jetzt Linux Foundation | Lässt Agenten verschiedener Anbieter miteinander kommunizieren (A2A) |
| ACP | Stripe und OpenAI | Agent-Checkout und Weitergabe von Zahlungsdaten (ACP) |
| AP2 | Signierte Mandate, die belegen, dass ein Nutzer einen Kauf autorisiert hat (AP2) | |
| Personal Agent Protocol | Sierra und Meta (Entwurf) | Discovery, Sitzungen, Anmeldung und Berechtigungen zwischen einem persönlichen Agenten und einem Unternehmen |
Der Stack oben ist unsere Lesart, kein offizielles Diagramm. Auf den Punkt gebracht: MCP ist, wie ein Agent ein Tool aufruft, A2A ist, wie Agenten miteinander sprechen, ACP und AP2 drehen sich ums Bezahlen, und dieser Entwurf regelt, wie man zur Tür hereinkommt und erkannt wird. Zahlungen sind als künftige Erweiterung aufgeführt, ein Checkout würde heute also weiterhin über etwas wie ACP oder AP2 laufen. Streit wird es bei der Überschneidung mit MCP geben, denn sowohl der Entwurf als auch ein normaler MCP-Server können die Aktionen eines Unternehmens bereitstellen.
Auch auf der Zugangsseite gibt es einen Rivalen. Visa betreibt ein Trusted Agent Protocol, das Anfang dieses Jahres gestartet ist, und The Next Web berichtete, dass Stripe und Shopify ihm bereits beigetreten seien (The Next Web). Visa steht inzwischen auch auf der Design-Partner-Liste des Personal Agent Protocol, die beiden Initiativen könnten sich also eher überschneiden, als frontal zu konkurrieren. Ob am Ende ein Standard oder zwei übrig bleiben, ist offen.
Wer dabei ist und wer fehlt
Die Ankündigung nannte neben Sierra und Meta auch Genesys, Instinct, Rocket, Shopify, Stripe und Walmart (Sierra). Der Beitrag zum Entwurf führt in dieser ersten Gruppe zusätzlich NiCE auf und ergänzt 35 weitere Design-Partner, darunter Adyen, Bank of America, BBVA, Cloudflare, Mastercard, OpenAI, PayPal, Target, United Airlines, Visa und Wells Fargo. Sierra zufolge werden sie am Designprozess teilnehmen, was nicht dasselbe ist wie eine ausgelieferte Unterstützung (Sierra). Das ändert eine frühere Geschichte: Am Tag der Ankündigung hoben Berichte hervor, dass OpenAI fehle, und Bret Taylor, Mitgründer von Sierra, ist Vorsitzender des OpenAI-Boards (AI Weekly).
Amazon, Anthropic und Google gehören weder zu den beim Start genannten Partnern noch zu denen im Beitrag zum Entwurf. Dass sie auf einer Liste fehlen, beweist nicht, dass sie draußen sind, prüfen Sie also Sierras Seiten erneut, bevor Sie das zitieren. Claude, ChatGPT und Perplexity wären alle naheliegende persönliche Agenten, und ein Standard ohne einen großen Assistenten dahinter bleibt eine Checkliste auf Unternehmensseite. Am Tag der Ankündigung merkte The Next Web an, dass kein europäischer Händler, keine Bank und kein Zahlungsunternehmen genannt worden sei (The Next Web). Die längere Liste enthält jetzt BBVA und Adyen.
Was es für Entwickler und Marketer bedeutet
Entwickler haben den klareren Deal. Wenn Ihr Produkt bereits OAuth und eine OpenAPI-Beschreibung hat, sind Sie beim API-Weg schon zum größten Teil am Ziel, und die Token-Regeln des Entwurfs (kurzlebig, schlüsselgebunden, nie in einer URL) lesen sich wie normale Best Practice. Neu sind die Discovery-Datei und die Entscheidung über die Scopes.
Marketer bekommen eine Messfrage. Heute sieht ein Agent, der für einen Kunden Ihre Preisseite recherchiert, wie ein Bot aus, oder wie gar nichts. Eine Sitzung, die den Agenten und den Kunden dahinter identifiziert, macht diesen Traffic zählbar und lässt ihn sich anders behandeln als Scraper. Ob das eine gute Nachricht ist, hängt davon ab, was Agenten über Sie sagen sollen, und das ist ebenso eine Content-Frage wie eine technische.
Was Unternehmen jetzt tun können
Nichts davon setzt das Protokoll voraus. Alles hilft, egal ob sich der Entwurf durchsetzt oder verschwindet.
- Sehen Sie in Ihre Logs und Ihr Bot-Tooling und finden Sie heraus, welcher Agenten-Traffic Sie schon erreicht. Wenn Sie Cloudflare nutzen, prüfen Sie, was dessen Bot-Regeln mit Agenten machen, die für einen Kunden handeln.
- Halten Sie pro Aktion fest, was ein Agent lesen und was er ändern darf. Nutzen Sie die Stufenleiter von oben: browsen, Konto einsehen, mit Zustimmung handeln.
- Prüfen Sie, ob sich Kunden über einen Standard-OAuth-Flow anmelden können. Agenten werden sich darauf stützen.
- Legen Sie Ihre wichtigsten Aktionen (Bestellstatus, Retouren, Buchungen) hinter eine dokumentierte API oder einen MCP-Server. Eine gut beschriebene OpenAPI-Datei lohnt sich ohnehin.
- Wenn Sie über Shopify verkaufen, beobachten Sie, was die Plattform liefert, statt es selbst zu bauen.
- Machen Sie eine Person dafür zuständig, den Entwurf zu verfolgen. Lesen Sie die Seite „Open topics" der Spezifikation, wenn sie sich ändert.
Der Scorer unten macht aus dieser Liste einen schnellen Selbsttest. Es ist unsere eigene Checkliste, kein Teil des Protokolls.
Wer sich noch nicht damit befassen muss: ein Unternehmen ohne Logins, ohne API und ohne Support-Agenten. Sie haben nichts, was Sie bereitstellen könnten. Wenn Sie im Kundenservice tätig sind, ist der nächste Vergleich der KI-Agent, den Sie schon betreiben (Sierra AI Agents ist einer; das Ranking der KI-Support-Chatbots listet weitere). Verwandte Lektüre: unser Kaufratgeber für KI-Agent-Plattformen und das Ranking der besten KI-Agenten.
Die offenen Fragen
Identität. Laut Entwurf können Unternehmen die Registrierung von Agenten verlangen, Allowlists und Blocklists nach Client-ID führen und eine Client-ID sperren, die das Protokoll missbraucht (Spezifikation). Wer für einen Agenten bürgt und wie ein kleiner Shop das prüft, bleibt jedem Unternehmen selbst überlassen. Zum Zeitpunkt der Ankündigung hieß es in Berichten, es gebe keine Details dazu, wie Agenten ihre Identität nachweisen (FourWeekMBA). Die Spezifikation beschreibt kein gemeinsames Register vertrauenswürdiger Agenten.
Einwilligung. Bei der direkten Anmeldung werden die angeforderten Scopes angezeigt, und die Person kann einige, alle oder keine genehmigen. Das ist gut. Ungeklärt ist, wie oft Agenten nachfragen und ob Menschen einfach durchklicken.
Haftung. Wenn ein Agent den falschen Flug bucht, trägt jemand die Kosten, und die Spezifikation sagt nicht, wer. Haftung erwähnt sie überhaupt nicht. Zahlungen ebenso wenig, die sind für später vorgesehen.
Spam und Missbrauch. Unternehmen dürfen die Erstellung von Sitzungen pro Client-ID begrenzen. Ob das gegen Agenten hält, die ihre Identität wechseln, ist ungetestet.
Häufig gestellte Fragen
Ist das Personal Agent Protocol live?
Nicht als ausgelieferter Standard. Eine Spezifikation im Draft 0.1 ist öffentlich, und Sierra hat Workshops und eine Referenzimplementierung versprochen. In den geprüften Quellen war kein produktiver Einsatz genannt.
Ersetzt es MCP?
Nein. Es verweist auf MCP als eine der Möglichkeiten, wie ein Unternehmen seine Aktionen bereitstellen kann. MCP verbindet eine KI-App mit einem Tool. Der Entwurf regelt, wer der Agent ist und was er bei einem bestimmten Unternehmen darf.
Muss ich eine poppy.json-Datei veröffentlichen?
Noch nicht. Laut Entwurf veröffentlichen Unternehmen sie zur Discovery, aber niemand muss das, bis die Spezifikation stabil ist und Agenten sie lesen. Nützlich ist, die zugrunde liegenden Entscheidungen vorzubereiten.
Kann ich KI-Agenten weiterhin blockieren?
Ja. Blockieren ist die erste Stufe der Leiter. Der Reiz des Entwurfs ist, dass Sie Optionen zwischen Blockieren und vollem Zugriff bekommen.
Deckt es Zahlungen ab?
Nicht im Entwurf. Sierra nennt Zahlungen ohne Weitergabe von Kartendaten als künftige Erweiterung. Für den Checkout heute sehen Sie sich ACP oder AP2 an.
Wer kontrolliert es?
Der Entwurf steht unter Apache 2.0 und wurde von Sierra gemeinsam mit Meta veröffentlicht. Ein Leitungsgremium taucht auf den veröffentlichten Seiten nicht auf, wer es langfristig steuert, ist also offen.