Esta mañana Cloudflare ha publicado en su blog que tu agente de IA no necesita un contenedor, necesita un ordenador. El paquete se llama @cloudflare/computer, es código abierto y llega en plena Agents Week, la semana en la que la empresa quiere convencerte de que Workers no es solo hosting barato sino la base de un «Agent Cloud». Yo lo he leído entero y, sinceramente, me suena a la respuesta correcta a un problema real envuelta en un discurso que conviene desmontar antes de que alguien de tu equipo lo meta en producción el viernes por la tarde.
La idea central no es mala. Los agentes de código que funcionan de verdad — Cursor, Claude Code, los entornos que usamos en el día a día — operan sobre un filesystem, una shell y herramientas que pueden ejecutar cosas. Cloudflare propone un runtime unificado donde el agente elige si ejecuta en un isolate (rápido y barato) o en un contenedor (Linux completo, npm, binarios nativos) contra el mismo sistema de archivos sincronizado. Según ellos, los modelos frontier son bastante buenos eligiendo el backend adecuado y reservan contenedores para menos del 10% del trabajo. Eso encaja con lo que veo en foros y en el propio repositorio de GitHub: la abstracción tiene sentido técnico.
Pero aquí empieza lo que me mosquea. El anuncio habla de escalar a cientos de millones de agentes concurrentes, de la «demanda desesperada» de CPU en la industria y de cómo los isolates que llevan diez años apostando son la solución. Todo eso puede ser cierto a escala de plataforma. Lo que no es cierto es que tú, con una pyme o una agencia web, estés a punto de tener cientos de millones de agentes. Lo que sí es cierto es que Cloudflare te está vendiendo otra pieza del ecosistema: Durable Objects, Workers, contenedores bajo demanda, Workers AI, el paquete @cloudflare/think… Cada capa encaja con la anterior, y cada capa te aleja un poco más de poder mover ese agente a otro proveedor sin reescribir media arquitectura.
Fui directo al README del repositorio en GitHub porque en estos anuncios la letra pequeña suele estar ahí, no en el post de marketing. Y efectivamente: el propio Cloudflare dice que el paquete está sujeto a cambios, que es para exploración y prototipos, y que no está pensado para producción en este momento. Repito: la empresa que hoy titula «Your agent needs a computer, not a container» admite en la documentación técnica que aún no deberías confiarle cargas reales de clientes. En mi experiencia, eso no impide que dentro de dos semanas alguien lo despliegue en un proyecto de un cliente porque «Cloudflare es fiable». Spoiler: fiable como CDN no significa fiable como runtime de agentes en preview.
Lo irónico es que esta misma semana, en DEV Community, un agente (sí, un agente escribiendo sobre agentes) responde a la pregunta de Cloudflare sobre qué necesita un agente de la nube. Y no pide más compute ni ventanas de contexto más grandes. Pide verificación barata: identidad, efectos, política, pago, silencio, coste. Menciona que Cloudflare merece crédito por empujar Web Bot Auth y firmas RFC 9421, pero que casi nadie verifica firmas todavía. Y apunta algo incómodo: a partir del 15 de septiembre, los nuevos dominios en páginas con publicidad empezarán a bloquear la categoría Agent por defecto. Es decir, la empresa que construye infraestructura para agentes también está cerrando la puerta a agentes no verificados en parte de la web abierta. Coherente desde seguridad, contradictorio desde marketing.
Microsoft, por su parte, ha sacado en agosto el Agent Framework a disponibilidad general con harness, agentes alojados en Foundry y facturación por consumo. InfoQ lo resume bien: runtime soportado, telemetría OpenTelemetry, conectores para Copilot y Claude. Es otro ecosistema cerrado, pero al menos lo venden como plataforma enterprise con precios publicados (vCPU-hora, memoria, etc.). Cloudflare apuesta por código abierto y experimentación, lo cual me gusta más como enfoque, pero eso no te quita el riesgo operativo si tu negocio depende de algo marcado como «work in progress».
¿Qué implica esto si gestionas webs, hosting o proyectos para clientes? Primero, separar hype de utilidad. Un sandbox unificado para que un agente triage bugs en un repositorio Git montado en un Durable Object es un experimento interesante para un equipo técnico con presupuesto de pruebas. No es la respuesta a «quiero que la IA gestione mi WordPress». Segundo, mirar el lock-in. Si conectas @cloudflare/computer con Workers AI, contenedores Cloudflare y el filesystem en SQLite dentro de un Durable Object, migrar ese agente a AWS, a un VPS propio o incluso a Modal implica rehacer capas que el anuncio presenta como «simple abstracción». Tercero, no confundir Agents Week con madurez. Rita Kozlov ya recicló en abril la narrativa de Workers como infraestructura para software autónomo; ahora añaden la pieza del «ordenador virtual». La estrategia es clara: ser la capa de red, runtime y seguridad por la que pasen todos los modelos, sin necesidad de ganar la carrera de entrenar el LLM más potente. Inteligente para Cloudflare. Menos obvio que te convenga a ti.
En inglés se comenta mucho la tensión entre isolates y contenedores para agentes, y Cloudflare no es el único jugador. Pero sí es de los que más ruido hacen hoy. El post de Matt Carey y Aron Carroll reconoce que hace seis meses lo normal era levantar un contenedor por agente y que ahora los harnesses mueven la ejecución a sandboxes vía herramientas. @cloudflare/computer es el intento de unificar eso en una sola API. Aprecio la honestidad de publicarlo como preview y de abrir el código. Lo que no aprecio es el tono apocalíptico sobre la escasez de CPU cuando lo que estás descargando es, literalmente, un experimento.
Si tienes un cliente que te pregunta «¿montamos agentes en Cloudflare?», mi respuesta hoy sería: prototipa en un entorno aislado, exige confirmación humana antes de cualquier acción con coste o datos sensibles, y no sustituyas procesos que ya funcionan con un runtime en preview. Si necesitas agentes en producción, mira qué ofrece tu proveedor actual — Plesk con Code with AI, integraciones en paneles de hosting, o despliegues en Foundry si ya estás en Azure — y compara lock-in, precio y madurez. No el titular del blog de moda.
Cloudflare acierta al señalar que dar un contenedor entero a cada agente no escala. También acierta al proponer un filesystem compartido entre runtimes. Donde flojea es en la brecha entre la visión de billones de agentes y la realidad de una pyme que solo quiere que un chatbot no alucine precios de su catálogo WooCommerce. Para eso no necesitas @cloudflare/computer. Para eso necesitas datos limpios, permisos claros y un humano que revise antes de publicar. Cosas aburridas que ninguna Agents Week va a anunciar con un diagrama bonito.
Si mañana tu proveedor de hosting te ofreciera integrar @cloudflare/computer en preview sin coste extra pero con la condición de que todo el agente viva dentro de Workers y no puedas exportarlo a otro cloud, ¿lo considerarías avance o trampa?