Sierra Personal Agent Protocol suma 35 socios, pero las empresas mantienen el control

Sierra publicó el borrador de su Personal Agent Protocol con 35 nuevos socios de diseño, transformando Poppy de una propuesta en un esfuerzo serio de estandarización. Sierra Personal Agent Protocol ahora cuenta con aportes de OpenAI, Bank of America, Mastercard, PayPal, Visa, Cloudflare y otras grandes empresas.

El anuncio es relevante porque los agentes personales suelen entrar en sistemas empresariales a través de interfaces diseñadas para personas. Navegan por páginas, completan formularios y, en ocasiones, usan credenciales con amplio acceso a cuentas. Poppy propone una vía intermedia en la que las empresas reconocen a los agentes, los usuarios aprueban permisos y una sesión puede abarcar sitios web, API y agentes de empresa.

Esa vía intermedia también crea el conflicto central. Los agentes personales necesitan un acceso amplio y coherente para ser útiles, mientras que las empresas quieren controlar la identidad, los permisos, los canales y las relaciones con los clientes. Sierra ha reunido a un grupo inusualmente amplio para negociar ese límite. Aún no ha demostrado que esas empresas desplegarán el protocolo resultante.

Sierra Personal Agent Protocol suma 35 socios de diseño

Poppy ha pasado de un anuncio inicial a un borrador técnico público, pero la participación sigue significando aportes al diseño, no adopción en producción.

Sierra publicó el borrador de Poppy el 9 de octubre de 2026. La empresa también nombró a 35 socios de diseño adicionales de los sectores financiero, minorista, viajes, seguros, medios, identidad, comunicaciones e IA.

El nuevo grupo incluye Adyen, Atomic, Bank of America, BBVA, Chime, Cigna, Cloudflare, Comcast, DIRECTV, ElevenLabs, FOX, Gap Inc., GEICO y Hertz. También incluye Insurify, Klaviyo, Liberty Mutual, Mastercard, Nordstrom, Notion, Okta, OneSignal, OpenAI, PayPal, Plaid y SiriusXM.

Synchrony, Target, United Airlines, Venmo, Visa, Wells Fargo, Zapier, Zendesk y 1Password completan el grupo adicional. Estas organizaciones se suman a las empresas implicadas en el anuncio anterior, entre ellas Meta, Genesys, Instinct, NiCE, Rocket, Shopify, Stripe y Walmart.

La distinción entre el grupo original y las 35 incorporaciones es importante. Sierra no anunció 35 participantes en total. Anunció 35 empresas más después de presentar el proyecto junto con Meta y varios socios de tecnología empresarial el 6 de octubre.

Según Sierra, las nuevas empresas aportarán comentarios basados en sus requisitos de negocio. La lista reúne a organizaciones que normalmente ocupan posiciones distintas dentro de una transacción.

Los bancos y las redes de pago gestionan identidad, fraude, autorización y liquidación. Los minoristas controlan inventario, pago, devoluciones y cuentas de clientes. Los proveedores de identidad gobiernan la autenticación. Las empresas de IA crean los agentes personales que solicitarían acceso.

Sus intereses se solapan, pero no son idénticos. Un desarrollador de agentes se beneficia cuando una integración alcanza a muchas empresas. Un banco se beneficia cuando cada acción sigue siendo atribuible, limitada y reversible. Un minorista quiere tráfico de agentes sin perder el control sobre las políticas de servicio ni la relación con el cliente.

Por eso, la lista de socios es más que una colección de logotipos conocidos. Da a Sierra acceso a las partes que deben acordar los límites entre el descubrimiento, el acceso delegado y las acciones en el mundo real.

Sin embargo, un socio de diseño no es automáticamente un implementador. Sierra no ha publicado cifras de uso en producción, integraciones completadas ni volúmenes de transacciones de Poppy. El anuncio establece participación en el proceso de diseño, no soporte operativo en cada empresa nombrada.

Sierra afirma que realizará talleres de diseño y publicará una implementación de referencia durante el próximo mes. Esos entregables ofrecerán una prueba más sólida que el número de socios. Los desarrolladores necesitan código funcional, entornos de prueba y reglas estables de conformidad antes de poder evaluar los costes de implementación.

