¿Qué es el Personal Agent Protocol?
Construyo integraciones para eesel, así que cuando un estándar promete decir cómo un agente "authenticates with and acts on" una empresa, lo leo como un contrato de API: qué está definido y qué es una frase de intención. El anuncio de Sierra es sobre todo intención, pero la intención es concreta.
Los agentes personales son los asistentes que trabajan para un consumidor, como Meta Muse, Instinct y OpenAI dots. Hoy, dice Sierra, la mayoría "use websites and apps the way people do" y, cuando eso falla, llaman a la línea de soporte o abren el chat web. PAP pretende sustituir eso por una conexión directa y autorizada. Tres partes quieren cosas distintas de él:
- Los consumidores quieren rapidez, fiabilidad y confianza.
- Las marcas quieren visibilidad y control: saber cuándo un agente personal actúa por un cliente y decidir qué puede hacer.
- Los creadores de agentes quieren una forma coherente de trabajar con las empresas participantes.
Los socios nombrados en la publicación de Sierra son Genesys, Instinct, Rocket, Shopify, Stripe y Walmart, junto con Meta y Sierra. Kevin Miller, de Stripe, planteó con claridad el lado empresarial:
"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."
¿Cómo funciona una sesión PAP?
Este es el flujo como lo describe Sierra, paso a paso. El protocolo empieza en el sitio web, donde un agente personal puede descubrir qué ofrece la empresa y cómo contactarla. Luego el agente abre una sesión para su usuario, y la sesión puede empezar como invitado. Una sesión de invitado puede bastar para comprobar la disponibilidad de un producto o preguntar por una política de devoluciones.
Cuando la tarea necesita acceso a la cuenta, el cliente inicia sesión en la página de la empresa o usa credenciales ya configuradas con su agente. El cliente decide si el agente recibe acceso de solo lectura o de escritura. La sesión se construye sobre OAuth, el mismo estándar de autorización que hay detrás de "Iniciar sesión con Google", y se mantiene entre canales, de modo que una pregunta hecha antes de iniciar sesión y un cambio de pedido hecho después son una sola visita.
Después la empresa elige la puerta:
| Puerta | Qué hace el agente | Ideal para |
|---|---|---|
| Sitio web | Navega por tus páginas normales | Estado del pedido, consulta de políticas |
| APIs (MCP, OpenAPI) | Llama a interfaces que publicas | Acciones rápidas y estructuradas |
| Agente de la empresa | Habla con tu propio agente de IA | Todo lo que requiere conversación, como una reclamación de garantía |
Esa tercera puerta es donde deberían fijarse los equipos de soporte. La propia publicación de Sierra dice que el agente de la empresa gestiona "tasks that need conversation", y un agente de empresa en un helpdesk es exactamente eso. Meta Business Agent, que David Singleton nombra en su publicación, es la versión de Meta de la misma idea en el lado empresarial. Mi lectura: PAP es un estándar de puerta de entrada, y lo que hay detrás de la puerta siguen siendo tus políticas y tu flujo de trabajo de atención al cliente con IA.
Una cosa más que conviene decir en voz alta: Sierra, Genesys y Decagon venden agentes del lado de la empresa o software de contact center, así que la puerta del "agente de la empresa" es también su terreno comercial. Eso no hace que la idea sea errónea. Sí significa que debes leer "abierto" como "especificación abierta" y comprobar quién escribe la primera implementación de referencia.
¿Qué se ha publicado realmente y qué solo se promete?
Esta es la parte que la mayoría de la cobertura se saltó, así que la seguí por fecha. Todo lo de abajo enlaza a la página del propio editor.
| Fecha | Qué | Estado |
|---|---|---|
| 6 oct. | Anuncio de Sierra y publicación de Bret Taylor | Publicado: principios, flujo, citas de socios |
| 6 oct. | Publicación de David Singleton, de Meta | Publicado: "previewing our work" |
| 6 oct. | Decagon publica PACT como código abierto | Publicado: especificación y código de referencia |
| 8 oct. | fleming-1 de Sierra | Lanzado: detecta llamantes de IA en llamadas telefónicas |
| "Later this month" | Especificación v0.1 | Prometida, no encontrada |
| Sin fecha | Talleres de diseño, implementación de referencia | Prometidos |
| Sin fecha | Límites detallados por acción, notificaciones push, extensiones de pagos | Listados como cosas que "could" llegar |
Lee la última fila dos veces. El anuncio expone el principio de que "companies set parameters for what those agents can do", pero los controles más finos, que permitirían a clientes y empresas limitar acciones concretas, se describen como trabajo futuro. Así, el PAP de hoy te da tres cosas sobre el papel: sesiones de invitado frente a sesiones iniciadas, acceso de lectura frente a escritura y tu elección de puerta. Los límites por acción no están en la primera versión tal como se describe.
Sierra también admite la brecha que más importa a un equipo de soporte. En su publicación sobre fleming-1 dice que cuando un agente usa el protocolo, "the company knows it's an agent and who it's acting for", y añade: "Of course, some agents may not respect the protocol." Por eso Sierra lanzó fleming-1 dos días después, un modelo que puntúa en tiempo real el habla de un llamante en busca de señales de que fue generada por IA. Sierra dice que está "tuned to be conservative by default, so real people don't inadvertently get flagged", y que sirve para dar información, no un veredicto.
¿Quién está dentro y quién falta?
La lista de socios depende de a quién preguntes, y creo que merece una tabla, porque las diferencias son la historia. Revisé cada fuente directamente.
| Fuente | Socios nombrados |
|---|---|
| Blog de Sierra | Genesys, Instinct, Rocket, Shopify, Stripe, Walmart (con Meta y Sierra) |
| Jeff Weinstein, Stripe | Meta, Sierra, Genesys, Instinct, Rocket, Shopify, Walmart, con Stripe como "founding members" |
| David Singleton, Meta | Genesys, NiCE, Decagon, Rocket, Shopify, Stripe, Walmart, con Muse y Meta Business Agent |
| Decagon en X | Se une al "Personal Agent Protocol working group by @Muse" |
La lista de Singleton añade NiCE y Decagon y deja fuera a Instinct, mientras que la de Sierra incluye a Instinct y no a NiCE ni a Decagon. Lo más probable es que el grupo de trabajo creciera en dos días, lo esperable en un estándar en borrador. Lo que ninguna de las cuatro publicaciones nombra es OpenAI, Anthropic, Amazon, Google, Zendesk ni Salesforce. Amazon es lo que más importa para el comercio: bloqueó a Muse de Meta en su sitio de venta en septiembre, y un comentarista en X expresó el coste sin rodeos.
"Nobody asked the person whose agent stopped working."
La reacción en X al lanzamiento fue dispar. Una respuesta a la publicación de Stripe suena como buena parte del escepticismo del sector que he visto:
"like you read the PACT announcement and released this with no spec?"
Eso es una conjetura sobre las motivaciones, y la publicación de Sierra no lo dice. Pero las fechas encajan: el código de PACT se hizo público el 6 de octubre, el mismo día en que se anunció PAP sin una especificación.
¿Cómo se relaciona PAP con PACT?
PACT es el pariente mejor definido, así que merece la pena entenderlo. PACT significa Personal Agent Consent & Trust. Decagon lo desarrolló junto con Instinct, y el repositorio abierto incluye la especificación, esquemas TypeScript, un proveedor de referencia, un agente personal de demostración y pruebas de conformidad, todo bajo Apache-2.0.
Funciona en tres pasos:
- Descubrir y conectar. El agente personal lee la A2A Agent Card de la empresa, que lista el endpoint, cómo autenticarse y los scopes disponibles, como
orders:readuorders:cancel. El agente firma cada solicitud con un JWT de corta duración, para que el proveedor pueda verificar qué plataforma llama. - Autenticar al cliente. El agente pide scopes mediante el flujo de autorización de dispositivo de OAuth y muestra al cliente un enlace de inicio de sesión. El cliente inicia sesión directamente en la empresa y aprueba los permisos. El agente nunca ve la contraseña.
- Actuar dentro de la concesión. Cada solicitud lleva tanto la identidad del agente como la delegación del cliente, y las respuestas incluyen recibos firmados que registran los scopes usados y las acciones realizadas.
Lo que más me gusta del diseño de PACT es que separa identidad de autoridad: "Verify which agent is calling independently of what the customer has permitted it to do." Alguien que respondió en X señaló por qué eso importa frente al 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."
PACT lo resuelve con JWTs de agente firmados y tokens de delegación de corta duración. El anuncio de PAP todavía no dice cómo lo gestiona, otra razón por la que importa el texto de la v0.1. Para el producto construido sobre PACT, incluida la detección y el ejemplo de la aerolínea, consulta mi análisis anterior de Decagon Personal Agent Gateway. Una corrección a esa publicación: decía que la especificación de PACT no era pública. Ahora lo es, con el repositorio publicado el 6 de octubre.
¿Cómo se compara PAP con los otros protocolos?
La respuesta honesta es que estos protocolos responden en su mayoría preguntas distintas, y la comparación es desigual porque solo algunos tienen un texto que se pueda leer. Esta es la tabla que yo capturaría.
| Protocolo | Respaldado por | Pregunta que responde | Texto público hoy | ¿Llega a los chats de soporte? |
|---|---|---|---|---|
| Personal Agent Protocol | Meta, Sierra y socios | Qué puerta, qué cliente, lectura o escritura | No, v0.1 prometida | Sí, a través de la puerta del agente de la empresa |
| PACT | Decagon, Instinct | De quién es este agente, qué scopes concedió el cliente | Sí, especificación y código en GitHub | Sí, creado para agentes de soporte |
| A2A | Agentic AI Foundation, más de 150 organizaciones | Cómo se encuentran y se envían mensajes dos agentes | Sí, especificación 1.0 | Solo transporte: la autorización es "implementation-specific" |
| MCP | Nombrado en PAP como opción de API | Cómo llama una IA a herramientas y datos | Sí | Herramientas, no consentimiento |
| Web Bot Auth | Cloudflare | Qué bot visita mi sitio | Sí | No, tráfico web |
| Trusted Agent Protocol | Visa | Es de confianza este agente de pago | Sí, con la salvedad "development and deployment" | No, pago del comerciante |
| Agent Pay probability score | Mastercard | Fue este pago iniciado por un agente de IA | Pruebas en EE. UU. | No, pagos |
| fleming-1 | Sierra | Es este llamante telefónico una IA | Función de producto, agentes de voz de Sierra | Llamadas de voz |
Destacan dos cosas. Primero, PAP apunta a la fila que nadie ha terminado: consentimiento y scope entre el agente de un consumidor y una empresa, en todos los canales. Segundo, nada en la fila de pagos habla con soporte en absoluto. El protocolo de Visa usa firmas ligadas al dominio y a la operación concreta, y la puntuación de Mastercard trata de si una transacción fue iniciada por IA. Ninguno le dice a tu helpdesk que el agente de un cliente quiere un reembolso. La propia publicación de Sierra lista las "payments extensions" como trabajo futuro de PAP, lo que indica dónde podrían encontrarse algún día las familias de protocolos. Si vendes online, el agentic commerce protocol y la versión de Stripe son el lado del pago de la misma historia.
¿Qué protocolo cubre tu caso?
Elige el trabajo que te importa. El widget muestra qué estándar lo cubre, cuán listo está y qué haría yo ahora.
¿Qué debería hacer un equipo de soporte antes de que llegue la especificación?
La mayoría de los equipos de soporte no serán adoptantes tempranos de un protocolo sin especificación. El trabajo útil está de tu lado de la puerta y es el mismo sea cual sea el estándar que acabe imponiéndose, PAP, PACT o ambos. Los agentes de los clientes ya llegan a las colas por chat, correo y teléfono, como muestran OpenAI dots para atención al cliente e Instinct para atención al cliente, así que lo haría en este orden:
- Lista cada acción que tu IA de soporte puede realizar. Clasifica cada una como lectura, escritura reversible, movimiento de dinero o control de cuenta. La mayoría de los equipos nunca lo ha puesto por escrito, y se convierte en tu lista de scopes.
- Pon aprobaciones en el dinero y en los cambios de cuenta. Un reembolso es un reembolso lo pida una persona o un agente. Las guías de acciones avanzadas de IA de Zendesk y de acciones de IA de Gorgias muestran qué pueden controlar las herramientas nativas.
- Cuenta tu tráfico de agentes. Etiqueta las conversaciones que parezcan enviadas por agentes y mide la proporción antes de comprar detección. La propia Sierra dice que una empresa de gran volumen "might start by measuring how often it happens".
- Escribe la escalada con dos salidas. Tu IA debería pasar a una persona y también decir qué necesita del agente del cliente. La guía de gestión de escaladas con IA cubre el lado humano.
- Mantén una vía de entrada para las APIs. Si ya publicas una API de atención al cliente con IA o una API de helpdesk, esa es la puerta número dos. Acota su alcance antes de anunciarla.
- Reproduce tickets pasados antes de salir en vivo. Ejecuta tickets reales de reembolso y cancelación contra tu IA y mira dónde cede. El agente de un cliente encontrará el punto débil más rápido que cualquier cliente.
El sexto punto tiene una cicatriz detrás. Un responsable de soporte le dijo a eesel en una llamada de ventas lo que necesitaba de una IA para confiar en ella:
"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
Esa frase es una definición de alcance con palabras sencillas. También es la prueba adecuada para un agente personal al otro lado: si tu IA no puede decir "este no es mío", no puede encontrarse con seguridad con un agente que preguntará de cinco maneras distintas.
Los equipos de comercio tienen una tarea más. Si usas Shopify, que está en la lista de socios, la guía de estrategias de atención al cliente con IA en Shopify y Muse para el soporte al cliente de Shopify muestran cómo los agentes ya llegan a esas colas. Para el lado de Meta, consulta Meta Muse para atención al cliente.
¿Dónde encaja eesel?
Seré directo con los límites. eesel no detecta agentes personales y no implementa PAP, PACT ni A2A. Si necesitas un proveedor que esté construyendo un canal de agente a agente con scopes concedidos por el cliente, Sierra y Decagon son los dos que debes mirar, y la comparativa Decagon vs Sierra y el resumen de alternativas a Sierra exponen las ventajas y desventajas. Cuando se publique la v0.1, la leeré frente a lo que hace eesel y escribiré la diferencia, en lugar de adivinarla ahora.
Lo que hace eesel es la capa de permisos en el helpdesk que ya usas. El compañero de IA para el helpdesk se une a Zendesk, Freshdesk o Gorgias como una nueva incorporación. Cada acción que puede realizar está configurada como Auto, Requiere aprobación o Desactivada, agrupada en Lectura y Escritura, según la documentación de acciones de eesel. Puedes decirlo con palabras sencillas: "consulta cosas por tu cuenta, pero pregúntame antes de cualquier reembolso".
Es la misma división entre lectura y escritura que formalizan los protocolos, dirigida a tu propia IA. Si PAP llega con límites por acción, estos son los ajustes a los que los asociaría. Y como los protocolos hablan de APIs y MCP, un detalle más: cada workspace de eesel es también un servidor MCP, y la CLI de eesel controla el mismo compañero desde una terminal. Un agente de programación como Claude Code puede ejecutar eesel integrations <platform> actions para ver cada acción y su ajuste de aprobación, o eesel approvals para aprobar o denegar acciones retenidas. La CLI sigue los mismos permisos que el panel, así que una escritura configurada como "requiere aprobación" queda retenida hasta que una persona la apruebe.
¿Qué dice la gente?
La reacción pública al propio PAP sigue siendo escasa, lo cual tiene sentido tres días después del lanzamiento. La discusión más amplia sobre agentes que contactan con soporte es más ruidosa. En Hacker News, el comentario más útil que encontré vino del lado del cliente de la mesa:
"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."
Ponlo junto a la lectura de PAP de Simon Taylor en X, donde lo llamó una alternativa al bloqueo y dijo que permite a una empresa "recognize it, give it read-only by default, and route anything that moves money to your own agent". Es su interpretación, no la redacción de Sierra, pero es la versión hacia la que yo construiría. Bloquear rechaza al cliente, y una puerta abierta sin límites es peor. Los scopes son lo que permite que ambas partes obtengan algo.
Prueba eesel
Si los agentes de tus clientes están a punto de pedirle reembolsos a tu cola, el primer trabajo es decidir a qué puede decir sí tu propia IA. El compañero de IA para el helpdesk de eesel se conecta a Zendesk, Freshdesk o Gorgias, aprende de tus tickets pasados y de tu centro de ayuda, y mantiene los reembolsos y las cancelaciones detrás de una aprobación hasta que hayas visto que mantiene la línea. Puedes ejecutarlo sobre tickets pasados en una simulación antes de que toque a un cliente.
El plan gratuito incluye 100 créditos y todas las integraciones, y los planes de pago empiezan en 299 $ al mes por 500 créditos, donde un ticket o un chat cuesta 1 crédito, en la página de precios de eesel. Prueba eesel en tu propia cola.