Personal Agent Protocol (PAP) : ce que Sierra et Meta ont publié jusqu'ici

Qu'est-ce que le Personal Agent Protocol ?

Je construis des intégrations pour eesel, donc quand un standard promet de dire comment un agent "authenticates with and acts on" une entreprise, je le lis comme un contrat d'API : ce qui est défini et ce qui n'est qu'une phrase d'intention. L'annonce de Sierra est surtout de l'intention, mais l'intention est précise.

Les agents personnels sont les assistants qui travaillent pour un consommateur, comme Meta Muse, Instinct et OpenAI dots. Aujourd'hui, dit Sierra, la plupart "use websites and apps the way people do" et, quand cela échoue, ils appellent la ligne de support ou ouvrent le chat web. PAP vise à remplacer cela par une connexion directe et autorisée. Trois parties veulent des choses différentes de lui :

• Les consommateurs veulent de la rapidité, de la fiabilité et de la confiance.
• Les marques veulent de la visibilité et du contrôle : savoir quand un agent personnel agit pour un client et décider de ce qu'il peut faire.
• Les concepteurs d'agents veulent une façon cohérente de travailler avec les entreprises participantes.

Les partenaires nommés dans la publication de Sierra sont Genesys, Instinct, Rocket, Shopify, Stripe et Walmart, aux côtés de Meta et Sierra. Kevin Miller, de Stripe, a présenté clairement le côté entreprise :

"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."

Kevin Miller, Stripe

Comment fonctionne une session PAP ?

Voici le déroulé tel que Sierra le décrit, étape par étape. Le protocole commence sur le site web, où un agent personnel peut découvrir ce que l'entreprise propose et comment la joindre. L'agent ouvre ensuite une session pour son utilisateur, et la session peut démarrer en invité. Une session invité peut suffire pour vérifier la disponibilité d'un produit ou s'informer sur une politique de retour.

Quand la tâche exige l'accès au compte, le client se connecte sur la page de l'entreprise ou utilise des identifiants déjà configurés avec son agent. Le client décide si l'agent obtient un accès en lecture seule ou en écriture. La session repose sur OAuth, le même standard d'autorisation que derrière "Se connecter avec Google", et traverse les canaux : une question posée avant la connexion et un changement de commande fait après ne forment qu'une seule visite.

L'entreprise choisit ensuite la porte :

C'est la troisième porte que les équipes support devraient regarder. La publication de Sierra dit elle-même que l'agent de l'entreprise gère des "tasks that need conversation", et un agent d'entreprise sur un helpdesk, c'est exactement cela. Meta Business Agent, que David Singleton cite dans sa publication, est la version de Meta de la même idée côté entreprise. Ma lecture : PAP est un standard de porte d'entrée, et ce qui se tient derrière la porte reste vos politiques et votre flux de travail de service client par IA.

Une chose de plus à dire tout haut : Sierra, Genesys et Decagon vendent tous des agents côté entreprise ou des logiciels de centre de contact, donc la porte "agent de l'entreprise" est aussi leur terrain commercial. Cela ne rend pas l'idée fausse. Cela signifie en revanche qu'il faut lire "ouvert" comme "spécification ouverte" et regarder qui écrit la première implémentation de référence.

Qu'est-ce qui est réellement livré et qu'est-ce qui n'est que promis ?

C'est la partie que la plupart des articles ont sautée, donc je l'ai suivie par date. Tout ce qui suit renvoie à la page de l'éditeur lui-même.

Lisez la dernière ligne deux fois. L'annonce énonce le principe que "companies set parameters for what those agents can do", mais les contrôles plus fins, permettant aux clients et aux entreprises de limiter des actions précises, sont décrits comme du travail futur. Le PAP d'aujourd'hui vous donne donc trois choses sur le papier : session invité contre session connectée, accès en lecture contre écriture, et votre choix de porte. Les limites par action ne figurent pas dans la première version telle que décrite.

Sierra admet aussi la faille qui compte le plus pour une équipe support. Dans sa publication sur fleming-1, elle dit que lorsqu'un agent utilise le protocole, "the company knows it's an agent and who it's acting for", puis ajoute : "Of course, some agents may not respect the protocol." C'est pourquoi Sierra a livré fleming-1 deux jours plus tard, un modèle qui note en temps réel la voix d'un appelant à la recherche d'indices qu'elle a été générée par une IA. Sierra dit qu'il est "tuned to be conservative by default, so real people don't inadvertently get flagged" et qu'il sert à informer, pas à rendre un verdict.

Qui en fait partie et qui manque ?

La liste des partenaires dépend de qui vous interrogez, et je pense qu'elle mérite un tableau, car les différences sont toute l'histoire. J'ai vérifié chaque source directement.

La liste de Singleton ajoute NiCE et Decagon et omet Instinct, alors que celle de Sierra a Instinct mais ni NiCE ni Decagon. Le plus probable est que le groupe de travail ait grandi en deux jours, ce à quoi l'on s'attend pour un standard en brouillon. Aucune des quatre publications ne nomme OpenAI, Anthropic, Amazon, Google, Zendesk ni Salesforce. Amazon est le plus important pour le commerce : il a bloqué Muse de Meta sur son site de vente en septembre, et un commentateur sur X a résumé le coût sans détour.