Por tanto, la versión actual cambia la credibilidad del protocolo, no su madurez. Poppy cuenta ahora con una especificación pública y un amplio conjunto de empresas interesadas. Sigue siendo el Borrador 0.1, con importantes decisiones técnicas y de gobernanza aún abiertas.

Poppy convierte los permisos en el producto

La principal aportación de Poppy no es otro formato de mensajería entre agentes. Es un modelo compartido de sesión y permisos para agentes que actúan dentro de sistemas controlados por empresas.

La especificación del Borrador 0.1 define un agente personal como software que actúa en nombre de un usuario. Define una empresa como la organización que permite a ese agente interactuar con sus servicios.

Una empresa participante publica un documento de descubrimiento en /.well-known/poppy.json. Ese documento identifica a la organización y enumera sus opciones de autenticación, API, acceso al sitio web, agente de empresa y extensiones compatibles.

El patrón se asemeja a otros mecanismos de descubrimiento web conocidos. En vez de obligar al desarrollador de un agente a localizar instrucciones de integración independientes, Poppy proporciona al agente una única dirección inicial predecible.

El descubrimiento es solo la primera capa. El agente personal abre una sesión para un usuario específico y se identifica ante la empresa. Ese diseño permite a la empresa distinguir la actividad automatizada de una persona que usa el sitio directamente.

Una sesión puede comenzar sin acceso a la cuenta. Por ejemplo, un agente podría comprobar si un producto está disponible o preguntar por una política de devoluciones como invitado. El usuario inicia sesión cuando la tarea requiere información personal de la cuenta o un cambio en ella.

Poppy define inicio de sesión directo, inicio de sesión mediante dispositivo e inicio de sesión mediado. El inicio de sesión directo mantiene la autenticación en la propia página de la empresa. El inicio de sesión mediante dispositivo permite al usuario aprobar el acceso en otro dispositivo siguiendo un enlace e introduciendo un código.

El inicio de sesión mediado permite a un agente enviar credenciales a un endpoint definido por la empresa cuando esta autoriza ese método. Esta opción ofrece compatibilidad, pero también plantea una de las cuestiones de seguridad más sensibles del borrador.

Una vez autorizado, el agente recibe acceso limitado por ámbitos. El amplio ámbito poppy:read cubre la consulta de información de la cuenta, mientras que poppy:write cubre cambios como intercambios o actualizaciones de reservas. Las empresas pueden definir ámbitos adicionales para actividades más específicas.

Estos ámbitos crean una escala de permisos entre dos extremos insatisfactorios. Una empresa no tiene que bloquear a todos los agentes. Un usuario tampoco tiene que conceder a un agente todas las capacidades disponibles a través de la cuenta.

La sesión acompaña al usuario a través de las interfaces compatibles. El agente puede desplazarse entre páginas web, endpoints OpenAPI, servidores MCP y conversaciones con un agente de empresa. Una pregunta previa al inicio de sesión y un cambio posterior en la cuenta pueden seguir formando parte de una misma visita.

Esa continuidad importa para ambas partes. Los usuarios evitan explicar repetidamente el mismo objetivo. Las empresas reciben un registro más coherente de cómo avanzó la sesión a través de distintos canales.

Poppy también define formas de incorporar a personas a una conversación entre agentes. Los mensajes indican si fueron creados por una IA o por un humano. Un agente personal puede solicitar un representante humano, mientras que el usuario puede entrar en una conversación directa sin leer el intercambio previo entre los agentes.

Pensemos en un vuelo cancelado. Un agente personal podría descubrir las interfaces compatibles de una aerolínea, iniciar una sesión y buscar alternativas sin acceso a la cuenta. Después, el usuario podría iniciar sesión, aprobar el acceso a las reservas y confirmar un vuelo de sustitución.

Un minorista podría aplicar una política distinta. Podría permitir que un agente iniciara una devolución mientras bloquea los cambios en los datos de pago guardados. La empresa, no el agente personal, determina qué operaciones habilita cada permiso.

Este mecanismo explica el atractivo del protocolo para las empresas. Poppy no les pide que cedan sus políticas a un agente externo. Ofrece una forma estándar de exponer esas políticas y aplicarlas a través de varios canales técnicos.

Las empresas, no los agentes personales, conservan la ventaja

El protocolo promete elección para el usuario, pero su arquitectura concede a las empresas participantes un control sustancial sobre qué agentes entran y qué pueden lograr.

