Los agentes personales de inteligencia artificial ya pueden buscar productos, reservar servicios, rellenar formularios o iniciar gestiones por una persona. El problema es que, en la mayoría de los casos, siguen entrando en una web como si fueran un usuario humano: cargan páginas, hacen clic, interpretan formularios y esperan que cada paso funcione. Personal Agent Protocol quiere cambiar ese modelo.
Meta y Sierra anunciaron el 6 de octubre de 2026, junto con socios como Genesys, Instinct, Rocket, Shopify, Stripe y Walmart, el desarrollo de un estándar abierto para definir cómo un agente personal puede identificarse, iniciar una sesión en nombre de una persona y actuar dentro de los límites que esa persona y la empresa hayan autorizado. La primera especificación, v0.1, está prevista para publicarse durante octubre.
La idea es importante porque no intenta crear otro modelo de IA ni otro chatbot. Busca resolver una capa mucho más práctica: cómo se reconoce a un agente, qué permisos tiene, qué canal puede utilizar y qué puede hacer sin obligarlo a “fingir” que es una persona haciendo clic por una web.
Qué es Personal Agent Protocol
Según el anuncio oficial de Sierra, Personal Agent Protocol —PAP— es un estándar abierto en desarrollo para que agentes personales de IA interactúen con empresas de una forma más directa, segura y visible. La propuesta parte de una idea sencilla: el usuario decide qué acceso concede a su agente y la empresa decide qué operaciones permite a ese agente.
El protocolo está pensado para funcionar sobre infraestructura que las empresas ya tienen. No obliga a abandonar la web, una API o un agente empresarial existente. Al contrario, pretende dar al agente personal una forma consistente de descubrir qué ofrece una empresa y por qué vía puede completar una tarea.
En la práctica, un agente podría empezar como invitado para consultar disponibilidad o una política de devoluciones. Si después necesita modificar un pedido o acceder a datos privados, el usuario podría autenticarse y autorizar un nivel concreto de acceso.
El problema que intenta resolver
Los agentes actuales suelen interactuar con internet mediante interfaces diseñadas para personas. Eso funciona, pero tiene límites. Una página puede cambiar de diseño, un formulario puede introducir un paso inesperado o una empresa puede bloquear automatizaciones porque no sabe quién está actuando ni con qué autorización.
Ese sistema también es ineficiente. Un agente puede tardar decenas de pasos en completar una gestión que una API podría resolver en segundos. Y desde el punto de vista de la empresa, un navegador automatizado ofrece poca información sobre la identidad del agente, la intención de la operación o los permisos que el usuario le concedió.
Este problema se vuelve más importante a medida que aparecen agentes persistentes capaces de trabajar entre aplicaciones. En FormateConIA ya explicamos cómo OpenAI Dots lleva los agentes a tareas continuadas entre servicios. Si ese tipo de sistema se generaliza, las empresas necesitarán una forma estándar de recibirlos sin tratar cada agente como una excepción.
Cómo funcionaría una sesión con un agente personal
La propuesta de Sierra describe un flujo en varias etapas. Primero, el agente descubre en la web qué servicios ofrece la empresa y cómo puede conectarse. Después inicia una sesión en nombre del usuario. Para acciones simples puede actuar como invitado; para acciones privadas o sensibles necesita autenticación.
El usuario decide entre lectura y escritura
Uno de los detalles más relevantes es la separación entre acceso de solo lectura y acceso de escritura. Consultar el estado de un pedido no implica necesariamente permiso para cancelarlo. Leer una factura no equivale a poder cambiar una dirección de cobro.
Este principio reduce un riesgo habitual en sistemas de agentes: conceder permisos excesivos por comodidad. Un diseño con niveles explícitos permite que el agente reciba exactamente el alcance necesario para cada tarea.
OAuth como base de autorización
Personal Agent Protocol utiliza OAuth para construir la sesión. OAuth es un estándar ampliamente utilizado para delegar acceso limitado sin compartir directamente las credenciales principales del usuario. El RFC 6749 del IETF define este modelo de autorización para que una aplicación pueda obtener acceso limitado a un servicio en nombre de una persona.
En este contexto, OAuth encaja porque permite que el usuario autorice al agente sin entregarle necesariamente su contraseña. El alcance puede limitarse y, en una implementación correcta, revocarse cuando deje de ser necesario.
Web, API o agente de la empresa: tres rutas posibles
Una de las decisiones más interesantes de PAP es no imponer un único canal. Sierra plantea tres rutas principales:
- La web: el agente puede seguir navegando por páginas normales cuando esa sea la mejor opción.
- Las APIs: puede conectarse a interfaces basadas en estándares como MCP u OpenAPI cuando exista una vía estructurada.
- El agente de la empresa: puede hablar con un agente propio de la compañía para tareas que requieren conversación, contexto o procesos específicos, como una reclamación de garantía.
Esto convierte el protocolo en una especie de capa de coordinación. No sustituye a MCP ni a OpenAPI. Esos estándares describen cómo exponer herramientas o interfaces; PAP intenta resolver quién llega, a quién representa, qué permiso tiene y cómo se mantiene la sesión a través de distintos canales.
La diferencia es importante. Un agente puede tener acceso técnico a una API y aun así no estar autorizado para modificar los datos de un cliente. El protocolo intenta hacer explícita esa relación entre capacidad técnica y permiso real.
Por qué participan Shopify, Stripe y Walmart
La presencia de empresas de comercio y pagos da una pista clara sobre uno de los primeros campos de aplicación. Comprar, devolver, cambiar un pedido, preguntar por inventario o gestionar una suscripción son tareas que un agente puede automatizar, pero requieren identidad, permisos y trazabilidad.
Shopify explica en el anuncio que los comerciantes necesitan una forma de trabajar con agentes enviados por sus clientes. Stripe pone el foco en reconocer a esos agentes y conservar la relación con el cliente. Walmart aporta el punto de vista de un gran comercio con catálogos, pedidos y operaciones a escala.
Para una pequeña empresa, el efecto no llegará necesariamente mediante una integración propia con PAP desde el primer día. Lo más probable es que aparezca primero a través de plataformas de comercio, CRM, pagos y atención al cliente que adopten el estándar.
Ese escenario conecta con herramientas actuales que ya convierten canales de mensajería en sistemas de trabajo. Nuestro análisis de Funnelchat 3.0 y la automatización de WhatsApp muestra precisamente cómo CRM, agentes y automatizaciones empiezan a mezclarse en una misma capa operativa.
Qué cambia para el usuario
Si PAP funciona como se plantea, el usuario debería notar menos fricción. En lugar de ver cómo su agente abre muchas páginas y repite pasos manuales, podría autorizar una tarea y dejar que la empresa y el agente negocien el canal adecuado.
El beneficio más evidente sería la velocidad, pero no es el único. Una sesión autorizada puede ofrecer más trazabilidad que una automatización de navegador. La empresa puede saber que un agente actúa en nombre de una persona concreta y qué operaciones están permitidas.
También puede mejorar la continuidad. Sierra plantea que una misma sesión atraviese varios canales. Una consulta iniciada antes de identificarse podría continuar después del inicio de sesión sin tratar cada interacción como una conversación separada.
Qué cambia para las empresas
Para una empresa, los agentes personales plantean un dilema. Bloquearlos puede empeorar la experiencia de clientes que quieren utilizarlos; aceptarlos sin reglas claras puede abrir problemas de fraude, permisos y responsabilidad.
Un estándar común podría permitir a una empresa establecer políticas concretas: qué acciones acepta, qué información necesita, qué permisos exige y qué canal recomienda. Eso es mucho más controlable que dejar que cada agente improvise sobre la interfaz pública.
También aparece una nueva disciplina de diseño: las empresas tendrán que pensar no solo en la experiencia de usuario humana, sino en la experiencia de agente. Una web puede seguir siendo importante para las personas mientras ofrece una ruta estructurada a sistemas automáticos.
Pagos, notificaciones y permisos más detallados
El anuncio describe varias extensiones futuras. Una de ellas son permisos más específicos para limitar acciones concretas. Otra son notificaciones push para que una empresa avise a un agente cuando cambia algo relevante, como el retraso de un vuelo o el envío de un pedido.
También se plantea una extensión de pagos que permitiría completar una compra sin compartir directamente los datos de la tarjeta con el agente. Esa posibilidad todavía forma parte de lo que viene después; no debe confundirse con una función ya desplegada de forma general.
La especificación v0.1 todavía no está publicada en el momento del anuncio. Sierra afirma que planea publicarla durante octubre, organizar talleres de diseño y ofrecer una implementación de referencia. Por tanto, muchas decisiones técnicas pueden cambiar antes de una adopción real a gran escala.
Personal Agent Protocol frente a MCP
Es fácil confundir ambos conceptos porque aparecen juntos en el mismo ecosistema. MCP conecta un sistema de IA con herramientas y fuentes de datos mediante una interfaz estructurada. PAP se sitúa un nivel por encima: define cómo un agente personal se presenta ante una empresa, cómo obtiene autorización y cómo conserva una sesión.
Una empresa podría utilizar PAP para reconocer que un agente actúa por un cliente y después ofrecerle herramientas mediante MCP. También podría exponer una API OpenAPI o dejar que el agente navegue por la web. No son alternativas excluyentes.
Este tipo de arquitectura es más fácil de entender si se compara con las plataformas que ya gestionan ejecución persistente y herramientas. Nuestro artículo sobre Agents API y agentes de IA que trabajan durante días explica por qué la infraestructura alrededor del modelo —sesiones, herramientas, permisos y recuperación— puede ser tan importante como el propio modelo.
Oportunidades para creadores y pequeños negocios
Para un creador o una pequeña empresa, PAP no es todavía una herramienta que haya que instalar mañana. La oportunidad está en anticipar cómo cambiará el recorrido del cliente cuando una parte de las visitas llegue a través de agentes.
Un negocio que vende formación, servicios o productos podría empezar a pensar en información estructurada, políticas claras, inventario fiable y procesos de atención que puedan exponerse de forma segura. Cuanto más ambiguo sea un proceso, más difícil será automatizarlo sin errores.
También crecerá la importancia de producir contenido y activos que puedan reutilizarse en distintos canales. Para quien trabaja esa parte, nuestro análisis de Monetízate con avatares IA y bots revisa un enfoque orientado a creación de contenido asistida por IA y recursos especializados.
Riesgos y preguntas que todavía están abiertas
Identidad del agente y responsabilidad
Saber que un agente representa a una persona no resuelve por sí solo quién responde si ejecuta una acción incorrecta. Las empresas necesitarán registros claros y mecanismos para diferenciar una recomendación, una petición de información y una acción irreversible.
Permisos demasiado amplios
El valor del protocolo depende de que los permisos sean comprensibles y suficientemente granulares. Si el usuario acepta un bloque enorme de acceso porque es más cómodo, se repite el mismo problema que PAP intenta evitar.
Adopción desigual
Un estándar abierto solo resulta útil si muchas partes lo implementan. La participación inicial de empresas relevantes es una buena señal, pero no garantiza que PAP se convierta en el protocolo dominante. Puede coexistir con otros estándares o evolucionar de forma considerable.
Seguridad de los propios agentes
Un canal de autorización correcto no elimina riesgos como la inyección de prompt, el uso incorrecto de herramientas o una interpretación equivocada de la intención del usuario. El agente sigue necesitando controles, verificación y límites de ejecución.
Hechos, inferencias y predicciones
Hecho confirmado: Meta y Sierra anunciaron el 6 de octubre de 2026 el desarrollo de Personal Agent Protocol junto con Genesys, Instinct, Rocket, Shopify, Stripe y Walmart.
Hecho confirmado: el diseño anunciado utiliza OAuth, contempla acceso de lectura y escritura, y permite que un agente trabaje a través de la web, APIs o un agente de la propia empresa.
Hecho confirmado: Sierra planea publicar la especificación v0.1 durante octubre de 2026 y posteriormente una implementación de referencia.
Inferencia razonable: el comercio electrónico, la atención al cliente, los viajes y los servicios con cuenta de usuario serán algunos de los primeros ámbitos donde un protocolo de este tipo puede aportar valor, porque combinan muchas acciones repetitivas con permisos sensibles.
Predicción: si PAP consigue suficiente adopción, las webs empezarán a diseñarse para dos públicos simultáneos: personas y agentes. La interfaz visual seguirá importando, pero cada vez más operaciones podrán resolverse mediante rutas estructuradas sin simular clics humanos.
Preguntas frecuentes
¿Personal Agent Protocol ya está disponible?
El protocolo fue anunciado el 6 de octubre de 2026. Sierra indica que la especificación v0.1 se publicará durante octubre, por lo que todavía está en fase inicial de definición.
¿Es lo mismo que MCP?
No. MCP permite conectar modelos y agentes con herramientas y datos. PAP está orientado a la relación entre un agente personal, el usuario al que representa y una empresa, incluyendo sesión, autorización y canales de actuación.
¿Un agente podrá comprar por mí?
El anuncio contempla futuras extensiones de pagos y operaciones comerciales, pero cada empresa podrá definir qué acciones admite y el usuario seguirá teniendo que autorizar el acceso correspondiente.
¿Las empresas tendrán que rehacer sus webs?
No necesariamente. La propuesta pretende funcionar con webs y APIs existentes, además de agentes empresariales. La adopción puede consistir en añadir una capa de descubrimiento, identidad y permisos sobre la infraestructura actual.
Conclusión
Personal Agent Protocol apunta a uno de los problemas menos vistosos pero más importantes de la nueva generación de agentes: cómo dejar que una IA actúe en nombre de una persona sin convertir internet en una colección de automatizaciones frágiles y permisos opacos.
La propuesta todavía está en una fase temprana, pero reúne piezas que tienen sentido: OAuth para autorización, permisos explícitos, continuidad de sesión y libertad para utilizar web, API o agentes empresariales. Su éxito dependerá de la especificación final, de la seguridad real de las implementaciones y, sobre todo, de cuántas plataformas decidan adoptarlo.
Si el estándar prospera, el cambio será profundo. Las empresas no solo tendrán que preguntarse si su web funciona bien para una persona. También tendrán que decidir qué puede hacer un agente, cómo demuestra a quién representa y hasta dónde puede actuar. Ese puede ser uno de los cimientos de la web agéntica que está empezando a aparecer.
Fuentes principales consultadas el 7 de octubre de 2026: anuncio oficial de Sierra sobre Personal Agent Protocol y RFC 6749 del IETF para OAuth 2.0. Las funciones futuras descritas por Sierra se presentan como propuestas en desarrollo, no como disponibilidad general ya confirmada.