Semana agentic: Cloudflare publicó un stack de agentes entero en cinco días

Una sola compañía publicó una wallet, un esquema de identidad, una implementación de protocolo stateless y un control plane de inferencia en cinco días laborables. Lo interesante no es el volumen. Es que las cuatro cosas son el mismo producto.

Entre el 2 y el 7 de agosto, Cloudflare corrió su primera Agents Week. El post de apertura del 2 de agosto planteó la premisa sin rodeos: "The cloud we have today, and the web it sits on, were built for people... but agents don't work that way." Lo que siguió no fue un conjunto de features. Fue un intento de ocupar todas las capas que un agente autónomo toca entre despertar y pagar por algo.

Fuera de esa semana hay un lanzamiento más que importa, y apunta en dirección contraria.

1. Los cuatro verbos de la web agentic

El 6 de agosto, Jack Galilee publicó el marco arquitectónico de todo lo demás: un Internet agentic abierto tiene que ser readable, discoverable, callable y payable. Cada verbo salió con un producto.

Readable es markdown en lugar de markup, más Kitesurf, un browser diseñado para correr dentro de Workers. El argumento es de costo: "Every HTML tag rendered for a human that never looks at it is not only a waste of compute but also a pollution of the context window." Discoverable es AI Search y medición para answer engines — "If you are not measurably visible to the agents your customers use, then you are effectively offline for them." Callable es WebMCP y Code Mode. Payable es Wallets más el Monetization Gateway, con una frase que se lee como requisito de spec: "Every paid interaction leaves a receipt. The publisher can prove which agent fetched which page."

La descomposición en cuatro verbos vale la pena robarla, independientemente de lo que opines del vendor. Es el primer marco de este año que pone discovery, invocación y settlement en la misma frase sin colapsarlos en un único protocolo.

2. Wallets y cloudflare.pay: llegó el lado comprador, casi todo como reserva

El 4 de agosto, Cloudflare anunció Cloudflare Wallets y cloudflare.pay. El diseño tiene dos niveles. Una Account Wallet controlada por un humano guarda el saldo. Virtual Wallets por agente gastan desde ahí mediante API keys, bajo allowances, allowlists, tamaño máximo de transacción y topes de gasto definidos por el dueño. Un agente que choca contra un límite puede pedirle a un humano una autorización manual. Los handles son legibles y jerárquicos — el ejemplo que dan es research.example.cloudflare.pay — y la identificación es opcional: el merchant decide si atiende a un agente sin identificar.

El comunicado de prensa es directo sobre el hueco que llena: "When an agent shows up at your door, you need to know who sent it." Y es igual de directo sobre lo que efectivamente salió. La reserva de handles abrió ese día. El acceso completo a la wallet — onramp, offramp y emisión de Virtual Wallets — llega "in the coming months".

La mitad de identidad se apoya en Web Bot Auth: un keypair prueba el agente, un handle vuelve ese keypair legible para un merchant. Es la tercera respuesta distinta a "qué agente está llamando" que ya está en producción o cerca, después de las firmas de Web Bot Auth en la capa HTTP y ERC-8004 en cadena. Ninguna resuelve a las otras.

Un post aparte del 7 de agosto dio una idea de la escala del problema de detección detrás de todo esto: 206 millones de eventos de evaluación Precursor sobre 73,438 zonas en una ventana de 24 horas, con la observación de que el comportamiento "often shifts from human to agentic and back over a session". La detección de bots puntual no sobrevive a eso. La autorización puntual tampoco.

3. MCP 2026-07-28 llegó a infraestructura de producción en nueve días

La especificación salió final el 28 de julio. El 6 de agosto, Cloudflare publicó soporte para ella. La consecuencia es arquitectónica, no cosmética: sin handshake ni estado de sesión — "Each request carries the protocol version, client identity, and client capabilities it needs" — los servidores MCP ahora corren directamente sobre Workers sin necesitar Durable Objects para las sesiones del protocolo.

Ese es el significado práctico del core stateless que analizamos en el deep dive de la spec. Un protocolo atado a sesión obliga a todo deployment a hacer routing sticky o a mantener un objeto de coordinación. Si lo eliminás, un servidor MCP se vuelve un handler HTTP stateless corriente que cualquier instancia puede responder.

La ruta de migración es dual-mode: un único endpoint /mcp acepta tanto las nuevas requests stateless como clientes Streamable HTTP de 2025, así las sesiones legacy se drenan en vez de romperse. Agents SDK v0.20.0 soporta la spec. Citan a David Cramer, cofundador de Sentry, diciendo que la corrieron en producción antes de que la spec estuviera finalizada sin romper prod. Cloudflare también reporta que su Code Mode MCP server "has scaled up to thousands of requests per second and served billions of tool calls".

4. El gateway se consolidó: un saldo, muchos proveedores

El 7 de agosto, Cloudflare fusionó Workers AI y AI Gateway en un solo control plane de IA. Tres propiedades importan para cualquiera que opere un gateway de inferencia.