Sierra presenta Poppy como un compromiso entre el acceso de los agentes y la supervisión empresarial. Los usuarios eligen un agente personal y aprueban sus permisos de cuenta. Las empresas deciden qué interfaces, métodos de inicio de sesión, ámbitos y acciones admiten.

Esta división parece equilibrada a alto nivel. Su resultado práctico dependerá de cómo configuren las empresas sus implementaciones.

Una empresa puede publicar únicamente su sitio web, solo API seleccionadas o un agente de empresa con un rango limitado de tareas. Puede admitir acceso de lectura sin acceso de escritura. Puede exigir inicio de sesión directo para acciones sensibles y rechazar agentes que no reconozca.

Por lo tanto, el protocolo estandariza la negociación más que el acceso universal. Publicar un archivo Poppy no obligaría a una empresa a exponer todas las operaciones de sus clientes. Informaría a los agentes de qué puertas existen y qué condiciones se aplican.

Este modelo aborda directamente un conflicto costoso de la web actual. Las empresas intentan con frecuencia detectar la automatización porque un agente que usa una interfaz humana puede parecer abuso. Los desarrolladores de agentes adaptan entonces sus navegadores para seguir funcionando pese a esos controles.

Ninguna de las dos partes obtiene información fiable de esa disputa. La empresa puede no saber qué servicio opera el agente ni qué usuario representa. El agente puede no saber si una acción fallida refleja una política, autenticación o un cambio de interfaz.

Poppy sustituye parte de esa ambigüedad por identidad y política explícitas. Una empresa puede reconocer la identidad cliente del agente personal, asociarla a un usuario y emitir tokens limitados a ámbitos aprobados.

Ese acuerdo debería facilitar distinguir a los agentes legítimos de la automatización anónima. No elimina el fraude, las cuentas comprometidas, la inyección de prompts ni los desarrolladores de agentes maliciosos. Crea pruebas más estructuradas para aplicar controles de seguridad.

Los usuarios obtienen opciones más claras, pero esas opciones siguen limitadas por la política de la empresa. Una persona no puede conceder a un agente una capacidad que la empresa nunca expone. Del mismo modo, una empresa participante no puede obligar a otra a aceptar su agente preferido.

Este es el equilibrio central detrás de Sierra Personal Agent Protocol. El descubrimiento y la autorización coherentes pueden ampliar el acceso legítimo de los agentes. El mismo diseño también formaliza el derecho de cada empresa a limitar ese acceso.

El equilibrio podría fomentar la adopción entre organizaciones reguladas. Bank of America, BBVA, Wells Fargo, Cigna y varias aseguradoras afrontan obligaciones que hacen inviable una automatización sin restricciones. Necesitan auditabilidad y distinciones sólidas entre leer datos y modificar una cuenta.

Las empresas de pagos tienen incentivos similares. Mastercard, Visa, PayPal, Venmo, Adyen, Plaid y Synchrony necesitan saber qué parte inició una acción. También necesitan controles que sigan funcionando cuando una interfaz de IA se sitúa entre el cliente y la transacción.

Para quienes desarrollan agentes personales, el compromiso sigue siendo atractivo si reduce las integraciones personalizadas. Un formato de descubrimiento y un modelo de autorización pueden ser valiosos incluso cuando cada empresa expone operaciones de negocio diferentes.

El riesgo mayor es la fragmentación dentro del estándar. Las empresas pueden definir ámbitos y extensiones personalizados, mientras que cada API conserva su propio esquema. Dos organizaciones podrían admitir Poppy y, aun así, requerir trabajos de implementación muy distintos.

Poppy puede estandarizar cómo llega un agente, se identifica y solicita acceso. No puede estandarizar automáticamente cada solicitud hipotecaria, reclamación de seguro, cambio de vuelo o devolución minorista.

Esa limitación no vuelve irrelevante al proyecto. Aclara dónde comienza el trabajo difícil. El protocolo puede establecer una puerta de entrada común, mientras que las industrias y las empresas individuales siguen definiendo lo que ocurre dentro.

Los estándares de agentes existentes son insumos, no rivales

Poppy resulta más creíble como una capa de orquestación que utiliza estándares existentes, no como un reemplazo de MCP, A2A, OpenAPI o protocolos de comercio.

Los estándares para agentes ahora cubren varios límites distintos. Tratarlos como una competencia en la que el ganador se lleva todo oculta el problema que aborda cada uno.

