Cloudflare Dynamic Workers: sandboxes rápidos para agentes AI

Cloudflare lanzó recientemente Dynamic Workers en beta abierta - sandboxes rápidos para agentes AI. La empresa afirma que funcionan 100 veces más rápido que los contenedores tradicionales al ejecutar código generado por agentes AI. Es una afirmación bastante seria. Veamos qué hay detrás.

Los contenedores son demasiado pesados para los agentes AI

Los agentes AI modernos no solo responden preguntas, también pueden escribir y ejecutar código sobre la marcha. Un agente puede generar un pequeño script para llamar a una API, procesar datos o completar una tarea. Ese código necesita ejecutarse en algún lugar. Por razones de seguridad, es mejor hacerlo en un sandbox, aislado del resto del sistema.

El enfoque estándar hoy en día es levantar un contenedor para cada tarea. Los contenedores funcionan, pero tienen algunos problemas:

• El arranque en frío (cold start) toma cientos de milisegundos.
• Cada contenedor consume mucha memoria.
• Para evitar retrasos, los contenedores se mantienen “calientes”, pero entonces hay que pagar por ellos incluso cuando están inactivos.
• Para ahorrar, se reutilizan contenedores entre tareas, lo que debilita el aislamiento y crea problemas de seguridad.

Cuando tu sistema tiene unas pocas docenas de usuarios, esto normalmente no es un problema. Pero si estás construyendo un producto donde millones de solicitudes simultáneas activan agentes AI, los contenedores se convierten en un cuello de botella.

V8 Isolates en lugar de contenedores

Cloudflare Dynamic Workers prescinden de los contenedores por completo. En su lugar, utilizan V8 isolates. Es el mismo motor de JavaScript que impulsa Google Chrome y toda la plataforma Cloudflare Workers (que lleva funcionando con esta tecnología ocho años).

Algunos números para entender la diferencia:

Un Dynamic Worker se levanta en milisegundos, ejecuta el código, devuelve el resultado y desaparece. Sin pools calientes, sin costes por inactividad, sin compromisos de reutilización.

Una analogía simple para entender la idea: levantar un contenedor completo para una tarea rápida de AI es como alquilar un apartamento de cinco habitaciones para hacer una sola llamada telefónica. Un Dynamic Worker es la cabina telefónica. Entras, llamas, sales, listo.

Cómo funciona

Tienes un Worker padre (tu aplicación principal) que recibe las solicitudes. Cuando necesita ejecutar código generado por AI, llama a la API Dynamic Worker Loader, que crea un entorno aislado sobre la marcha.

Digamos que estás construyendo un chatbot de atención al cliente. Un cliente hace una pregunta compleja que requiere consultar varias APIs. El LLM genera una función corta en TypeScript, y el Worker padre la ejecuta en un sandbox:

// El Worker padre recibe la consulta del cliente
const worker = env.LOADER.load({
  compatibilityDate: "2026-03-01",
  mainModule: "agent.js",
  modules: { "agent.js": llmGeneratedCode },

  // Dar al sandbox acceso solo a la API de pedidos
  env: { ORDER_API: env.ORDER_SERVICE },

  // Bloquear todo acceso a internet
  globalOutbound: null,
});

// Ejecutar y obtener el resultado
const result = await worker.getEntrypoint().handleQuery(customerId);

El sandbox solo tiene acceso a lo que tú le pasas explícitamente. Sin acceso a internet, sin credenciales de base de datos, sin posibilidad de llegar a nada fuera de la interfaz definida. Incluso si alguien engaña al LLM para que genere código malicioso, el sandbox limita lo que puede hacer.

¿Para qué generar código?

Para una consulta simple como “¿dónde está mi pedido?” se puede escribir un handler de antemano. El código pre-escrito es más rápido, más barato y mucho más predecible. Entonces, ¿en qué casos tiene sentido la generación dinámica de código? Aquí van algunos ejemplos:

Consultas impredecibles. Un cliente pregunta: “Pedí una chaqueta azul el martes, luego la cambié por una negra y además añadí una bufanda, ¿puedes verificar si esos cambios se aplicaron y decirme cuándo llega todo?” Ningún handler pre-escrito cubre esa combinación. Pero un LLM puede determinar la secuencia correcta de llamadas API y componerlas en el momento.

Grandes superficies de API. Si tu plataforma tiene más de 200 endpoints que cubren pedidos, devoluciones, pagos, suscripciones y programas de fidelidad, mantener handlers pre-construidos para cada consulta posible es una enorme cantidad de trabajo de ingeniería. Con la generación de código, simplemente describes la API tipada y el LLM ensambla las llamadas necesarias bajo demanda.

Lógica multi-tenant. Diferentes clientes tienen diferentes reglas. Un retailer acepta devoluciones durante 30 días, otro durante 14, un tercero solo para ciertas categorías. En lugar de construir un motor de reglas complejo que cubra todas las variaciones, el LLM genera código que aplica las reglas correctas para cada contexto.

Integraciones cambiantes. Conectas un nuevo transportista o proveedor de pagos. Con handlers pre-escritos, eso significa actualizar código, testear, desplegar. Con generación de código, actualizas la definición TypeScript de la API y el LLM recoge los cambios inmediatamente.

En la práctica, la mayoría de los equipos usarían ambos enfoques: las consultas comunes se manejan con código pre-escrito, mientras que las complejas o inusuales se envían al LLM. Solo pagas por la generación de código cuando realmente la necesitas.

La idea de “Code Mode”

Dynamic Workers son parte de un concepto más amplio que Cloudflare llama “Code Mode”. En lugar de que el LLM haga muchas tool calls secuenciales (llamar API A, esperar, llamar API B, esperar, llamar API C), el agente escribe un solo script que encadena todo, lo ejecuta en un solo paso y devuelve solo el resultado final.

