Meta, Walmart y Stripe quieren que los agentes inicien sesión en lugar de hacer clic. La especificación aún no existe
By Surya Pratap
10 de octubre de 2026
9 min read
AI & Technology
10 de octubre de 2026
9 min read
Invitado, luego lectura, luego escrituraHover to exploreHoy, un agente personal de IA que quiere consultar un pedido, reservar mesa o cambiar una dirección de entrega hace lo mismo que una persona: carga la página, busca el formulario y lo va rellenando. Es lento, se rompe en cuanto cambia la página y, en general, la empresa no sabe si al otro lado hay una persona o un programa.
Esta semana, un grupo de grandes empresas ha propuesto otro modelo: el agente inicia sesión, el cliente decide qué puede hacer y la empresa decide cómo entra.
Este artículo se basa en «Introducing Personal Agent Protocol», de Bret Taylor y Clay Bavor, de Sierra, publicado el 6 de octubre de 2026, y en la cobertura de The Next Web, Constellation Research y The Daily Brief. Cuando se escribió, no se había publicado ninguna especificación. La lectura a partir de la sección 4 es mía.
El 6 de octubre de 2026, en la cumbre de Sierra en San Francisco, Sierra y Meta anunciaron el Personal Agent Protocol, que describen como un estándar abierto sobre «cómo interactúan los agentes personales con las empresas». Los socios fundadores son Genesys, Instinct, Rocket, Shopify, Stripe y Walmart.
La idea, en palabras de Sierra: «los consumidores deciden qué acceso dan a sus agentes personales, y las empresas fijan los parámetros de lo que esos agentes pueden hacer».
El anuncio plantea el protocolo en torno a lo que quieren tres grupos:
El interés de Meta es directo. Su agente personal, Muse, es justo el tipo de agente para el que está pensado el protocolo. Según Constellation Research, Muse aplica dos comprobaciones antes de actuar: si una persona honrada haría lo mismo —el ejemplo citado es crear cinco cuentas para canjear un solo cupón— y si el sistema seguiría funcionando en caso de que todos los agentes lo hicieran.
El anuncio describe una sesión con tres niveles de acceso:
La sesión se basa en OAuth, el estándar que ya usan la mayoría de los inicios de sesión. Además, «se mantiene entre canales, de modo que una pregunta hecha antes de iniciar sesión y un cambio en un pedido hecho después forman parte de la misma visita».
Por su parte, la empresa elige cómo llegan a ella los agentes:
El cliente decide cuánto puede hacer el agente. La empresa decide por qué puerta entra. Por ahora, la propuesta es eso.
Esto es un anuncio, no un estándar que se pueda implementar esta semana.
Bret Taylor, citado por The Daily Brief, resumió la situación actual: «Hasta que exista un estándar así, esto es un poco un caos».
Conviene leer este anuncio junto a los otros con los que se solapa. The Daily Brief comparó cuatro:
| Protocolo | Principales impulsores | Enfoque |
|---|---|---|
| Agentic Commerce Protocol (ACP) | OpenAI, Stripe | Pago dentro del agente, con tokens de pago acotados |
| Trusted Agent Protocol (TAP) | Visa, Cloudflare | Demostrar la identidad de un agente con peticiones firmadas |
| Universal Commerce Protocol (UCP) | Google, Shopify y otros | La compra completa, desde el descubrimiento hasta la posventa |
| Personal Agent Protocol (PAP) | Sierra, Meta, Walmart y otros | Cómo inicia sesión el agente de una persona y qué puede hacer |
Stripe y Shopify participan en los cuatro. Las empresas que más tienen que perder si eligen el estándar equivocado han decidido no elegir. Una startup de cinco personas no debería intentar tener más certeza que ellas.
Además, cada protocolo responde a una pregunta distinta. TAP trata de qué agente está llamando. ACP, de cómo se paga. PAP, de qué ha permitido este cliente que haga este agente en su cuenta. Un producto real podría acabar necesitando partes de más de uno.
La buena noticia es que el trabajo de base que exigen todos estos protocolos es el mismo, y casi todo mejora el producto también para las personas.
Haz legibles los datos públicos sin necesidad de iniciar sesión. Stock, precios, horarios, zonas de entrega, política de devoluciones. Si un agente en modo invitado no puede leerlos de forma fiable, mandará a su usuario a otro sitio donde sí pueda. Valen tanto los datos estructurados en tus páginas como una pequeña API de solo lectura.
Separa el acceso de lectura del de escritura. Si tu API tiene un único token que lo puede todo, un agente al que el cliente solo quería dejar ver sus pedidos también puede cancelarlos. Los scopes de OAuth para «leer la cuenta» y «modificar la cuenta» son el mínimo que da por hecho el protocolo.
Haz que las acciones de escritura se puedan repetir sin riesgo. Los agentes reintentan. Un cambio de pedido, una reserva o una solicitud de reembolso deberían aceptar una clave de idempotencia, para que la misma petición enviada dos veces se ejecute una sola. Añade un paso de confirmación para todo lo que sea caro o irreversible.
Etiqueta las sesiones de agentes. Registra si una acción la hizo una persona, un agente conocido en nombre del cliente o un script desconocido. No puedes fijar límites de uso, detectar abusos ni medir los ingresos que generan los agentes si no distingues ese tráfico.
Si ya tienes una API, un servidor MCP sobre un puñado de las tareas más habituales de tus clientes es una forma barata de aprender qué piden realmente los agentes. Empieza por herramientas de solo lectura. Añade las de escritura solo cuando sepas quién llama y tengas resueltas la idempotencia y la confirmación.
Cómo elegir el canal
El protocolo te deja elegir entre tu web, tu API y tu propio agente. Para la mayoría de los productos en fase inicial, la respuesta correcta para empezar es la API: una web es frágil para un agente, y mantener tu propio agente de cara al cliente es un producto en sí mismo. Ofrece tu propio agente cuando la tarea de verdad necesite una conversación —una devolución complicada, una consulta sobre una hipoteca—, no como vía de entrada por defecto.
Que el PAP vaya a ganar. Tiene grandes nombres y ninguna especificación. UCP, ACP y TAP cuentan con sus propios pesos pesados, y el solapamiento entre sus miembros indica que nada está decidido.
Que los agentes vayan a llegar pronto a tu producto. La propia investigación de Visa concluyó que la mayoría de la gente todavía no está dispuesta a dejar que un agente pague por ella. El protocolo hace más capaces a los agentes; no hace que los clientes confíen en ellos.
Que resuelva las cuestiones legales. El anuncio no aborda quién responde cuando un agente con acceso de escritura hace algo que el cliente no pretendía. Tampoco cómo encajan los pagos aprobados por un agente en normas como la autenticación reforzada de clientes europea, que se redactó pensando en una persona que aprueba un pago. Para ver cómo ha tratado un tribunal a los agentes que actúan en nombre de usuarios, consulta nuestra lectura de la decisión del Noveno Circuito en el caso Perplexity.
Que los detalles estén cerrados. Todo lo de las secciones 2 y 3 procede de un anuncio. La especificación v0.1 puede cambiar nombres, scopes o el modelo de sesión.
Meta, Sierra, Walmart, Shopify, Stripe y otras empresas han propuesto una forma estándar para que el agente de IA de una persona inicie sesión en una empresa. Los agentes empiezan como invitados, el cliente elige acceso de solo lectura o de escritura mediante OAuth, y la empresa decide si los agentes usan su web, sus API o su propio agente. Aún no hay especificación, ni pagos, ni permisos detallados, ni órgano de gobierno, y es uno de cuatro protocolos que se solapan.
El protocolo que acabes adoptando importa menos que la base que todos dan por supuesta: datos públicos que un agente pueda leer, acceso a la cuenta con permisos acotados, acciones de escritura que se puedan repetir sin riesgo y la capacidad de distinguir el tráfico de agentes del humano.
Elige las tres tareas más habituales de tus clientes. Haz que las de solo lectura funcionen sin iniciar sesión, y que las de escritura tengan permisos acotados, se puedan repetir y queden registradas. Después, lee la especificación v0.1 cuando salga, en lugar de esperar a que salga para empezar.
Fuentes: Bret Taylor y Clay Bavor, «Introducing Personal Agent Protocol», Sierra, 6 de octubre de 2026: los socios, el principio declarado, las necesidades de los tres grupos, los niveles de invitado, solo lectura y escritura, OAuth y las sesiones entre canales, los canales de web, API y agente de la empresa, el calendario de la v0.1 y el trabajo futuro sobre pagos, permisos y notificaciones. The Next Web, para la fecha y el contexto del anuncio. Larry Dignan, Constellation Research, 7 de octubre de 2026: Muse, de Meta, y sus dos comprobaciones. Rajesh Beri, The Daily Brief, 7 de octubre de 2026: la ausencia de especificación, licencia y órgano de gobierno, la cita de Bret Taylor y la comparación con UCP, ACP y TAP. La lectura de las secciones 4 a 6 es mía.
IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.