Anthropic presentó el Model Context Protocol como una conexión estándar entre aplicaciones de IA y herramientas o datos externos. Un servidor MCP puede exponer capacidades que un cliente de IA descubre e invoca.

Google desarrolló originalmente el protocolo A2A para la comunicación y colaboración entre agentes independientes. A2A se centra en que los agentes intercambien tareas, mensajes, artefactos e información de estado más allá de las fronteras entre proveedores.

Poppy aborda una relación más amplia entre el usuario y la empresa. Cubre el descubrimiento de empresas, la identidad del agente personal, las sesiones de usuario, la autorización, la navegación web, las API, las conversaciones entre empresas y agentes, y las derivaciones a personas.

La distinción aparece en la arquitectura de Poppy. Una empresa puede incluir un servidor MCP como una API disponible. También puede incluir una descripción OpenAPI, ofrecer su sitio web habitual o exponer un agente de empresa.

Por tanto, MCP es una ruta dentro de una sesión de Poppy. Poppy proporciona la identidad circundante, la autorización del usuario y la continuidad entre canales que una interfaz de herramientas por sí sola no define completamente.

A2A tiene una relación similar. Un agente de empresa y un agente personal necesitan una forma de comunicarse, pero su conversación es solo una parte de la visita. El agente personal también podría navegar por una página o llamar a una API convencional.

Los estándares de comercio crean otra capa. El Universal Commerce Protocol de Shopify y Google se centra en actividades comerciales como el descubrimiento de productos, el proceso de pago y la gestión de pedidos.

Sierra describe explícitamente UCP como complementario. Poppy puede establecer a quién representa el agente y qué autorizó el usuario. Después, un protocolo de comercio puede definir las operaciones específicas del dominio involucradas en comprar o gestionar un pedido.

Este enfoque por capas es práctico porque las empresas ya cuentan con pilas tecnológicas variadas. Un minorista podría exponer un flujo de comercio UCP, un servidor MCP de atención al cliente y páginas web normales. Poppy busca conectar esas superficies con una sesión reconocida.

El enfoque también evita forzar todos los procesos empresariales a conversaciones con agentes en lenguaje natural. Las API estructuradas siguen siendo más eficientes y predecibles para muchas operaciones. El acceso web puede cubrir sistemas antiguos que carecen de API modernas.

Sierra afirma que el protocolo se basa en OAuth, HTTPS, JSON Web Tokens, OpenAPI y MCP. Estas decisiones reducen la barrera conceptual para los equipos familiarizados con la seguridad web y las herramientas de API existentes.

El uso de componentes consolidados no garantiza la interoperabilidad. El perfil circundante debe ser lo bastante preciso para que dos implementaciones independientes se comporten de forma coherente. La ambigüedad sobre las audiencias de los tokens, la aplicación de alcances, los reintentos y los estados de fallo aún puede producir sistemas incompatibles.

Por esa razón, la implementación de referencia del protocolo será importante. Los desarrolladores necesitan más que requisitos redactados. Necesitan ejemplos comprobables de registro de agentes, validación de descubrimiento, intercambio de tokens, sesiones de navegador y transferencias de conversaciones.

Lo mismo se aplica a la conformidad. Si cada empresa interpreta las funciones opcionales de manera distinta, los agentes personales seguirán necesitando lógica específica para cada organización. Un estándar útil debe identificar qué comportamientos son necesarios para una compatibilidad básica.

El amplio grupo de socios de Poppy puede ayudar a resolver esos detalles. También puede ralentizar el acuerdo porque los participantes representan plataformas competidoras, entornos regulatorios y relaciones con clientes.

El mejor resultado no es que un protocolo sustituya a todos los demás. Es una pila en la que cada capa tiene una responsabilidad clara. Poppy tendrá éxito si hace que la identidad, los permisos y la continuidad de sesión sean predecibles en toda esa pila.

El borrador deja abiertas difíciles preguntas de seguridad

Poppy proporciona una estructura de seguridad, pero el Borrador 0.1 no elimina los riesgos creados cuando el software puede actuar a través de la cuenta de un cliente.

La especificación advierte que cualquier parte del Borrador 0.1 puede cambiar antes de una versión estable. Esa advertencia importa porque los errores de autorización en esta capa pueden afectar compras, reservas, solicitudes financieras y datos personales.