Cloudflare afirma que este enfoque reduce el consumo de tokens en un 81% comparado con tool calls secuenciales. Su propio servidor MCP funciona exactamente así: expone toda la API de Cloudflare a través de solo dos herramientas (search y execute) en menos de 1.000 tokens. El agente escribe TypeScript contra una API tipada, lo ejecuta en un Dynamic Worker, y solo el resultado vuelve a la ventana de contexto. Los pasos intermedios nunca llegan al LLM.

TypeScript en lugar de OpenAPI

Cloudflare usa interfaces TypeScript en lugar de especificaciones OpenAPI para describir las APIs disponibles para los agentes.

Una API de sala de chat como interfaz TypeScript ocupa unas 15 líneas. La especificación OpenAPI equivalente son más de 60 líneas de YAML. TypeScript es más compacto, más fácil de leer tanto para humanos como para LLMs, y consume menos tokens por llamada API. Si tienes millones de interacciones de agentes, esa diferencia se nota mucho en la factura.

Bibliotecas auxiliares

Junto con el runtime, Cloudflare publicó tres paquetes npm:

• @cloudflare/codemode envuelve la creación de sandboxes y la integración con servidores MCP; puede tomar un servidor MCP existente y reducir todas sus herramientas a un único tool code().

• @cloudflare/worker-bundler resuelve dependencias npm en tiempo de ejecución, así que el código generado por el agente puede importar bibliotecas de terceros como Hono o el Stripe SDK sin configuración previa.

• @cloudflare/shell proporciona un sistema de archivos virtual dentro de un Dynamic Worker (respaldado por SQLite y R2) con métodos tipados para operaciones con archivos. El sistema de archivos soporta escrituras por lotes transaccionales: si cualquier operación del lote falla, todo se revierte.

El modelo de seguridad

Cloudflare es bastante abierto sobre dónde tuvieron que hacer compromisos. Las vulnerabilidades en V8 son más frecuentes que en los hipervisores. Así que su estrategia de defensa tiene varias capas:

• Los parches de seguridad de V8 llegan a producción en cuestión de horas (más rápido que el propio Chrome).
• Un segundo nivel de sandbox personalizado con separación dinámica de tenants según el nivel de riesgo.
• Protección de memoria por hardware mediante MPK (Memory Protection Keys).
• Defensas contra Spectre desarrolladas en colaboración con investigadores.
• Escaneo automático de código que bloquea patrones maliciosos.

También ayuda el corto ciclo de vida de los isolates. Como es barato crearlos y destruirlos en cada solicitud, no hay tentación de reutilizarlos entre tareas, que es un problema de seguridad bastante común en los pools de contenedores calientes.

Limitaciones

Por ahora, Dynamic Workers solo funcionan eficazmente con JavaScript. Python y WebAssembly están técnicamente soportados, pero son significativamente más lentos para fragmentos cortos de código. Gran parte del ecosistema AI vive en Python, especialmente data science y pipelines de ML. Para esos casos de uso, esto no es adecuado.

Además, la capa de ejecución de código está vinculada a Cloudflare. Tus bases de datos, APIs y proveedores de LLM pueden estar en cualquier lugar, pero el sandbox solo funciona en la infraestructura de Cloudflare. Así que necesitarás un plan Workers de pago para usarlos.

Precio

Dynamic Workers cuestan $0.002 por día por cada Worker único cargado, más los cargos estándar de CPU e invocaciones. Durante la beta, la tarifa por Worker no se cobra, así que puedes experimentar libremente. Recomiendo empezar por la documentación y guía de inicio.

Para generación de código puntual, el coste de ejecución es insignificante comparado con el coste de inferencia para generar el código en sí. Una llamada al LLM puede costar unos centavos. La ejecución en el sandbox cuesta fracciones de centavo.

¿Quién necesita esto?

No todo el mundo.

Productos de consumo de alto volumen son la audiencia principal. Plataformas de e-commerce, SaaS de consumo, apps de mensajería, grandes marketplaces, apps fintech con millones de usuarios. El patrón: muchas tareas AI pequeñas e independientes que los usuarios disparan simultáneamente.

Plataformas multi-tenant son la segunda audiencia posible. Empresas que permiten a sus clientes construir automatizaciones personalizadas. Aunque la carga de cada cliente individual sea modesta, miles de tenants ejecutando su propio código suman una demanda seria. Los contenedores a esa escala se vuelven caros. Los isolates ayudan a ahorrar recursos.

¿Herramientas AI empresariales con un número moderado de usuarios? Probablemente no es la audiencia objetivo. Si tus ejecuciones concurrentes de agentes se miden en cientos y no en cientos de miles, la diferencia entre 5 ms y 500 ms de cold start no importa. Un contenedor, una función serverless o incluso ejecutar la lógica directamente en tu workflow engine funcionarán perfectamente sin Dynamic Workers.

El panorama general

El mercado de infraestructura AI se está dividiendo según el tipo de carga de trabajo. Algunos proveedores están construyendo entornos de agentes de larga duración con memoria persistente y ejecución stateful. Cloudflare se mueve en la dirección opuesta: ejecución desechable que aparece al instante y desaparece después de usarse.

Creo que ambos enfoques van a coexistir, pero Cloudflare está haciendo una apuesta concreta: que el número de empresas que necesitan millones de ejecuciones concurrentes y de corta duración de agentes va a seguir creciendo. Si tienen razón, Dynamic Workers podrían convertirse silenciosamente en un bloque fundamental para la próxima ola de productos AI.

Y aunque no sea así, sigue siendo una tecnología elegante en busca de una audiencia más amplia.