Was ist das Personal Agent Protocol?
Ich baue Integrationen für eesel. Wenn ein Standard verspricht, zu regeln, wie sich ein Agent bei einem Unternehmen „authenticates with and acts on“, lese ich ihn wie einen API-Vertrag: Was ist definiert, was ist ein Satz voller Absicht? Die Ankündigung von Sierra besteht überwiegend aus Absichten, aber die Absichten sind konkret.
Persönliche Agenten sind die Assistenten, die für Verbraucher arbeiten, etwa Meta Muse, Instinct und OpenAI dots. Laut Sierra „use websites and apps the way people do“, und wenn das scheitert, rufen sie die Support-Hotline an oder öffnen den Web-Chat. PAP soll das durch eine direkte, autorisierte Verbindung ersetzen. Drei Parteien wollen davon Unterschiedliches:
- Verbraucher wollen Tempo, Verlässlichkeit und Vertrauen.
- Marken wollen Sichtbarkeit und Kontrolle: wissen, wann ein persönlicher Agent für einen Kunden handelt, und entscheiden, was er darf.
- Agent-Entwickler wollen einen einheitlichen Weg, mit teilnehmenden Unternehmen zu arbeiten.
Die in Sierras Beitrag genannten Partner sind Genesys, Instinct, Rocket, Shopify, Stripe und Walmart, neben Meta und Sierra. Kevin Miller von Stripe beschrieb die Geschäftsseite klar:
"We're contributing to the Personal Agent Protocol to give businesses a standard way to recognize their customers' agents, efficiently interact with them, and shape their customer relationships."
Wie läuft eine PAP-Sitzung ab?
So beschreibt Sierra den Ablauf, Schritt für Schritt. Das Protokoll beginnt auf der Website, wo ein persönlicher Agent herausfinden kann, was das Unternehmen anbietet und wie man es erreicht. Der Agent eröffnet dann eine Sitzung für seinen Nutzer, und die Sitzung kann als Gast beginnen. Eine Gastsitzung kann reichen, um die Verfügbarkeit eines Produkts zu prüfen oder nach den Rückgabebedingungen zu fragen.
Braucht die Aufgabe Kontozugriff, meldet sich der Kunde auf der Seite des Unternehmens an oder nutzt Zugangsdaten, die bereits bei seinem Agenten hinterlegt sind. Der Kunde entscheidet, ob der Agent nur Lese- oder auch Schreibzugriff bekommt. Die Sitzung basiert auf OAuth, dem Autorisierungsstandard hinter „Mit Google anmelden“, und gilt kanalübergreifend: Eine Frage vor der Anmeldung und eine Bestelländerung danach sind ein einziger Besuch.
Das Unternehmen wählt dann die Tür:
| Tür | Was der Agent tut | Geeignet für |
|---|---|---|
| Website | Navigiert Ihre normalen Seiten | Bestellstatus, Richtlinien nachschlagen |
| APIs (MCP, OpenAPI) | Ruft von Ihnen veröffentlichte Schnittstellen auf | Schnelle, strukturierte Aktionen |
| Unternehmensagent | Spricht mit Ihrem eigenen KI-Agenten | Alles, was ein Gespräch braucht, etwa ein Garantiefall |
Auf die dritte Tür sollten Support-Teams achten. Sierras Beitrag sagt selbst, dass der Unternehmensagent „tasks that need conversation“ übernimmt, und ein Unternehmensagent im Helpdesk ist genau das. Meta Business Agent, den David Singleton in seinem Beitrag nennt, ist Metas Version derselben Idee auf der Unternehmensseite. Meine Einschätzung: PAP ist ein Standard für die Eingangstür, und was hinter der Tür steht, sind weiterhin Ihre Richtlinien und Ihr KI-Kundenservice-Workflow.
Noch etwas, das man laut sagen sollte: Sierra, Genesys und Decagon verkaufen alle unternehmensseitige Agenten oder Contact-Center-Software, die Tür „Unternehmensagent“ ist also auch deren Geschäftsfeld. Das macht die Idee nicht falsch. Es heißt aber, dass Sie „offen“ als „offene Spezifikation“ lesen und prüfen sollten, wer die erste Referenzimplementierung schreibt.
Was ist tatsächlich ausgeliefert und was nur versprochen?
Diesen Teil haben die meisten Berichte übersprungen, deshalb habe ich ihn nach Datum nachverfolgt. Alles unten verlinkt auf die Seite des jeweiligen Herausgebers.
| Datum | Was | Status |
|---|---|---|
| 6. Okt. | Sierras Ankündigung und Bret Taylors Beitrag | Veröffentlicht: Prinzipien, Ablauf, Partnerzitate |
| 6. Okt. | Beitrag von Metas David Singleton | Veröffentlicht: „previewing our work“ |
| 6. Okt. | Decagon stellt PACT als Open Source bereit | Veröffentlicht: Spezifikation und Referenzcode |
| 8. Okt. | Sierras fleming-1 | Ausgeliefert: erkennt KI-Anrufer bei Telefonaten |
| „Later this month“ | Spezifikation v0.1 | Versprochen, nicht gefunden |
| Ohne Datum | Design-Workshops, Referenzimplementierung | Versprochen |
| Ohne Datum | Detaillierte Limits pro Aktion, Push-Benachrichtigungen, Zahlungserweiterungen | Als Dinge genannt, die kommen „could“ |
Lesen Sie die letzte Zeile zweimal. Die Ankündigung nennt das Prinzip, dass „companies set parameters for what those agents can do“, aber die feineren Kontrollen, mit denen Kunden und Unternehmen bestimmte Aktionen begrenzen können, werden als künftige Arbeit beschrieben. Das heutige PAP gibt Ihnen also auf dem Papier drei Dinge: Gast- gegenüber angemeldeter Sitzung, Lese- gegenüber Schreibzugriff und die Wahl der Tür. Limits pro Aktion gehören in der beschriebenen Form nicht zur ersten Version.
Sierra räumt auch die Lücke ein, die für ein Support-Team am wichtigsten ist. In seinem fleming-1-Beitrag heißt es, dass bei einem Agenten, der das Protokoll nutzt, „the company knows it's an agent and who it's acting for“, und weiter: „Of course, some agents may not respect the protocol.“ Deshalb hat Sierra zwei Tage später fleming-1 ausgeliefert, ein Modell, das die Sprache eines Anrufers in Echtzeit auf Anzeichen bewertet, dass sie von einer KI erzeugt wurde. Laut Sierra ist es „tuned to be conservative by default, so real people don't inadvertently get flagged“, und es soll Informationen liefern, kein Urteil.
Wer ist dabei und wer fehlt?
Die Partnerliste hängt davon ab, wen man fragt, und ich finde eine Tabelle angebracht, denn die Unterschiede sind die Geschichte. Ich habe jede Quelle direkt geprüft.
| Quelle | Genannte Partner |
|---|---|
| Sierra-Blog | Genesys, Instinct, Rocket, Shopify, Stripe, Walmart (mit Meta und Sierra) |
| Jeff Weinstein, Stripe | Meta, Sierra, Genesys, Instinct, Rocket, Shopify, Walmart, mit Stripe als „founding members“ |
| David Singleton, Meta | Genesys, NiCE, Decagon, Rocket, Shopify, Stripe, Walmart, mit Muse und Meta Business Agent |
| Decagon auf X | Tritt der „Personal Agent Protocol working group by @Muse“ bei |
Singletons Liste ergänzt NiCE und Decagon und lässt Instinct weg, während Sierras Liste Instinct enthält, aber weder NiCE noch Decagon. Am wahrscheinlichsten ist die Arbeitsgruppe in zwei Tagen gewachsen, was man von einem Standardentwurf erwarten würde. Keiner der vier Beiträge nennt OpenAI, Anthropic, Amazon, Google, Zendesk oder Salesforce. Amazon ist für den Handel am wichtigsten: Es hat im September Metas Muse gesperrt, und ein Kommentator auf X beschrieb die Folgen unverblümt.
"Nobody asked the person whose agent stopped working."
Die Reaktionen auf X zum Start waren gemischt. Eine Antwort auf Stripes Beitrag klingt wie viel von der Skepsis, die ich in der Branche gesehen habe:
"like you read the PACT announcement and released this with no spec?"
Das ist eine Vermutung über Motive, und Sierras Beitrag sagt das nicht. Die Daten passen aber zusammen: PACTs Code wurde am 6. Oktober öffentlich, am selben Tag, an dem PAP ohne Spezifikation angekündigt wurde.
Wie verhält sich PAP zu PACT?
PACT ist der am besten definierte Verwandte und deshalb verstehenswert. PACT steht für Personal Agent Consent & Trust. Decagon hat es gemeinsam mit Instinct entwickelt, und das offene Repository enthält die Spezifikation, TypeScript-Schemas, einen Referenz-Provider, einen Demo-Agenten und Konformitätstests, alles unter Apache-2.0.
Es läuft in drei Schritten ab:
- Entdecken und verbinden. Der persönliche Agent liest die A2A Agent Card des Unternehmens, die den Endpunkt, die Authentifizierung und die angebotenen Scopes wie
orders:readoderorders:cancelauflistet. Der Agent signiert jede Anfrage mit einem kurzlebigen JWT, sodass der Provider prüfen kann, welche Plattform anfragt. - Den Kunden authentifizieren. Der Agent fragt Scopes über den Device-Authorization-Flow von OAuth an und zeigt dem Kunden einen Anmeldelink. Der Kunde meldet sich direkt beim Unternehmen an und bestätigt die Berechtigungen. Der Agent sieht das Passwort nie.
- Im Rahmen der Freigabe handeln. Jede Anfrage trägt sowohl die Identität des Agenten als auch die Delegation des Kunden, und die Antworten enthalten signierte Belege, die die genutzten Scopes und ausgeführten Aktionen festhalten.
An PACTs Design gefällt mir am meisten die Trennung von Identität und Befugnis: "Verify which agent is calling independently of what the customer has permitted it to do." Ein Antwortender auf X erklärte, warum das bei einfachem OAuth wichtig ist:
"OAuth tells the business which customer, not which agent process holds the token. A copied bearer token works until it expires, so keep those short."
PACT beantwortet das mit signierten Agenten-JWTs und kurzlebigen Delegations-Tokens. PAPs Ankündigung sagt bisher nicht, wie sie damit umgeht, ein weiterer Grund, warum der Text von v0.1 zählt. Zum Produkt auf Basis von PACT, einschließlich Erkennung und Fluggesellschaft-Beispiel, siehe meine frühere Analyse zum Decagon Personal Agent Gateway. Eine Korrektur zu diesem Beitrag: Er sagte, die PACT-Spezifikation sei nicht öffentlich. Jetzt ist sie es, das Repository wurde am 6. Oktober veröffentlicht.
Wie schneidet PAP im Vergleich zu den anderen Protokollen ab?
Ehrlich gesagt beantworten diese Protokolle meist unterschiedliche Fragen, und der Vergleich ist einseitig, weil nur manche lesbaren Text haben. Diese Tabelle würde ich als Screenshot festhalten.
| Protokoll | Getragen von | Welche Frage es beantwortet | Öffentlicher Text heute | Erreicht Support-Chats? |
|---|---|---|---|---|
| Personal Agent Protocol | Meta, Sierra und Partner | Welche Tür, welcher Kunde, Lesen oder Schreiben | Nein, v0.1 versprochen | Ja, über die Tür des Unternehmensagenten |
| PACT | Decagon, Instinct | Wessen Agent ist das, welche Scopes hat der Kunde erteilt | Ja, Spezifikation und Code auf GitHub | Ja, für Support-Agenten gebaut |
| A2A | Agentic AI Foundation, über 150 Organisationen | Wie finden und adressieren sich zwei Agenten | Ja, Spezifikation 1.0 | Nur Transport: Autorisierung ist „implementation-specific“ |
| MCP | In PAP als API-Option genannt | Wie ruft eine KI Tools und Daten auf | Ja | Tools, keine Einwilligung |
| Web Bot Auth | Cloudflare | Welcher Bot besucht meine Website | Ja | Nein, Webverkehr |
| Trusted Agent Protocol | Visa | Ist dieser Checkout-Agent vertrauenswürdig | Ja, mit Vorbehalt „development and deployment“ | Nein, Händler-Checkout |
| Agent Pay probability score | Mastercard | Wurde diese Zahlung von einem KI-Agenten ausgelöst | Tests in den USA | Nein, Zahlungen |
| fleming-1 | Sierra | Ist dieser Anrufer eine KI | Produktfunktion, Sierra-Sprachagenten | Telefonate |
Zwei Dinge fallen auf. Erstens zielt PAP auf die Zeile, die niemand fertiggestellt hat: Einwilligung und Scope zwischen dem Agenten eines Verbrauchers und einem Unternehmen, über alle Kanäle. Zweitens spricht nichts in der Zahlungszeile überhaupt mit dem Support. Visas Protokoll nutzt Signaturen, die an die Domain und die konkrete Operation gebunden sind, und Mastercards Score sagt, ob eine Transaktion von einer KI ausgelöst wurde. Keines sagt Ihrem Helpdesk, dass der Agent eines Kunden eine Rückerstattung will. Sierras eigener Beitrag nennt „payments extensions“ als künftige PAP-Arbeit, was zeigt, wo sich die Protokollfamilien irgendwann treffen könnten. Wenn Sie online verkaufen, sind das Agentic Commerce Protocol und Stripes Version die Checkout-Seite derselben Geschichte.
Welches Protokoll deckt Ihren Fall ab?
Wählen Sie die Aufgabe, die Sie interessiert. Das Widget zeigt, welcher Standard sie abdeckt, wie weit er ist und was ich jetzt tun würde.
Was sollte ein Support-Team tun, bevor die Spezifikation kommt?
Die meisten Support-Teams werden keine Early Adopter eines Protokolls ohne Spezifikation sein. Die nützliche Arbeit liegt auf Ihrer Seite der Tür, und sie ist dieselbe, ob der Standard am Ende PAP, PACT oder beides ist. Die Agenten von Kunden erreichen Warteschlangen schon jetzt über Chat, E-Mail und Telefon, wie OpenAI dots für den Kundensupport und Instinct für den Kundensupport zeigen. Ich würde es in dieser Reihenfolge angehen:
- Listen Sie jede Aktion auf, die Ihre Support-KI ausführen kann. Ordnen Sie jede als Lesen, umkehrbares Schreiben, Geldbewegung oder Kontosteuerung ein. Die meisten Teams haben das nie aufgeschrieben, und es wird Ihre Scope-Liste.
- Setzen Sie Freigaben auf Geld und Kontoänderungen. Eine Rückerstattung ist eine Rückerstattung, egal ob ein Mensch oder ein Agent sie verlangt. Die Leitfäden zu Zendesk Advanced AI Actions und Gorgias AI Actions zeigen, was native Tools absichern können.
- Zählen Sie Ihren Agenten-Traffic. Markieren Sie Gespräche, die von Agenten zu stammen scheinen, und messen Sie den Anteil, bevor Sie Erkennung kaufen. Sierra selbst sagt, ein Unternehmen mit hohem Volumen „might start by measuring how often it happens“.
- Schreiben Sie die Eskalation mit zwei Ausgängen. Ihre KI sollte an einen Menschen übergeben und außerdem sagen, was sie vom Agenten des Kunden braucht. Der Leitfaden zum KI-Eskalationsmanagement behandelt die menschliche Seite.
- Halten Sie einen Zugang für APIs offen. Wenn Sie bereits eine KI-Kundenservice-API oder Helpdesk-API veröffentlichen, ist das Tür Nummer zwei. Begrenzen Sie sie, bevor Sie sie bewerben.
- Spielen Sie vergangene Tickets vor dem Livegang durch. Lassen Sie echte Rückerstattungs- und Kündigungstickets gegen Ihre KI laufen und sehen Sie, wo sie nachgibt. Der Agent eines Kunden findet die weiche Stelle schneller als jeder Kunde.
Der sechste Punkt hat eine Erfahrung im Rücken. Ein Support-Leiter sagte in einem Verkaufsgespräch eesel, was er von einer KI brauche, bevor er ihr vertraue:
"I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."
A CX lead at a DTC supplements brand on Gorgias and Shopify, about 7,000 tickets a month
Dieser Satz ist eine Scope-Definition in einfachen Worten. Er ist auch der richtige Test für einen persönlichen Agenten am anderen Ende: Wenn Ihre KI nicht sagen kann „das hier ist nicht meins“, kann sie einem Agenten, der auf fünf verschiedene Arten fragt, nicht sicher begegnen.
Handelsteams haben noch eine Aufgabe. Wenn Sie Shopify nutzen, das auf der Partnerliste steht, zeigen der Leitfaden zu Shopify-Strategien für KI-Kundenservice und Muse für den Shopify-Kundensupport, wie Agenten diese Warteschlangen schon erreichen. Zu Metas Seite der Geschichte siehe Meta Muse für den Kundensupport.
Wo steht eesel?
Ich sage offen, wo die Grenzen liegen. eesel erkennt keine persönlichen Agenten und implementiert weder PAP noch PACT oder A2A. Wenn Sie einen Anbieter brauchen, der einen Agent-zu-Agent-Kanal mit vom Kunden erteilten Scopes baut, sind Sierra und Decagon die beiden, die Sie sich ansehen sollten. Der Vergleich Decagon vs Sierra und die Übersicht Sierra-Alternativen zeigen die Abwägungen. Wenn v0.1 veröffentlicht ist, lese ich es gegen das, was eesel kann, und schreibe die Lücke auf, statt sie jetzt zu raten.
Was eesel leistet, ist die Berechtigungsschicht im Helpdesk, den Sie bereits betreiben. Das KI-Helpdesk-Teammitglied stößt wie ein neuer Mitarbeiter zu Zendesk, Freshdesk oder Gorgias. Jede Aktion, die es ausführen kann, steht auf Auto, Freigabe nötig oder Deaktiviert, gruppiert in Lesen und Schreiben, laut eesels Aktions-Dokumentation. Sie können es in einfachen Worten sagen: „Schlag Dinge selbstständig nach, aber frag mich vor jeder Rückerstattung.“
Das ist dieselbe Trennung in Lesen und Schreiben, die die Protokolle formalisieren, nur auf Ihre eigene KI gerichtet. Sollte PAP mit Limits pro Aktion kommen, sind das die Einstellungen, auf die ich sie abbilden würde. Und weil die Protokolle von APIs und MCP sprechen, noch ein Detail: Jeder eesel-Workspace ist auch ein MCP-Server, und die eesel CLI steuert dasselbe Teammitglied vom Terminal aus. Ein Coding-Agent wie Claude Code kann eesel integrations <platform> actions ausführen, um jede Aktion und ihre Freigabe-Einstellung zu sehen, oder eesel approvals, um zurückgehaltene Aktionen zu genehmigen oder abzulehnen. Die CLI folgt denselben Berechtigungen wie das Dashboard, eine auf „Freigabe nötig“ gesetzte Schreibaktion bleibt also zurückgehalten, bis ein Mensch sie genehmigt.
Was sagen die Leute?
Die öffentliche Reaktion auf PAP selbst ist noch dünn, was drei Tage nach dem Start verständlich ist. Die größere Debatte über Agenten, die den Support kontaktieren, ist lauter. Auf Hacker News kam der nützlichste Kommentar, den ich fand, von der Kundenseite des Tisches:
"The solution for both sides is for the companies to implement support bots that have more power to address my problem than the humans they replaced were ever given."
Stellen Sie daneben Simon Taylors Einschätzung von PAP auf X, wo er es eine Alternative zum Blockieren nannte und sagte, ein Unternehmen könne es „recognize it, give it read-only by default, and route anything that moves money to your own agent“. Das ist seine Interpretation, nicht Sierras Wortlaut, aber es ist die Version, auf die ich hinarbeiten würde. Blockieren weist den Kunden ab, und eine offene Tür ohne Grenzen ist schlimmer. Die Scopes sind es, die beiden Seiten etwas bringen.
eesel ausprobieren
Wenn die Agenten Ihrer Kunden bald in Ihrer Warteschlange Rückerstattungen verlangen, ist die erste Aufgabe zu entscheiden, wozu Ihre eigene KI Ja sagen darf. Das KI-Helpdesk-Teammitglied von eesel verbindet sich mit Zendesk, Freshdesk oder Gorgias, lernt aus Ihren vergangenen Tickets und dem Help Center und hält Rückerstattungen und Kündigungen hinter einer Freigabe, bis Sie gesehen haben, dass es die Linie hält. Sie können es in einer Simulation an vergangenen Tickets laufen lassen, bevor es einen Kunden berührt.
Der kostenlose Tarif enthält 100 Credits und jede Integration, und bezahlte Tarife beginnen bei 299 $ im Monat für 500 Credits, wobei ein Ticket oder ein Chat 1 Credit kostet, auf der eesel-Preisseite. Testen Sie eesel an Ihrer eigenen Warteschlange.