Poppy utiliza tokens de sesión de corta duración y vincula las solicitudes a la identidad del agente. También describe protecciones de prueba de posesión, en las que el solicitante demuestra que posee la clave asociada a un token.

Esos controles pueden reducir la repetición de tokens y ayudar a las empresas a atribuir actividad automatizada. Su eficacia sigue dependiendo de implementaciones correctas, almacenamiento seguro de claves y validación coherente en todas las interfaces expuestas.

Las sesiones entre canales aumentan la comodidad, pero amplían la superficie de aplicación. Una empresa debe aplicar el mismo estado de cuenta y los mismos límites de permisos en sus API, endpoints de navegador y conversaciones con agentes.

Un alcance aplicado en una API pero ignorado por una página web crearía una vía de elusión. Un agente de empresa que realizara una acción fuera de los permisos de la sesión crearía otra.

El inicio de sesión mediado merece un escrutinio particular. Bajo ese modelo, el agente personal maneja las credenciales antes de transmitirlas a la empresa. La especificación exige que los agentes protejan los campos secretos y eviten mostrarlos o registrarlos.

Ese requisito es útil, pero no puede demostrar que todos los agentes manejen las credenciales de forma segura. Las empresas pueden decidir que el inicio de sesión mediado crea una exposición inaceptable para cuentas sensibles.

El inicio de sesión directo ofrece un límite más claro porque los usuarios se autentican en la propia página de la empresa. El inicio de sesión mediante dispositivo puede proporcionar una separación similar cuando el agente personal opera en otro dispositivo.

El diseño de permisos presenta otro problema. Los amplios alcances read y write son simples, pero los servicios reales contienen acciones con consecuencias muy diferentes.

Cambiar una preferencia de boletín y cambiar una dirección postal son ambas acciones de escritura. Devolver una chaqueta y transferir dinero también lo son. Las empresas necesitarán alcances personalizados más acotados o aprobaciones reforzadas para operaciones de alto impacto.

Los alcances personalizados mejoran el control, pero amenazan la interoperabilidad. Los agentes deben entender qué significa cada alcance antes de explicárselo a los usuarios. Acciones similares pueden recibir nombres distintos entre empresas.

La comprensión del usuario es igualmente importante. Las personas aprueban rutinariamente solicitudes de acceso sin examinar sus detalles. Añadir agentes eleva lo que está en juego porque una aprobación puede respaldar acciones autónomas repetidas.

Una interfaz fiable debe explicar qué agente solicita acceso, qué cuenta utilizará, qué puede leer y qué puede cambiar. También debería facilitar la revocación.

El borrador admite la revocación y describe tokens de cuenta de larga duración para iniciar sesiones posteriores. Esa comodidad crea una relación persistente entre la cuenta del usuario y el agente personal.

Las empresas y los proveedores de agentes necesitarán registros claros de esas relaciones. Los usuarios deberían poder inspeccionar las conexiones activas, los alcances concedidos, las acciones recientes y las fechas de vencimiento.

La inyección de instrucciones sigue fuera del control directo del protocolo. Un agente puede recibir instrucciones maliciosas desde una página web, un mensaje o un documento externo. Una autenticación válida no garantiza que la decisión resultante del agente coincida con la intención del usuario.

Esta preocupación es especialmente relevante cuando un agente combina información de varias fuentes. Una buena gestión del conocimiento personal puede mejorar el contexto, pero más contexto también exige límites más sólidos en torno a la divulgación y la acción.

La confirmación humana puede reducir el riesgo en compras, reservas y cambios de cuenta. Sin embargo, exigir confirmación para cada pequeño paso socavaría la eficiencia que prometen los agentes personales.

Por lo tanto, el protocolo necesita más que un intercambio seguro de tokens. Las implementaciones necesitan aprobación basada en riesgos, registros de transacciones, procesos de recuperación y una responsabilidad clara cuando un agente comete un error costoso.

Los socios de diseño de los sectores bancario, de pagos, identidad, seguros y seguridad en la nube pueden ayudar a poner a prueba esas cuestiones. Sus nombres por sí solos no las responden.

La revisión independiente de seguridad será otra señal importante. Los modelos públicos de amenazas, las pruebas de interoperabilidad y los fallos documentados aportarían más evidencia que las declaraciones sobre confianza o control.