"Nobody asked the person whose agent stopped working."

Ryan Sarver, X

La réaction sur X au lancement a été mitigée. Une réponse à la publication de Stripe ressemble à une bonne part du scepticisme du secteur que j'ai vu :

"like you read the PACT announcement and released this with no spec?"

Jeff Schneider, X

C'est une supposition sur les motivations, et la publication de Sierra ne le dit pas. Mais les dates concordent : le code de PACT est devenu public le 6 octobre, le jour même où PAP a été annoncé sans spécification.

Comment PAP se rapporte-t-il à PACT ?

PACT est le cousin le mieux défini, donc il vaut la peine de le comprendre. PACT signifie Personal Agent Consent & Trust. Decagon l'a co-développé avec Instinct, et le dépôt ouvert contient la spécification, des schémas TypeScript, un fournisseur de référence, un agent personnel de démonstration et des tests de conformité, le tout sous Apache-2.0.

Il fonctionne en trois étapes :

1. Découvrir et connecter. L'agent personnel lit l'A2A Agent Card de l'entreprise, qui liste le endpoint, la façon de s'authentifier et les scopes proposés, comme orders:read ou orders:cancel. L'agent signe chaque requête avec un JWT de courte durée, pour que le fournisseur puisse vérifier quelle plateforme appelle.
2. Authentifier le client. L'agent demande des scopes via le flux d'autorisation d'appareil d'OAuth et montre au client un lien de connexion. Le client se connecte directement auprès de l'entreprise et approuve les autorisations. L'agent ne voit jamais le mot de passe.
3. Agir dans les limites de la délégation. Chaque requête porte à la fois l'identité de l'agent et la délégation du client, et les réponses incluent des reçus signés qui consignent les scopes utilisés et les actions effectuées.

Le choix de conception de PACT que j'aime le plus est la séparation de l'identité et de l'autorité : "Verify which agent is calling independently of what the customer has permitted it to do." Un répondant sur X a signalé pourquoi cela compte pour OAuth simple :

"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."

Mike Moore, X

PACT y répond avec des JWT d'agent signés et des jetons de délégation de courte durée. L'annonce de PAP ne dit pas encore comment il traite cela, une raison de plus pour laquelle le texte de la v0.1 compte. Pour le produit construit sur PACT, y compris la détection et l'exemple de la compagnie aérienne, voir mon analyse précédente du Decagon Personal Agent Gateway. Une correction à cet article : il disait que la spécification de PACT n'était pas publique. Elle l'est maintenant, le dépôt ayant été publié le 6 octobre.

Comment PAP se compare-t-il aux autres protocoles ?

La réponse honnête est que ces protocoles répondent surtout à des questions différentes, et la comparaison est déséquilibrée parce que seuls certains ont un texte lisible. C'est le tableau dont je ferais une capture d'écran.

Deux choses ressortent. D'abord, PAP vise la ligne que personne n'a terminée : consentement et scope entre l'agent d'un consommateur et une entreprise, sur tous les canaux. Ensuite, rien dans la ligne des paiements ne parle au support. Le protocole de Visa utilise des signatures liées au domaine et à l'opération précise, et le score de Mastercard indique si une transaction a été initiée par une IA. Aucun ne dit à votre helpdesk que l'agent d'un client veut un remboursement. La publication de Sierra liste elle-même les "payments extensions" comme travail futur de PAP, ce qui indique où les familles de protocoles pourraient finir par se rejoindre. Si vous vendez en ligne, l'agentic commerce protocol et la version de Stripe sont le côté paiement de la même histoire.

Quel protocole couvre votre cas ?

Choisissez la tâche qui vous importe. Le widget montre quel standard y répond, son niveau de maturité et ce que je ferais maintenant.

Que doit faire une équipe support avant l'arrivée de la spécification ?

La plupart des équipes support ne seront pas des adoptantes précoces d'un protocole sans spécification. Le travail utile se fait de votre côté de la porte, et il est le même que le standard retenu soit PAP, PACT ou les deux. Les agents des clients atteignent déjà les files par chat, e-mail et téléphone, comme le montrent OpenAI dots pour le support client et Instinct pour le support client, donc je procéderais dans cet ordre :

