El Personal Agent Protocol, explicado: qué han lanzado Sierra y Meta y qué tiene que exponer tu stack de soporte
El Personal Agent Protocol (PAP) es un estándar abierto basado en OAuth que define cómo el agente de IA personal de un consumidor encuentra una empresa, inicia sesión con el consentimiento del cliente y actúa en su nombre. Sierra y Meta lo anunciaron el 6 de octubre de 2026, y tres días después llegó un Draft 0.1.
En resumen: el Draft 0.1 de PAP estandariza el descubrimiento, la identidad del agente y el inicio de sesión con OAuth, pero, según la descripción general del borrador, deja sin definir los permisos por acción y la auditoría, así que el trabajo duro recae en el help desk y el CRM que ya usas.
Metodología y fuentes
- Fuentes primarias: el anuncio y la publicación del borrador de Sierra, la documentación de PAP, la publicación sobre PACT de Decagon y las especificaciones de MCP, A2A, AP2 y WebMCP.
- La lista de socios de Meta procede del artículo de CMSWire; la propia publicación de Meta bloquea la lectura automatizada.
- Todos los datos se verificaron el 13 de octubre de 2026. Esta página se actualizará a medida que avance el borrador.
- Aviso: este es el blog de Aissist. Aissist vende una capa operativa de IA que funciona sobre los help desks existentes, y Sierra compite con nosotros.
¿Qué es el Personal Agent Protocol y cómo funciona una sesión?
PAP es un apretón de manos compartido: un archivo indica a los agentes qué permite una empresa, OAuth permite al cliente conceder acceso de lectura o escritura y, después, un único token funciona en el sitio web, las API y el propio agente de la empresa. La publicación del borrador de Sierra, firmada por Bret Taylor y Clay Bavor, apoda al protocolo «Poppy».
Una sesión se desarrolla en cuatro pasos:
- Descubrimiento. La empresa publica
/.well-known/poppy.json, donde describe cómo pueden interactuar los agentes, cómo inician sesión los clientes y qué puede hacer un agente. - Sesión de invitado. El agente abre una sesión y se identifica. Hasta el inicio de sesión, según la documentación de PAP, la empresa solo ve un ID sin información personal, y ese ID es distinto en cada empresa.
- Inicio de sesión. Para las tareas de la cuenta, el cliente inicia sesión en la propia página de la empresa mediante OAuth y elige acceso de consulta, de modificación o ambos. El acceso es revocable.
- Acción. El agente trabaja a través del canal que ofrezca la empresa: su sitio web, sus API (OpenAPI o MCP) o su propio agente.
El argumento para las empresas es económico: conectarse una vez, en lugar de una vez por cada agente personal. El argumento para los consumidores es la velocidad. Hoy, un agente personal recorre tu proceso de compra clic a clic como un becario con mucha paciencia; una conexión directa hace el mismo trabajo en segundos.
«Las marcas necesitan una forma fiable de saber a quién representa un agente de IA.» — Tony Bates, Chairman & CEO, Genesys, en el anuncio de Sierra
Fíjate en lo que la sesión le da a una empresa: quién es el agente y qué ha aceptado el cliente. No te dice si este reembolso en concreto debe tramitarse.
¿Qué se ha lanzado realmente y cuándo?
Se ha lanzado un borrador; un estándar terminado, no. Sierra prometió una v0.1 dentro de octubre cuando anunció PAP el 6 de octubre, publicó el borrador el 9 de octubre y la documentación ya llevaba la etiqueta Draft 0.1 el 13 de octubre. Lo siguiente son talleres y una implementación de referencia.
| Fecha | Evento | Fuente primaria |
|---|---|---|
| 16 sep 2025 | Google anuncia AP2, el Agent Payments Protocol | ap2-protocol.org |
| 6 oct 2026 | Sierra y Meta anuncian PAP; v0.1 prometida para octubre | Sierra |
| 6 oct 2026 | Decagon publica PACT como código abierto y se une al grupo de trabajo de PAP | Decagon |
| 7 oct 2026 | NiCE afirma que está codesarrollando PAP con Meta | IT Brief |
| 9 oct 2026 | Sierra publica el borrador («Poppy») | Sierra |
| 9 oct 2026 | Se actualiza el borrador del WebMCP Community Group | W3C WebML CG |
| 13 oct 2026 | La documentación de PAP se etiqueta como Draft 0.1 | Documentación de PAP |
| El mes que viene | Talleres de diseño y una implementación de referencia | Sierra |
El borrador no nombra ningún organismo de normalización ni ningún proceso de gobernanza. El anuncio de Sierra enumera como posibles extensiones permisos de acción más granulares, notificaciones push y pagos, todo ello en futuro.
¿Quién respalda PAP y por qué no coinciden las listas de socios?
Los tres anuncios fundacionales nombran empresas que se solapan pero no son las mismas: Sierra incluye a Instinct, y Meta, en cambio, a NiCE y Decagon. Cinco socios (Genesys, Rocket, Shopify, Stripe y Walmart) aparecen en todas las listas.
| Empresa | Publicación de Sierra, 6 oct | Lista de Meta, según CMSWire | Publicación de Stripe, según eesel |
|---|---|---|---|
| Genesys | Sí | Sí | Sí |
| Rocket | Sí | Sí | Sí |
| Shopify | Sí | Sí | Sí |
| Stripe | Sí | Sí | Sí (fundador) |
| Walmart | Sí | Sí | Sí |
| Instinct | Sí | No | Sí |
| NiCE | No | Sí | No |
| Decagon | No | Sí | No |
La explicación más probable es prosaica: el grupo de trabajo creció entre la redacción y la publicación. En cualquier caso, dos competidores directos de Sierra en IA para atención al cliente, Decagon y NiCE, ya están en la sala. Está claro que los proveedores de contact center interpretan PAP como un acontecimiento del canal de soporte, no del comercio.
«Los agentes personales ya trabajan para los consumidores.» — Philipp Heltewig, Chief AI Officer, NiCE, vía IT Brief
Ausentes de todas las listas: Zendesk, Salesforce, Intercom, Google, OpenAI y Anthropic. Un estándar sobre cómo entran los agentes en una empresa, sin las compañías que alojan la mayoría de las colas de soporte, sigue siendo una propuesta.
¿Cómo se compara PAP con MCP, A2A y AP2?
Cada protocolo responde a una pregunta distinta: PAP pregunta a quién representa el agente y qué permitió el cliente; MCP conecta un agente con herramientas; el protocolo agent to agent (A2A) permite que los agentes hablen con otros agentes; AP2 demuestra que un pago estaba autorizado.
| PAP | MCP | A2A | AP2 | |
|---|---|---|---|---|
| Pregunta que responde | ¿Quién es este agente y qué permitió el cliente? | ¿Cómo llama un agente a mis herramientas y datos? | ¿Cómo intercambian tareas dos agentes? | ¿Cómo demuestro que esta compra estaba autorizada? |
| Estado (oct 2026) | Draft 0.1 | Especificación 2026-07-28 | Proyecto de la Linux Foundation | v0.2 |
| Liderado por | Sierra, Meta | LF Projects (Linux Foundation) | Comité de dirección de 8 empresas | Google; grupos de la FIDO Alliance |
| Modelo de consentimiento | Inicio de sesión con OAuth; consulta, modificación o ambos | OAuth 2.1, opcional | Esquemas declarados por agente (OAuth 2.0, OIDC, mTLS) | Mandatos de compra y de pago firmados |
| Auditoría por acción | No incluida en el borrador | No definida | No definida | Los mandatos encadenados forman un registro de auditoría |
Fuentes: especificación de autorización de MCP, gobernanza de MCP, especificación de A2A, AP2.
Se apilan en lugar de competir. PAP enruta explícitamente el trabajo con API a través de MCP y OpenAPI. AP2 se describe a sí mismo como una extensión de A2A y MCP. También importan dos vecinos. WebMCP, editado por ingenieros de Microsoft y Google, permite que una página web registre herramientas JavaScript para agentes: un canal «sitio web» más ordenado. Y PACT, de Decagon, construido sobre A2A, ya define permisos por acción como orders:cancel y recibos firmados de cada acción realizada: justo las partes que el borrador de PAP aplaza.
«…este estándar podría desarrollarse rápidamente, igual que lo hizo Model Context Protocol.» — Larry Dignan, Editor in Chief, Constellation Insights
¿Qué tiene que exponer tu stack de soporte?
Expones acciones, no sistemas: cada cosa que un agente puede hacer necesita un endpoint, una regla de acceso para invitados frente a usuarios con sesión iniciada, un techo para lo que puede cambiar y un registro de lo que ha pasado. El apretón de manos de OAuth es la parte fácil. Tu proveedor de identidad lleva años haciéndolo.
| Clase de acción | Ejemplo en el help desk | Acceso necesario | Qué debes decidir y exponer |
|---|---|---|---|
| Respuestas públicas | Política de devoluciones, stock, plazos de envío | Invitado | Base de conocimiento o API de lectura; límites de uso por agente |
| Lecturas de la cuenta | Estado del pedido, historial de tickets | Sesión iniciada, consulta | Asociar el ID por pares a un contacto del CRM; limitar el alcance a un solo cliente |
| Escrituras reversibles | Cambiar la dirección, reprogramar, abrir un ticket | Sesión iniciada, modificación | Endpoints idempotentes; etiquetar cada escritura con la identidad del agente |
| Dinero o irreversibles | Reembolso, cancelar el plan, condonar una comisión | Sesión iniciada, modificación, más tu política | Límites de importe, reglas de aprobación, vía de escalación |
| Traspaso | «Necesito hablar con una persona» | Cualquiera | Ticket con la transcripción, la identidad del agente y los permisos usados |
Las filas cuatro y cinco son donde el borrador de PAP guarda silencio y donde una mala decisión sale cara. Si una acción no se puede deshacer, ponle un límite y una regla de aprobación, porque el permiso de escritura de un cliente no dice nada sobre importes. Un agente con un token válido y sin techo de reembolso es una forma educada de regalar inventario.
Dentro de Aissist clasificamos cada acción de la IA en una escala de gravedad de cuatro niveles: desde S0, para un resultado de negocio que no se puede deshacer fácilmente, como cerrar un acuerdo que no debería cerrarse, hasta S3, para la redacción meramente estética. Nuestro objetivo es menos de un 0.01% de errores S0. Esa misma escala sirve como política de PAP: las acciones de clase S0 nunca deberían depender solo del permiso de escritura de un cliente, sea de quien sea el agente que lo pide.
Nada de esto exige un help desk nuevo. Las reglas pertenecen a una capa operativa de IA que ya lee y escribe los datos de tu Zendesk o de Intercom. Los gateways de Aissist se conectan con 50+ sistemas y se despliegan en unos 10 minutos, según nuestros propios datos: el lugar donde ya residen los límites de acción de tu agente de IA.
PAP estandariza la puerta, no las decisiones que hay detrás
PAP tiene opciones reales de imponerse: cuenta con la distribución de Meta y con dos de los mayores proveedores de contact center, Genesys y NiCE. Pero el borrador resuelve la identidad y el consentimiento, no el criterio. Qué acciones puede realizar un agente externo, con qué límites y qué recoge el registro de auditoría sigue siendo algo que te toca definir a ti. Empieza por un inventario de acciones por gravedad, no por un proyecto de integración. Cambiar de plataforma al autor del estándar es justo el movimiento que el estándar hace innecesario; el lock-in es una elección. Para el lado de compra del tráfico de agentes, nuestra comparativa de plataformas de comercio agéntico y el artículo explicativo sobre Claude for Commerce profundizan más.
¿Quieres ver dónde residen los límites de acción de los agentes en tu stack? Aissist funciona sobre el help desk que ya tienes, con límites, aprobaciones y escalación por acción. Reserva una demo gratuita →
Preguntas frecuentes
¿Está publicada la especificación del Personal Agent Protocol?
Sí, como borrador. Sierra la publicó el 9 de octubre de 2026, y la documentación de personalagentprotocol.org se etiquetó como Draft 0.1 el 13 de octubre. Se prometen talleres de diseño y una implementación de referencia en el plazo de un mes.
¿PAP es lo mismo que el protocolo agent to agent (A2A)?
No. A2A, un proyecto de la Linux Foundation, define cómo intercambian tareas los agentes. PAP define cómo un agente personal se identifica ante una empresa y actúa dentro del acceso que le concedió un cliente. PACT, de Decagon, es el protocolo que se construye sobre A2A.
¿Qué es WebMCP y qué relación tiene con PAP?
WebMCP es un borrador de un W3C Community Group que permite que una página web registre herramientas JavaScript para agentes de IA. Describe qué puede hacer una página; PAP describe quién es el agente y qué autorizó el cliente. Ni la publicación del borrador de Sierra ni la descripción general de PAP lo mencionan.
¿Necesito a Sierra o a Meta para implementar PAP?
No. Sierra describe PAP como abierto para que cualquiera lo implemente. Una empresa publica un archivo de descubrimiento, admite el inicio de sesión con OAuth y elige sus canales.
¿PAP gestiona pagos?
Todavía no. Sierra solo menciona una extensión de pagos como posible incorporación futura. AP2 de Google, en su v0.2, cubre hoy la autorización de pagos de agentes con mandatos de compra y de pago firmados.
¿Tengo que sustituir mi help desk para admitir PAP?
No. PAP se sitúa delante de los sistemas que ya usas. El trabajo consiste en definir qué acciones puede realizar un agente, sus límites y qué se registra: una política que debe ir por encima de tu help desk y tu CRM actuales.
