Agentes de IA sin VMs: el salto de camelAI a Cloudflare
En pocas palabras: camelAI reconstruyó sus agentes de programación sobre Cloudflare Workers, Durable Objects y un sandbox de JavaScript, eliminando las máquinas virtuales. Cada agente ahora vive como un objeto con estado propio y SQLite embebido, que arranca en milisegundos como isolate de V8 en lugar de segundos.
camelAI movió sus agentes de programación fuera de máquinas virtuales y los reconstruyó sobre Cloudflare Durable Objects más un sandbox de JavaScript. El resultado, según la empresa, es una arquitectura serverless donde cada agente vive como un objeto con estado propio, sin contenedores ni VMs que mantener a mano.
Los Durable Objects de Cloudflare son un primitivo de cómputo serverless con estado: cada objeto es una instancia única, identificada de forma global, que junta lógica de ejecución y almacenamiento persistente (SQLite embebido) en el mismo lugar. Cloudflare los usa como base de su Agents SDK para hospedar agentes de IA que mantienen memoria y contexto entre llamadas, sin una base de datos externa colgando al costado.
En 30 segundos
- Qué pasó: camelAI sacó sus agentes de coding de las VMs y los reconstruyó sobre Cloudflare Workers, Durable Objects y un sandbox de JS.
- Por qué importa: los Workers arrancan como isolates de V8 en milisegundos, no como contenedores que tardan segundos en levantar.
- Estado propio: cada Durable Object trae SQLite embebido (hasta 10 GB por objeto según la doc de Cloudflare), WebSockets y alarmas programadas.
- El sandbox: el código que genera el LLM corre aislado, sin acceso libre a red ni a las credenciales del sistema.
- El norte: Cloudflare lo enmarca en Project Think, su apuesta a hospedar “millones de agentes” en el edge.
¿Qué ventajas tiene migrar agentes de IA desde VMs a Cloudflare Durable Objects?
La ventaja principal es que desaparece la capa de máquinas virtuales y contenedores. En un stack Cloudflare agentes IA Durable Objects, cada agente corre como un Worker sobre un isolate de V8, el mismo motor de JavaScript de Chrome, que arranca en milisegundos en vez de los segundos que tarda un contenedor en bootear. Cloudflare afirma que sus isolates levantan en menos de 5 ms. Eso cambia la economía de correr miles de agentes en paralelo.
Ponele que tenés 500 agentes, cada uno atendiendo a un usuario distinto. Con VMs, o mantenés 500 procesos calientes quemando plata las 24 horas, o pagás el arranque en frío cada vez. Con Workers, el código está distribuido en la red de Cloudflare y se ejecuta cerca del usuario, así que la latencia de red baja sin que vos administres regiones.
- Menos mantenimiento: no hay sistema operativo que parchear ni orquestador de contenedores que vigilar.
- Escala automática: Cloudflare crea y descarta objetos según la demanda, sin que definas grupos de autoscaling.
- Latencia global: el cómputo vive en el edge, cerca de quien consulta.
- Modelo de costo por uso: pagás ejecución real, no servidores encendidos esperando.
Eso sí: no es magia. Si tu workload necesita una GPU pegada para inferencia pesada, esto no la reemplaza. El cómputo edge sirve para orquestar al agente, no para correr el modelo grande adentro. Relacionado: orquestar agentes con sistemas CI/CD.
¿Cómo funcionan los Durable Objects como infraestructura para agentes persistentes?
Un Durable Object es una instancia única e identificable a la que Cloudflare enruta siempre al mismo lugar, y ahí está la diferencia clave con una función stateless: mientras un Worker común olvida todo apenas termina la request, el Durable Object recuerda. Cada objeto tiene su propio almacenamiento SQLite embebido (hasta 10 GB por objeto, según la documentación de Cloudflare), su scheduler mediante alarmas y soporte de WebSockets con hibernación.
Para un agente de IA, esto significa que la memoria, la sesión y el contexto de una conversación viven pegados al cómputo. No hay que ir a buscar el estado a un Redis o a una base externa en cada turno. El agente es su propia base de datos.
¿Y qué gana el desarrollador con eso? Se ahorra media arquitectura. La consistencia se vuelve más simple porque cada objeto es de instancia única, así que no hay dos réplicas peleando por escribir el mismo estado al mismo tiempo. Para un agente que mantiene un plan de tareas y va tachando pasos, esa garantía de “un solo escritor” vale oro.
¿Cómo ejecutan código de forma segura? El sandbox de JavaScript
El sandbox de Cloudflare aísla el código que genera el LLM para que corra sin poner en riesgo al resto del sistema. Un agente de coding escribe código y lo ejecuta, y ese código no es de confianza por definición. El sandbox lo encierra: acceso a red controlado, credenciales inyectadas de forma acotada y separación del entorno del host.
Acá viene lo bueno: los isolates de V8 permiten densidad. Miles de sandboxes conviven en la misma infraestructura sin el peso de arrancar un contenedor completo por cada ejecución. Comparado con levantar Docker cada vez que el agente quiere probar tres líneas de código, la diferencia de velocidad y de costo es enorme. Te puede servir nuestra cobertura de elegir entre Jenkins o GitHub Actions.
La “seguridad” total no existe, obvio, y ningún sandbox es infalible. Pero el modelo de aislamiento por isolate más control de red da una superficie de ataque más chica que dejar a un LLM ejecutando shell contra tu VM con permisos amplios.
El caso de camelAI: de VMs a infraestructura edge
camelAI (del equipo qaml-ai) es un agente de IA orientado a análisis de datos y tareas de programación que ejecuta código en nombre del usuario. Según el relato de la propia empresa, su arquitectura anterior corría los agentes dentro de máquinas virtuales con contenedores aislados, el patrón clásico cuando tenés que ejecutar código no confiable.
El cambio: mover esa ejecución a Workers más Durable Objects más el sandbox de JS, apoyándose en el resto del ecosistema de Cloudflare (KV, R2, D1) para almacenamiento. La empresa presenta el nuevo stack como completamente serverless. Sin VMs que aprovisionar, sin flota que patchear.
Ojo con esto: los detalles de la migración y cualquier beneficio medido vienen del propio camelAI, no de un tercero independiente. Tomalo con pinzas hasta que haya benchmarks públicos verificables. Lo que sí es verificable es la plataforma que usaron, porque Durable Objects, Workers y el sandbox están documentados por Cloudflare.
VMs con contenedores frente a Durable Objects: comparación
| Criterio | VMs + contenedores (Docker/gVisor) | Cloudflare Durable Objects + sandbox JS |
|---|---|---|
| Arranque | Segundos (boot de contenedor) | Milisegundos (isolate V8, <5 ms según Cloudflare) |
| Estado del agente | Base externa (Redis/Postgres) | SQLite embebido en el objeto (hasta 10 GB) |
| Escalado | Autoscaling manual de grupos | Automático por objeto, bajo demanda |
| Distribución geográfica | Por región que configurás | Edge global sin gestión de regiones |
| Mantenimiento | SO, parches, orquestador | Serverless, gestionado por Cloudflare |
| GPU / inferencia pesada | Soportado en la VM | No apto (orquestación, no inferencia local) |
¿Cómo construir agentes con Cloudflare?
Se arranca con el Agents SDK de Cloudflare, que está construido sobre Durable Objects. La lógica del agente vive en una clase que representa el objeto durable, y ahí adentro tenés estado, WebSockets para streaming y alarmas para tareas programadas. Alrededor sumás KV para pares clave valor rápidos, R2 para objetos grandes tipo S3, D1 si querés SQL relacional y Queues para trabajo asíncrono. Más contexto en ejecutar agentes sin depender de APIs.
El cambio mental respecto a las VMs es fuerte. Venís de pensar en procesos de larga vida y pasás a pensar en objetos que se despiertan, atienden, guardan estado y se duermen. Subís el agente, mantiene su sesión solo, se hiberna cuando no hay tráfico y revive con el estado intacto cuando llega el próximo mensaje, sin que vos toques un scheduler ni levantes un contenedor a mano.
Entre las herramientas accesibles hay automatización de navegador, el code sandbox y búsqueda con IA. Si sos dev en Argentina y querés desplegar el frontend o APIs que consumen estos agentes, para el hosting y los dominios podés apoyarte en donweb.com y dejar el cómputo edge en Cloudflare.
¿Cuándo conviene migrar tu infraestructura de IA a Durable Objects?
Conviene cuando la latencia global es prioridad, cuando tu carga es variable en vez de un flujo parejo 24/7, y cuando tenés un equipo chico que no quiere administrar servidores. El modelo por uso premia a quien tiene picos y valles, porque no pagás capacidad ociosa.
- Sí tiene sentido: agentes con muchas sesiones concurrentes, carga impredecible, presupuesto OPEX ajustado, equipo reducido.
- No tanto: workloads de GPU intensiva, sistemas legacy difíciles de reescribir, o requisitos de multinube obligatoria.
- Zona gris: apps con dependencias nativas pesadas que asumen un SO completo. Habría que ver cuánto hay que reescribir.
Roadmap: qué sigue con Project Think
Cloudflare enmarcó todo esto en Project Think, su plan para ser la plataforma donde, en sus palabras, vivan millones de agentes de IA. La visión incluye ejecución duradera de agentes, sub-agentes que se coordinan, sesiones persistentes y mecanismos de pago entre agentes. Es un tiro directo al terreno de AWS SageMaker, Google Vertex AI y Azure AI, pero desde el ángulo del edge en vez del datacenter tradicional.
Qué está confirmado y qué no
- Confirmado: Durable Objects tienen SQLite embebido, alarmas y WebSockets, según la documentación oficial de Cloudflare.
- Confirmado: Cloudflare tiene un Agents SDK y un sandbox para ejecutar código, ambos documentados.
- Confirmado: Cloudflare comunicó Project Think y la expansión de su nube de agentes en su comunicado de prensa de 2026.
- Pendiente de verificación independiente: las métricas y motivaciones de la migración de camelAI, que hoy salen del propio proveedor.
- Sin dato público: costos exactos comparados entre el stack viejo de camelAI y el nuevo.
Errores comunes al mover agentes a Durable Objects
- Meter todo en un solo objeto: un Durable Object es de instancia única, así que si concentrás miles de usuarios en uno, lo convertís en cuello de botella. Corregí modelando un objeto por usuario o por sesión.
- Esperar correr el modelo adentro: el edge orquesta, no hace inferencia de un LLM grande local. La inferencia pesada sigue yendo a una API o a hardware con GPU.
- Ignorar el límite de 10 GB por objeto: el SQLite embebido tiene tope. Para datos grandes o compartidos, usá R2 o D1 en vez de inflar el objeto.
- Confiar de más en el sandbox: aísla, pero seguí aplicando principio de menor privilegio con las credenciales que le inyectás al código del agente.
Preguntas Frecuentes
¿Qué son los Durable Objects de Cloudflare?
Son un primitivo serverless con estado: cada objeto es una instancia única e identificable de forma global que combina cómputo y almacenamiento persistente (SQLite embebido) en el mismo lugar. Cloudflare los usa como base de agentes de IA que necesitan recordar contexto entre invocaciones sin una base de datos externa.
¿Por qué una plataforma de IA migra sus agentes de VMs a Cloudflare?
Para eliminar el overhead de contenedores y VMs. Los Workers arrancan como isolates de V8 en milisegundos, escalan solos y corren en el edge cerca del usuario. Eso baja latencia y costo operativo frente a mantener una flota de servidores encendida todo el día. Lo explicamos a fondo en seguridad y privacidad en ejecución remota.
¿Qué es un sandbox de JavaScript en Cloudflare?
Es un entorno aislado donde corre el código que genera un LLM sin acceso libre al host ni a la red. Cloudflare lo ofrece para que agentes autónomos ejecuten código propio con control de credenciales y de conexiones, aprovechando la densidad de los isolates de V8.
¿Cuánto almacenamiento tiene un Durable Object?
El backend SQLite de un Durable Object soporta hasta 10 GB por objeto, según la documentación de Cloudflare. Para volúmenes mayores o datos compartidos entre agentes conviene usar R2 (objetos tipo S3) o D1 (SQL relacional) en lugar de forzar el estado dentro del objeto.
¿Sirve Cloudflare para correr la inferencia del modelo?
No para inferencia pesada de modelos grandes. Durable Objects y Workers orquestan al agente, manejan estado y ejecutan código liviano en el edge. La inferencia del LLM sigue corriendo contra una API o hardware con GPU, fuera del objeto durable.
Conclusión
Lo que cambió es el lugar donde vive un agente de IA: de una VM con contenedores a un objeto serverless con estado propio en el edge. Para equipos chicos con cargas variables, sacarse de encima el mantenimiento de servidores y el arranque lento de contenedores es un golazo. El punto es que no aplica a todo: si dependés de GPU o de un SO completo, el modelo se te queda corto.
Qué hacer ahora: si estás evaluando agentes, probá el Agents SDK con un caso acotado, medí latencia y costo real contra tu stack actual, y esperá benchmarks independientes de casos como el de camelAI antes de mover producción entera. La plataforma es sólida y está documentada. Las promesas de migración específicas, tomalas con pinzas hasta ver números de terceros.
