Ce que Decagon a réellement lancé
Decagon a annoncé le gateway lors de son événement Dialogues 2026, parmi quatre nouveautés, aux côtés de Decagon Voice 3, d'Agent Modules et de Duet Apprentice.
Le billet de lancement, signé des cofondateurs Jesse Zhang et Ashwin Sreenivas, commence par la raison : en un seul mois, Meta a lancé Muse, OpenAI a présenté dots et Instinct a commencé à passer des appels téléphoniques pour ses utilisateurs.
Ce sont des agents personnels. Ils travaillent pour un consommateur, pas pour une entreprise, et ils "réservent, achètent, résilient et négocient" pour le compte de leur propriétaire. Quand ils arrivent dans une file de support, ils tombent généralement sur l'agent IA de service client de la marque. Il y a donc maintenant un agent aux deux bouts de la conversation. Et cela se passe déjà sur de vraies lignes téléphoniques :
"This week, Muse called customer service on my behalf. It navigated the phone tree, waited on hold, spoke with a human rep, and resolved the issue (worked great!)."
Le gateway, c'est deux fonctionnalités et un protocole :
| Élément | Ce qu'il fait | Pour qui |
|---|---|---|
| Détection des agents personnels | Signale les agents personnels probables dans le chat en direct et la voix | Les agents qui ne disent pas qu'ils sont des agents |
| Canal des agents personnels | Un canal dédié à côté du chat, de l'e-mail et de la voix, avec ses propres Agent Operating Procedures (AOPs) | Les agents qui s'identifient |
| PACT (Personal Agent Consent & Trust) | Un protocole pour qu'un agent prouve qui il représente et ce que cette personne a autorisé | Fournisseurs d'agents personnels et entreprises |
Je construis des intégrations pour vivre chez eesel, et ma première lecture a été que c'est surtout un produit d'autorisation déguisé en détection. C'est un compliment. La détection fait les gros titres, mais ce sont les scopes que l'on déploierait vraiment.
Pourquoi les agents personnels font voler en éclats les politiques de support
Voici la phrase du billet de Decagon à laquelle je reviens sans cesse. Une personne à qui l'on refuse un remboursement "might ask once more and let it go". Un agent personnel "might ask for a refund once, or keep trying different approaches to maximize the concession."
Tout le problème tient en deux phrases. La plupart des politiques de remboursement et d'exception s'appuient discrètement sur la patience humaine. Le client qui aurait besoin de quatre essais pour obtenir une exception s'arrête généralement au deuxième. Un agent ne se fatigue pas, ne se sent pas gêné et n'a pas d'autre endroit où être. L'avis le plus partagé à ce sujet sur X a résumé l'économie sans détour :
"AI agents reduce the cost of complaints/requests to ~ zero. Anything free is consumed at much higher rates, so we should expect the total volume of this category to explode."
Je vois le même schéma de l'autre côté, dans les files eesel avec lesquelles je travaille. Un administrateur support d'eesel a passé une session à apprendre une seule règle à l'agent Zendesk d'eesel, et il l'a mieux formulée que je ne pourrais :
"I have a rule in CS where we do not address a cancel or refund request when there is an issue attached to it."
A digital-media support admin encoding a "troubleshoot before you cancel" policy into a Zendesk AI agent
Cette règle fonctionne avec un humain parce qu'un humain accepte le dépannage. Un agent personnel à qui l'on a dit "obtiens-moi un remboursement" essaiera de la contourner. Si votre agent de support IA se laisse convaincre d'abandonner une règle au cinquième essai, il n'a jamais eu cette règle. C'est pourquoi l'IA pour les demandes de remboursement se joue sur ce que l'agent a le droit de faire, pas sur la politesse de son refus.
Decagon relève un second problème : la permission. "Permission to check a balance doesn't necessarily mean permission to move money." Aujourd'hui, si l'agent de quelqu'un appelle avec les bonnes informations de compte, la plupart des piles de support ne peuvent pas savoir ce que le client a réellement approuvé.
Comment fonctionne le Personal Agent Gateway
Decagon articule la conception autour de quatre points qu'une entreprise doit réussir : identification, accès, autorisation et résolution. Voici comment chacun se traduit dans le produit.
Identification : détection et auto-identification
La plupart des agents aujourd'hui appellent ou ouvrent un chat comme n'importe qui. Decagon dit que la détection combine des signaux de l'entreprise, comme les empreintes d'appareil et l'historique du compte, avec des signaux de la plateforme de support, comme les schémas de conversation et le rythme des requêtes. Le signalement fonctionne dans le chat en direct et la voix. La suite relève de l'entreprise.
La nuance à noter : Decagon ne présente pas la détection comme la barrière principale. Elle fonctionne "best alongside an easy way for agents to identify themselves upfront", elle n'a donc qu'à attraper ceux qui ne s'annoncent pas. La détection est le filet de secours. Le canal est le plan. Ma lecture : c'est la même logique qui a poussé le paiement vers un protocole de commerce agentique. Une porte d'entrée pour agents passe mieux à l'échelle que de deviner qui est un bot.
Accès : un canal réservé aux agents
Les agents qui s'identifient accèdent au canal des agents personnels. Il se place à côté du chat, de l'e-mail et de la voix, avec des AOPs distincts. Les AOPs sont les workflows de Decagon pour son agent IA, et je les ai détaillés davantage dans le test de Decagon.
Concrètement, la même demande peut suivre une logique différente selon l'auteur. Une demande de remboursement d'une personne peut prendre un chemin ; celle d'un agent, un autre. Les demandes moins sensibles peuvent réutiliser les workflows existants sans configuration supplémentaire, ce qui compte, car personne ne veut maintenir deux copies de chaque politique. L'autre point de Decagon passe facilement inaperçu : un canal pour tous les fournisseurs d'agents signifie que vous ne construisez pas une intégration pour Muse, une autre pour dots et une autre pour Instinct.
Autorisation : des scopes dans les AOPs
C'est la partie que je lirais deux fois. Decagon place les permissions dans les AOPs : l'entreprise définit les scopes qu'un agent peut demander et indique quelles sections exigent chacun. Sans le scope, "those sections are never exposed to the agent". C'est le modèle OAuth que vous connaissez déjà quand vous connectez une appli à votre compte Google, appliqué à une conversation de support. Si vous avez déjà configuré des scopes de l'API Zendesk, la forme vous sera familière.
L'exemple de Decagon est une compagnie aérienne :
Le voyageur accorde la consultation mais pas la modification. L'agent de la compagnie partage des options plus tôt mais ne peut pas effectuer le changement, donc l'agent personnel retourne voir son propriétaire pour obtenir la permission manquante. Decagon dit aussi que l'octroi "creates a record of what the customer authorized", ce qui permet à l'entreprise de le prouver plus tard. Pour un responsable support qui a déjà dû démêler un changement contesté, cette piste d'audit est la vraie fonctionnalité.
Cela répond aussi à l'inquiétude des consommateurs de leur côté. Sur Reddit, un utilisateur de Muse demandait comment cela pourrait fonctionner alors que son assureur et son opérateur exigent toujours d'abord des informations personnelles :
"...for that to all I have to hand those info (social, address, DOB, etc.) directly into Muse memory as plain text without a secure credential layer, or the customer service might just hand off knowing it's an AI calling?"
Des permissions à portée limitée, accordées par le client, sont la "secure credential layer" que réclame cet utilisateur.
Résolution : empêcher deux agents de tourner en boucle
"Two agents can loop forever if neither is built to stop." La réponse de Decagon : l'agent de l'entreprise tient sa position sur la politique tout en restant utile, et l'escalade fonctionne dans les deux sens : l'agent de l'entreprise peut avoir besoin d'un humain, et l'agent personnel de son propriétaire. Si vous avez déjà réglé des règles d'escalade par IA, c'est le même muscle avec une seconde sortie. Cela change aussi la mesure : le taux de résolution autonome et la qualité d'escalade incluent désormais le renvoi d'une demande vers l'agent de quelqu'un d'autre.
Ce que PACT ajoute à A2A
PACT est l'abréviation de Personal Agent Consent & Trust. Selon Decagon, il "builds on the Agent2Agent protocol", qui gère la façon dont les agents se trouvent et échangent des messages, et ajoute une "delegated authorization built on OAuth 2.0". En clair : A2A fait parler les deux agents, et PACT permet à l'agent personnel de prouver de quel client il dépend et ce qu'il peut faire. C'est un travail différent du MCP pour le support client, qui relie une IA à des outils plutôt qu'à un autre agent.
Cette répartition se comprend quand on lit la spécification A2A. Les agents se présentent avec une agent card à /.well-known/agent-card.json, mais la spécification A2A laisse l'autorisation à la discrétion de chaque implémentation. Quelque chose doit combler ce vide pour les demandes de consommateur à entreprise, et PACT est la proposition de Decagon. A2A lui-même bénéficie d'un vrai soutien : le 27 août 2026, il est devenu un projet de stade Growth à l'Agentic AI Foundation, avec plus de 150 organisations derrière lui.
Deux points à garder en tête avant de chercher de la documentation :
- Le nom PACT est déjà pris deux fois. Cloudflare a annoncé un autre PACT, les Private Access Control Tokens, avec Mozilla, Google, Microsoft et Shopify en juin 2026. Il s'agit de prouver qu'une personne est derrière l'écran sur le web, pas du consentement dans le support.
- La spécification n'est pas facile à trouver. Le récapitulatif Dialogues de Decagon dit "the specification is available today", mais au 6 octobre aucun des deux billets de lancement n'y renvoie et je n'en ai pas trouvé de copie publique. Je ne peux donc pas vous donner de noms de champs, de points de terminaison ni la façon dont les enregistrements d'octroi sont stockés. Decagon dit qu'il travaille "working with personal agent providers" pour la façonner.
Decagon n'est pas seul sur ce terrain. Le 30 septembre, Mastercard a annoncé un score de probabilité qu'un paiement ait été initié par un agent IA, en test aux États-Unis. C'est de la détection au niveau du paiement. Decagon est le premier que je vois viser la même idée sur la conversation de support elle-même. Des concurrents comme Sierra n'ont rien annoncé de comparable à ce jour, ce qui crée une vraie différence dans la comparaison Decagon vs Sierra.
Ce qu'on ignore encore
Decagon est clair sur la conception et discret sur les détails qu'un acheteur demanderait. Voici l'état des lieux honnête au 6 octobre 2026 :
| Question | Ce que Decagon a publié |
|---|---|
| Prix | Rien. La page /pricing de Decagon renvoie une 404 et tout passe par une démo |
| Disponibilité | Aucune mention de GA, de bêta ou de formule. L'appel à l'action est "Talk to our team" |
| Canaux de détection | Chat en direct et voix |
| Le canal des agents est à côté de l'e-mail, mais la détection n'est décrite que pour le chat et la voix | |
| Spécification | Décrite comme disponible, non liée publiquement |
| Fournisseurs d'agents inscrits | Aucun cité comme adoptant de PACT. Instinct, Muse et dots sont cités comme exemples d'agents qui contactent déjà le support |
| Précision de la détection | Aucun chiffre. Decagon dit que la détection "will keep improving as personal agents evolve" |
Rien de tout cela n'est inhabituel pour une fonctionnalité lancée par un éditeur enterprise, et l'histoire des tarifs de Decagon a toujours été pilotée par la vente. Mais cela signifie que le gateway est une direction, pas un produit que l'on peut chiffrer aujourd'hui, et cela alimente directement la question plus large de savoir si Decagon en vaut la peine. Le canal d'auto-identification, en particulier, ne portera ses fruits que quand les fabricants d'agents adopteront le protocole, et aucun n'a dit publiquement qu'il le ferait.
Ce que disent les gens
La réaction publique au gateway lui-même est mince pour l'instant, ce qui se comprend cinq jours après le lancement. Le débat plus large dans lequel il s'inscrit est en revanche bruyant. Sur Hacker News, le fil de lancement d'OpenAI dots s'est transformé en discussion sur exactement ce sujet :
"All this outsourcing of human interaction to agents is going to get locked down. Customer service relies on people not overabusing it, and that trust is getting abused by agents."
Et la réponse qui explique pourquoi les consommateurs enverront des agents malgré tout :
"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. I have a feeling it's not going to work out that way, though."
Bloquer est l'autre réflexe, et il a un coût. Comme l'a dit Ryan Sarver après qu'Amazon a bloqué Muse sur son site de vente, "Nobody asked the person whose agent stopped working" (Ryan Sarver, X).
Ensemble, ces commentaires forment tout le cahier des charges du gateway. Les entreprises doivent freiner les abus, les clients veulent que leur agent obtienne vraiment des résultats, et les permissions à portée limitée sont la seule version où chaque camp y gagne. Si l'agent de l'entreprise peut dire oui à davantage de choses, en sécurité, l'agent du client a moins de raisons d'insister.
Comment préparer votre équipe support, avec ou sans Decagon
La plupart des équipes support qui lisent ceci n'utilisent pas Decagon et ne le feront pas dans le budget 2026. La bonne nouvelle : la partie difficile du gateway est un exercice de permissions que vous pouvez faire sur n'importe quelle pile. Des agents comme Instinct et Meta Muse atteindront votre file par les mêmes lignes e-mail, chat et téléphone que les personnes, que vous ayez acheté quoi que ce soit ou non. Si vous assurez le support sur WhatsApp ou Messenger, Meta Muse pour le support client explique ce que font les outils professionnels de Meta.
Choisissez ci-dessous un type de demande pour voir comment je l'encadrerais.
Voici la version courte sous forme de liste :
- Faites l'inventaire de vos actions. Listez chaque action de votre workflow de service client par IA et classez chacune en lecture, écriture réversible, mouvement d'argent ou contrôle du compte. La plupart des équipes ne l'ont jamais écrit.
- Contrôlez par niveau, pas par canal. Un remboursement reste un remboursement, qu'il vienne d'une personne, d'un bot ou d'un appel. Mettez d'abord les approbations sur le niveau mouvement d'argent. Les guides sur les actions IA avancées de Zendesk et les actions IA de Gorgias montrent ce qui est configurable en natif.
- Écrivez des politiques qui résistent à la répétition. Relisez chaque règle d'exception et demandez-vous : tiendrait-elle à la cinquième demande ? Si la réponse honnête est "ça dépend de qui demande", resserrez-la.
- Donnez deux sorties à l'escalade. Votre IA doit passer la main à une personne proprement et dire clairement ce dont elle a besoin du client quand un agent n'a pas la permission. Côté humain, voir les bonnes pratiques de transfert à un humain.
- Testez sur d'anciens tickets avant la mise en service. Rejouez de vrais tickets de remboursement et de résiliation et repérez où votre IA cède. C'est moins cher que de l'apprendre d'un agent qui ne lâche rien.
Le quatrième point a laissé une cicatrice chez moi. J'ai un jour vu une configuration autonome de rédaction casser son propre chemin d'escalade chez un client de médias numériques : l'e-mail d'escalade a été fermé automatiquement, si bien qu'aucune personne ne l'a jamais vu. Rien n'a été escaladé et personne ne le savait. Deux agents qui se parlent trouveront ce genre de failles plus vite que n'importe quel client, et c'est pourquoi chaque déploiement eesel est désormais simulé d'abord sur des tickets historiques.
Où eesel s'intègre
Soyons francs d'abord sur les limites. eesel ne détecte pas les agents personnels et n'implémente ni Agent2Agent ni PACT. Si vous avez besoin dès aujourd'hui d'un canal enterprise d'agent à agent avec des scopes accordés par le client, Decagon est l'éditeur qui le construit, et le comparatif des alternatives à Decagon montre qui est proche.
Ce que fait eesel, c'est la couche de permissions en dessous, sur le helpdesk que vous utilisez déjà. Le coéquipier IA pour helpdesk rejoint Zendesk, Freshdesk ou Gorgias comme un nouvel embauché, à côté de Zendesk AI natif ou à sa place. Chaque action qu'il peut effectuer, d'ajouter une étiquette à émettre un remboursement, est réglée sur Auto, Approbation requise ou Désactivée, regroupées en Lecture et Écriture, d'après les docs des actions d'eesel.
C'est la même séparation lecture et écriture que font respecter les scopes de Decagon, mais tournée vers votre propre IA plutôt que vers celle du client. Donc, quelle que soit la personne au bout du ticket, un humain ou son agent, vous pouvez laisser eesel rechercher seule la commande et lui faire attendre un humain avant tout mouvement d'argent. Vous pouvez le régler avec des mots simples, comme "consulte les choses toi-même, mais demande-moi avant tout remboursement", et approuver les actions retenues depuis le tableau de bord, Slack ou la CLI eesel avec eesel approvals.
Essayer eesel
Si des agents personnels s'apprêtent à réclamer des remboursements à votre file, la première tâche est de décider à quoi votre propre IA peut dire oui. Le coéquipier IA pour helpdesk d'eesel se branche sur Zendesk, Freshdesk ou Gorgias, apprend de vos anciens tickets et de votre centre d'aide, et garde remboursements et résiliations derrière une approbation jusqu'à ce que vous ayez vu qu'il tient bon. Vous pouvez d'abord l'exécuter en simulation sur vos anciens tickets, avant qu'il ne touche un client.
L'offre gratuite inclut 100 crédits et toutes les intégrations, et les offres payantes démarrent à $299 par mois pour 500 crédits sur la page tarifs d'eesel. Essayez eesel sur votre propre file.
Comment Decagon Personal Agent Gateway détecte-t-il les agents IA ?