Stripe lanzó Projects el 30 de abril de 2026, un protocolo comercial que permite a los agentes de IA crear cuentas, comprar dominios, actualizar planes e implementar infraestructura en nombre de propietarios humanos. Cloudflare, Vercel y Netlify se enviaron como socios de lanzamiento. El protocolo se ejecuta en paralelo al Protocolo de Comercio Agentic existente de Stripe, que maneja el comercio minorista. Juntos, los dos protocolos definen una clara división entre comprar cosas (ACP) y comprar capacidades (Proyectos).
Esa división es el hecho estructural que vale la pena considerar. La primera ola de comercio de agentes, desde septiembre de 2025 hasta principios de 2026, tuvo forma minorista. Los agentes exploraron catálogos de productos, agregaron artículos a los carritos, completaron pagos en minoristas como Etsy, Walmart y Glossier. El modelo mental siempre fue una versión digital de un comprador humano. Stripe Projects rompe ese marco. El comprador sigue siendo un agente que actúa bajo la autorización del usuario, pero el comerciante es una plataforma en la nube, el catálogo es un conjunto de planes y recursos en lugar de productos, y la transacción se completa mediante el aprovisionamiento de capacidad en lugar de enviar una caja.
La compra de infraestructura es la segunda categoría comercial de la web agentic, y las preguntas de auditoría para los proveedores de esta categoría no son las mismas que las preguntas de auditoría para los minoristas.
Qué hace realmente Stripe Projects
Stripe Projects expone cuatro flujos principales a agentes de IA que actúan bajo la autorización del usuario.
El primero es la creación de cuenta. Un agente puede registrar una nueva cuenta en un proveedor participante en nombre de un propietario humano, utilizando la identidad verificada y el instrumento de pago del propietario. El proveedor recibe una solicitud de registro estructurada que incluye la identidad del propietario, la identidad del agente y el alcance de la autorización.
El segundo es la compra de planes y productos. Un agente puede leer el catálogo de planes, recursos o dominios del proveedor, seleccionar el que coincida con los requisitos establecidos por el propietario y completar la compra. El flujo utiliza tokens de pago compartidos para la transacción real, el mismo ACP primitivo que utiliza para el comercio minorista. El token tiene como alcance el proveedor, la cantidad y el período de tiempo.
El tercero es el aprovisionamiento y la configuración. Después de la compra, el agente puede configurar los recursos para el propietario. La descripción del lanzamiento de Cloudflare lo menciona explícitamente: un agente que compra una cuenta de Cloudflare también puede configurar registros DNS, implementar un trabajador, adjuntar un dominio y producir una configuración funcional al final del flujo en lugar de solo una factura paga.
El cuarto es la gestión de suscripciones. Las relaciones continuas, incluidas actualizaciones, degradaciones, cambios en el ciclo de facturación y cancelaciones, son abordables por el agente. El agente puede actuar según las instrucciones del propietario para cambiar el estado de la suscripción en cualquier momento. El proveedor recibe una solicitud autenticada del agente, valida la autorización y actualiza la suscripción.
Los cuatro flujos juntos cubren el ciclo de vida de una relación de infraestructura. Un agente puede iniciar la relación, ejecutar una transacción, configurar el trabajo y mantener la suscripción a lo largo del tiempo. El equivalente minorista sería un agente que no solo comprara zapatillas sino que también las devolviera, las cambiara por una talla diferente y gestionara la membresía de fidelidad. La mayoría de los agentes minoristas hoy en día se detienen en la compra.
Por qué se lanzaron Cloudflare, Vercel y Netlify
La cohorte de lanzamiento indica la categoría a la que Stripe se dirige primero. Los tres socios de lanzamiento se ubican en la capa de plataforma de desarrollador de la infraestructura de la nube: computación de borde, plataformas de implementación y entrega de contenido. Ninguno de ellos es proveedor de nube de propósito general en el molde de AWS, Azure o GCP. La elección parece deliberada.
La descripción del lanzamiento de Cloudflare cubrió el ciclo de vida completo. Los agentes crean cuentas de Cloudflare, registran dominios, adjuntan los dominios a la cuenta, implementan trabajadores y configuran registros DNS. La transacción es una parte del flujo y la configuración es el resto. Cloudflare enmarcó los proyectos como un aprovisionamiento de infraestructura impulsado por agentes que se completa produciendo una configuración funcional, no completando un pago.
Vercel publicó una entrada en el registro de cambios que respalda las compras del plan Pro a través de Proyectos. La integración cubre específicamente el flujo de actualización: un agente puede mover la cuenta Vercel de un propietario humano del nivel gratuito al nivel Pro, y la relación de facturación se administra a través de Proyectos a partir de ese momento.
Netlify se lanzó con un anuncio en LinkedIn del director ejecutivo Matthias Biilmann. El marco de Netlify enfatizó que la integración cubre tanto la creación de nuevas cuentas como la gestión de suscripciones de cuentas existentes, las dos mitades de la relación con el cliente.
La característica compartida de la cohorte de lanzamiento es que los tres proveedores ya tenían superficies de productos API primero antes de Proyectos. La API de Cloudflare, la API de Vercel y la API de Netlify se crearon para flujos de trabajo impulsados por desarrolladores. Projects se encuentra encima de esas API y agrega la capa de protocolo de comercio específicamente para los agentes. Los proveedores con superficies API-first son los proveedores que pueden enviar soporte para proyectos más rápido. Los proveedores que solo exponen paneles de control orientados a humanos tienen una construcción más sustancial por delante.
La categoría que Stripe señala primero es la infraestructura de nube adyacente al desarrollador. El siguiente sonido, plausiblemente, son las suscripciones SaaS para audiencias que no son desarrolladores: herramientas de gestión de proyectos, plataformas de marketing, software de diseño, cualquier cosa que venda una suscripción con una escalera de niveles. El siguiente anillo es la nube de uso general y el SaaS B2B tradicional. Ninguno de ellos se ha enviado todavía. La pregunta para cada proveedor en esas categorías es si llegar temprano o esperar.
En qué se diferencia Stripe Projects de ACP
ACP y Stripe Projects comparten la misma infraestructura de pago subyacente. Ambos funcionan con las vías de pago de Stripe. Ambos pueden usar tokens de pago compartidos para la transacción del agente en nombre del usuario. Ambos pasan por Stripe Radar para la detección de fraude. La plomería compartida es significativa y probablemente sea la razón por la que ambos protocolos pueden coexistir limpiamente bajo el mismo proveedor.
Las diferencias están en la capa de instrumentación del lado comercial.
La ACP supone que un comerciante minorista expone un catálogo de productos. El agente lee el catálogo a través de la superficie Feed de ACP, selecciona productos y completa el pago. La responsabilidad del comerciante es mantener limpio el catálogo y manejar el punto final de pago completo. El trabajo del agente es leer, seleccionar y confirmar. La mayoría de los patrones con forma de comercio dentro de ACP se asignan claramente a los sitios web de comercio electrónico existentes.
Projects asume que el comerciante expone una capacidad o suscripción. El catálogo es un conjunto de planes, niveles, recursos o dominios. Los criterios de selección son diferentes a los del comercio minorista: un agente que compra un plan Vercel Pro no optimiza el tamaño, el color y las opiniones de los clientes; es comparar los límites de recursos del plan con la carga de trabajo indicada por el propietario. La tarea de lectura del agente se parece más a una hoja de especificaciones de producto que a una página de listado de productos. Los comerciantes que respaldan proyectos deben exponer esas especificaciones en una estructura que los agentes puedan leer, no solo en una página de precios accesible para humanos.
La forma de autorización también difiere. ACP autoriza una compra única, mientras que Proyectos autoriza una relación continua. Un agente que compra a través de ACP necesita permiso para la transacción específica. Un agente que compra a través de Proyectos necesita permiso para realizar la transacción y, a menudo, permiso para administrar la suscripción resultante. Las concesiones de autorización del lado del usuario son más amplias para los Proyectos, y las verificaciones de autorización del lado del comerciante deben mantenerse al día con ese alcance más amplio.
El panorama de la detección de fraudes también es diferente. Las señales de fraude de la ACP se basan en patrones a nivel de transacción: tarjeta conocida, dirección de envío conocida, composición de compra plausible. Las señales de fraude de proyectos se basan en patrones a nivel de relación: creación de cuentas en condiciones inusuales, cambios de configuración que exceden la autorización indicada por el agente, aprovisionamiento de recursos que no coincide con la carga de trabajo verificada del propietario humano. Stripe Radar maneja ambos, pero el modelo tiene que aprender el segundo patrón por separado del primero.
La superficie de compra de infraestructura tiene diferentes preguntas de auditoría
Los proveedores que desean que los agentes puedan comprarlos a través de Proyectos se enfrentan a una auditoría diferente a la de los minoristas a los que se les audita la preparación de ACP o UCP.
La primera pregunta de auditoría es si la superficie de creación de cuentas acepta la incorporación programática. La mayoría de los proveedores de nube y SaaS crearon sus flujos de registro para usuarios humanos que ingresan direcciones de correo electrónico y las verifican, y luego pasan por un asistente de incorporación. Los agentes que trabajan con la autorización del usuario necesitan un punto final de registro estructurado que acepte la identidad verificada del propietario, la identidad del agente y el alcance de la autorización como una sola solicitud. Los proveedores cuya única ruta de registro es un formulario de página de marketing con verificación por correo electrónico no pueden ser comprados por agentes hoy en día, independientemente de lo que diga su página de precios.
La segunda es si el plan o catálogo de productos está expuesto en una estructura que un agente pueda leer. Las páginas de precios diseñadas para el consumo humano suelen presentar planes en tablas de comparación de características con textos de marketing intercalados. Los agentes que leen esas páginas tienen que analizar la tabla semánticamente, inferir equivalencias de características entre planes y adivinar los límites de recursos implícitos en el texto de marketing. Un proveedor que expone un catálogo limpio y estructurado a través de Proyectos o mediante un punto final paralelo legible por el agente elimina el problema de inferencia. El proveedor que no lo hace es el que el agente omite o configura mal.
El tercero es si la superficie de suscripción y facturación maneja las actualizaciones, degradaciones y cancelaciones iniciadas por el agente sin necesidad de que un humano inicie sesión en un panel. La mayoría de los flujos de facturación de SaaS asumen que el propietario humano es quien realiza los cambios. Proyectos autoriza al agente a realizar cambios en nombre del ser humano. Los proveedores cuyo flujo de facturación requiere autenticación a nivel de sesión por parte del usuario humano, sin una ruta para un agente autenticado que actúe bajo delegación del usuario, no pueden manejar la administración de suscripciones de Proyectos, incluso si pueden manejar la creación de cuentas de Proyectos.
El cuarto, más sutil, es si la documentación de cara al cliente del proveedor está en condiciones de ser consumida por los agentes. Un agente que compra infraestructura para un propietario humano a menudo necesita leer la documentación del producto para tomar la decisión de comprar o configurar: qué plan cubre la carga de trabajo, qué característica requiere el nivel superior, qué paso de configuración debe realizarse antes de que la implementación pueda tener éxito. La documentación escrita para desarrolladores humanos, con suposiciones implícitas sobre conocimientos previos, es más difícil de usar para los agentes que la documentación escrita con respuestas canónicas limpias por pregunta. La auditoría del comercio minorista no incluye un eje de legibilidad de la documentación. La auditoría de compra de infraestructura sí lo hace.
Cada uno de los cuatro es una auditoría independiente. La mayoría de los proveedores hoy en día no tienen ninguno de los cuatro disponibles para el acceso de los agentes. Algunos tienen uno o dos. Los proveedores que auditen los cuatro y solucionen las deficiencias son los proveedores a los que los agentes impulsados por proyectos podrán contactar durante los próximos doce meses.
Qué significa Stripe Projects si su sitio web vende suscripciones o servicios
Tres categorías de proveedores deberían leer el lanzamiento del 30 de abril como una señal prospectiva y no como un evento que no los afecta.
El primero son los proveedores de SaaS que venden productos de suscripción. Herramientas de gestión de proyectos, plataformas de diseño, software de marketing, herramientas para desarrolladores, servicios de análisis. Si un usuario puede configurar un agente para administrar sus suscripciones y el usuario está dispuesto a delegar ese trabajo, Proyectos es el protocolo que el agente utilizará. Los proveedores de SaaS que no aparecen en el catálogo legible de Proyectos perderán esos flujos de trabajo frente a los proveedores que sí lo hacen. La opción es ser legible por el agente a través de Proyectos o ser completamente invisible para ese flujo.
El segundo son los proveedores de hosting, DNS e infraestructura de nube fuera del grupo de lanzamiento. Las categorías que Cloudflare, Vercel y Netlify ya cubren ahora pueden ser compradas por agentes. Las siguientes son las categorías adyacentes, que incluyen alojamiento especializado, plataformas de seguridad, entrega de contenido, observabilidad y base de datos como servicio. Los proveedores de esas categorías adyacentes que ven cómo la cohorte de lanzamiento tiene éxito y no se mueven están apostando a que sus clientes seguirán haciendo el trabajo de configuración ellos mismos. Esa apuesta es plausible hoy y será menos plausible cada trimestre hasta el resto de 2026.
El tercero, más interesante, son los proveedores de servicios profesionales que venden trabajo de participación estructurada. Todo lo que se vende con un alcance definido a un precio definido, incluidos contratos de agencia, contratos independientes, consultoría estructurada y ofertas de servicios empaquetados. Actualmente, el protocolo no aborda estas categorías, pero la brecha será la próxima superficie sobre la que alguien construya. Un usuario con un agente autorizado que puede comprar infraestructura puede autorizar al mismo agente a comprar servicios estructurados de un proveedor conocido. Los proveedores que ahora piensan en cómo exponer su catálogo de servicios en una estructura legible por los agentes estarán en condiciones de ofrecer soporte cuando llegue la capa de protocolo.
La versión más corta de las tres: la compra de infraestructura es la segunda categoría comercial de la web agencial, la auditoría es diferente del comercio minorista, y los proveedores que ejecuten esa auditoría temprano serán los que los agentes podrán encontrar cuando el usuario delega el trabajo.
Más recursos:
Esta publicación se publicó originalmente en No Hacks.
Imagen de portada: Roman Samborskyi/Shutterstock