Poppy debería evaluarse según si sus controles se mantienen coherentes en condiciones adversariales. Una demostración exitosa es útil. Un fallo recuperable suele ser más informativo.

Tres señales decidirán el futuro de Poppy

El código funcional, las implementaciones reales por parte de empresas y las pruebas independientes de seguridad determinarán si Poppy se convierte en infraestructura o sigue siendo un borrador ambicioso.

La primera señal es la implementación de referencia prometida por Sierra. La empresa afirma que planea publicar una tras talleres de diseño durante el próximo mes.

Una publicación útil debería incluir ambos lados de la interacción. Los desarrolladores necesitan un agente personal de ejemplo, un servicio de empresa participante, documentos de descubrimiento, flujos de autenticación y pruebas de aplicación de alcances.

La implementación también debería demostrar fallos. Los tokens vencidos, el acceso revocado, los alcances insuficientes, los mensajes duplicados, las transferencias a personas y los flujos interrumpidos son condiciones normales en sistemas de producción.

Un código claro y pruebas de conformidad reforzarían el argumento de Sierra de que las empresas pueden implementar el protocolo con herramientas conocidas. Un retraso o una demostración con un guion limitado debilitaría esa afirmación.

La segunda señal es la adopción por parte de socios identificados. Un archivo público poppy.json en un dominio controlado por un socio tendría más peso que otro anuncio de diseño.

Las primeras implementaciones no necesitan admitir todas las acciones. Un minorista podría comenzar con preguntas sobre productos y el estado de devoluciones. Una aerolínea podría exponer información de horarios antes de permitir cambios en las reservas.

Lo importante es si los agentes personales independientes pueden descubrir y utilizar esas capacidades sin una integración privada. Si el acceso todavía requiere contratos personalizados y comportamientos no documentados, el estándar no ha proporcionado portabilidad.

OpenAI y Meta son especialmente importantes del lado de los agentes personales. Su participación crea la posibilidad de una distribución amplia. Ninguno de los dos nombres garantiza que un producto de consumo admita Poppy.

Los bancos, las empresas de pagos, los minoristas y los proveedores de viajes importan del lado de las empresas. Sus decisiones de implementación revelarán qué modelos de autenticación y permisos superan las revisiones regulatorias y de fraude.

La tercera señal es evidencia de que el modelo de seguridad funciona más allá de demostraciones controladas. Preste atención a modelos públicos de amenazas, auditorías de terceros, eventos de interoperabilidad y correcciones documentadas tras las pruebas.

Un protocolo que permite acciones sobre cuentas atraerá escrutinio. Eso es saludable. Los investigadores deberían poder probar la validación de descubrimiento, la vinculación de tokens, los alcances personalizados, las sesiones de navegador, el manejo de credenciales y las defensas contra la suplantación de agentes.

Estas tres señales se refuerzan mutuamente. El código de referencia posibilita las pruebas. Las implementaciones reales exponen problemas operativos. La revisión independiente identifica debilidades antes de que se propaguen por muchos servicios.

La lista de socios otorga al Sierra Personal Agent Protocol una sólida posición inicial. Abarca las industrias más afectadas cuando los agentes personales pasan de responder preguntas a completar transacciones.

Aun así, los estándares triunfan mediante una implementación repetida, no por el impulso de los anuncios. Las empresas deben exponer capacidades útiles. Los creadores de agentes deben admitir el protocolo de forma coherente. Los usuarios deben comprender y confiar en los permisos que conceden.

Para los desarrolladores, la acción inmediata es revisar el borrador y comparar su modelo de sesión con la arquitectura de autenticación existente. Los comentarios más útiles abordarán incompatibilidades concretas, estados de fallo ausentes o requisitos de seguridad poco claros.

Los compradores empresariales deberían preguntar a los proveedores si la participación implica comentarios sobre el diseño, un piloto o un despliegue comprometido. Esos términos representan niveles de apoyo muy diferentes.

Los usuarios de agentes personales deberían observar dónde aparece realmente el control. ¿Pueden ver las conexiones activas, limitar acciones, revisar el historial y revocar el acceso sin tener que navegar por varios productos?

Poppy intenta sustituir una competencia inestable entre el bloqueo de agentes y el disfraz de agentes por una cooperación explícita. Es un objetivo valioso. El próximo mes debería mostrar si Sierra y sus socios pueden convertir ese objetivo en código que otros puedan implementar de forma segura.