Primera, un saldo único entre vendors: "you can load a wallet full of credits, and then choose to spend that across OpenAI, Anthropic, Workers AI, or any provider that we support." Segunda, routing model-first — pedís un modelo, el gateway elige el proveedor, y si el primario está al límite de capacidad "transparently load balances you to another provider". Tercera, un smart routing basado en clasificador que selecciona modelos automáticamente, hoy en piloto interno.

Leé esa lista al lado de las cadenas de fallback y el solapamiento es total. Failover entre proveedores y billing unificado ya no son diferenciadores. Son requisitos mínimos, publicados por una compañía cuyo negocio no depende de cobrar por el routing en sí.

5. OSL AgentPay apostó al pluralismo de protocolos

El contrapeso llegó la misma semana y desde fuera de la órbita Cloudflare. El 7 de agosto, OSL Group lanzó OSL AgentPay, infraestructura de pago en stablecoins para agentes de IA, con integración por API disponible desde el primer día.

El campo notable es la lista de compatibilidad. AgentPay soporta x402, AP2 y MPP — el Machine Payments Protocol de Stripe y Tempo — y varias stablecoins, entre ellas USDT, USDC y USDGO. Entre las capacidades declaradas están nano-pagos, cero gas fees, compatibilidad multi-wallet y on/off-ramp fiat.

Eso es un vendor negándose a elegir ganador. Y es el primer producto de pagos que vemos que trata tres protocolos de pago agentic en competencia como una matriz de compatibilidad y no como una apuesta estratégica. Si el pluralismo de protocolos es donde esto aterriza, los adaptadores valen más que la lealtad.

Qué significa para LLM4Agents

La semana produjo una amenaza clara y una oportunidad clara, y vienen del mismo anuncio.

La amenaza: un control plane de inferencia unificado con failover entre proveedores y saldo único de gasto es ahora infraestructura gratuita en una red detrás de la cual ya vive buena parte de la web. Routing y fallback dejan de ser razones para elegir un gateway. Lo que queda como diferenciador real es el modelo de settlement — LLM4Agents cobra por llamada en stablecoins sobre x402 y EIP-3009, sin cuenta de créditos prepagos, sin saldo de vendor que recargar y sin cuenta de cloud que crear. El modelo de Cloudflare es una wallet de créditos que se funda por adelantado, en geografías soportadas, con onramps que todavía no están vivos. Son productos distintos para compradores distintos, y la diferencia hay que enunciarla, no darla por supuesta.

La oportunidad: Cloudflare acaba de construir un lado comprador para exactamente el rail sobre el que LLM4Agents vende. Una Virtual Wallet gastando sobre x402 es un cliente que no requiere trabajo de integración de nuestra parte más allá de implementar bien el challenge. Cada agente que reciba una wallet en esa red es un caller potencial de un endpoint de inferencia con precio en x402. El lado vendedor es donde ya vivimos — ver enforcement en el edge y los nanopagos de Gateway.

El riesgo estratégico no es perder en routing. Es volverse invisible: un agente dentro de la red de un hyperscaler, pagando desde la wallet de esa red, llamando a los modelos de esa red, nunca emite un 402 hacia afuera. Seguir alcanzable significa ser el endpoint por el que vale la pena salir del jardín amurallado — cobertura de modelos que el catálogo de un solo vendor no puede igualar, y precio por llamada en lugar de por crédito prepago.

Cómo mantenerse en la frontera

Seis movimientos, en orden de dependencia.

Uno — pagabilidad, verificada contra un comprador real. Probar el challenge 402 de LLM4Agents contra el stack cliente de Cloudflare apenas se emitan las Virtual Wallets, y confirmar que un agente puede pagar sin tener cuenta con nosotros. Es la única prueba que importa ante la llegada del lado comprador.

Dos — aceptar el nuevo claim de identidad. Tratar un handle cloudflare.pay como metadata de atribución opcional junto a una firma Web Bot Auth, loguearlo por request, y nunca dejar que sustituya a la prueba de pago. La identidad responde quién llamó; el settlement responde si puede.

Tres — publicar la superficie MCP stateless. Eliminar cualquier dependencia de headers de sesión, exponer un endpoint /mcp dual-mode que sirva tanto las requests stateless de 2026-07-28 como clientes Streamable HTTP de 2025, y drenar el camino legacy en lugar de cortarlo.

Cuatro — bajar el costo de contexto de MCP. Adoptar una interfaz estilo Code Mode: una sola tool de ejecución en vez de una definición de tool por endpoint. El overhead de tokens por tool call ya es una superficie competitiva, no un detalle de implementación.

Cinco — publicar recibos. "Every paid interaction leaves a receipt" debería ser una garantía documentada, no una propiedad emergente. Prueba de settlement por llamada, recuperable por el pagador, atada al modelo y al conteo de tokens.

Seis — tratar el rail como plural. Mantener x402 como primario y especificar ya el límite del adaptador, para que AP2 y MPP sean configuración y no una reescritura. OSL publicó tres protocolos en un producto esta semana. Asumir que los compradores esperarán lo mismo.