1. Listez chaque action que votre IA de support peut effectuer. Classez chacune en lecture, écriture réversible, mouvement d'argent ou contrôle de compte. La plupart des équipes ne l'ont jamais écrit, et cela devient votre liste de scopes.
2. Mettez des approbations sur l'argent et les changements de compte. Un remboursement reste un remboursement, qu'une personne ou un agent le demande. Les guides sur les actions IA avancées de Zendesk et les actions IA de Gorgias montrent ce que les outils natifs savent contrôler.
3. Comptez votre trafic d'agents. Étiquetez les conversations qui semblent envoyées par des agents et mesurez la part avant d'acheter de la détection. Sierra dit elle-même qu'une entreprise à fort volume "might start by measuring how often it happens".
4. Écrivez l'escalade avec deux sorties. Votre IA doit passer la main à une personne et dire aussi ce dont elle a besoin de la part de l'agent du client. Le guide de gestion de l'escalade par IA couvre le côté humain.
5. Gardez une entrée pour les API. Si vous publiez déjà une API de service client IA ou une API de helpdesk, c'est la porte numéro deux. Limitez son périmètre avant de la faire connaître.
6. Rejouez d'anciens tickets avant la mise en production. Faites passer de vrais tickets de remboursement et d'annulation sur votre IA et voyez où elle cède. L'agent d'un client trouvera le point faible plus vite que n'importe quel client.

Le sixième point a une cicatrice derrière lui. Un responsable support a dit à eesel, lors d'un appel commercial, ce qu'il attendait d'une IA avant de lui faire confiance :

"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

Cette phrase est une définition de périmètre en mots simples. C'est aussi le bon test pour un agent personnel en face : si votre IA ne sait pas dire "celui-ci n'est pas pour moi", elle ne peut pas rencontrer en sécurité un agent qui posera la question de cinq façons différentes.

Les équipes e-commerce ont une tâche de plus. Si vous utilisez Shopify, qui figure dans la liste des partenaires, le guide des stratégies de service client par IA sur Shopify et Muse pour le support client Shopify montrent comment les agents atteignent déjà ces files. Pour le côté de Meta, voir Meta Muse pour le support client.

Où se situe eesel ?

Je serai direct sur les limites. eesel ne détecte pas les agents personnels et n'implémente ni PAP, ni PACT, ni A2A. Si vous avez besoin d'un fournisseur qui construit un canal d'agent à agent avec des scopes accordés par le client, Sierra et Decagon sont les deux à examiner, et la comparaison Decagon vs Sierra et le panorama des alternatives à Sierra exposent les compromis. Quand la v0.1 sera publiée, je la lirai face à ce que fait eesel et j'écrirai l'écart, au lieu de le deviner maintenant.

Ce que fait eesel, c'est la couche d'autorisations sur le helpdesk que vous utilisez déjà. Le coéquipier IA de helpdesk rejoint Zendesk, Freshdesk ou Gorgias comme un nouvel embauché. Chaque action qu'il peut effectuer est réglée sur Auto, Approbation requise ou Désactivée, regroupée en Lecture et Écriture, selon la documentation des actions d'eesel. Vous pouvez le dire en mots simples : "consulte les choses toi-même, mais demande-moi avant tout remboursement".

C'est la même séparation lecture contre écriture que les protocoles formalisent, appliquée à votre propre IA. Si PAP arrive avec des limites par action, ce sont les réglages auxquels je les associerais. Et puisque les protocoles parlent d'API et de MCP, un détail de plus : chaque espace de travail eesel est aussi un serveur MCP, et la CLI eesel pilote le même coéquipier depuis un terminal. Un agent de code comme Claude Code peut exécuter eesel integrations <platform> actions pour voir chaque action et son réglage d'approbation, ou eesel approvals pour approuver ou refuser des actions retenues. La CLI suit les mêmes autorisations que le tableau de bord, donc une écriture réglée sur "approbation requise" reste retenue jusqu'à ce qu'une personne l'approuve.

Que disent les gens ?

La réaction publique à PAP lui-même est encore mince, ce qui se comprend trois jours après le lancement. Le débat plus large sur les agents qui contactent le support est plus bruyant. Sur Hacker News, le commentaire le plus utile que j'ai trouvé venait du côté client de la table :

"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."

CamperBob2, Hacker News

Mettez cela à côté de la lecture de PAP par Simon Taylor sur X, où il l'a présenté comme une alternative au blocage et a dit qu'il permet à une entreprise de "recognize it, give it read-only by default, and route anything that moves money to your own agent". C'est son interprétation, pas la formulation de Sierra, mais c'est la version vers laquelle je construirais. Bloquer repousse le client, et une porte ouverte sans limites est pire. Ce sont les scopes qui permettent aux deux côtés d'y gagner.

Essayer eesel

Si les agents de vos clients s'apprêtent à demander des remboursements à votre file, la première tâche est de décider à quoi votre propre IA peut dire oui. Le coéquipier IA de helpdesk d'eesel se branche sur Zendesk, Freshdesk ou Gorgias, apprend de vos anciens tickets et de votre centre d'aide, et garde les remboursements et les annulations derrière une approbation jusqu'à ce que vous l'ayez vu tenir la ligne. Vous pouvez l'exécuter sur d'anciens tickets dans une simulation avant qu'il ne touche un client.

Le plan gratuit inclut 100 crédits et toutes les intégrations, et les plans payants démarrent à 299 $ par mois pour 500 crédits, où un ticket ou un chat vaut 1 crédit, sur la page de tarifs d'eesel. Essayez eesel sur votre propre file.