Los AI agents están evolucionando demasiado rápido para quedarse atrapados en infraestructuras que no siguen el ritmo
Si has seguido la explosión de los coding agents en los últimos meses, sabes de lo que estamos hablando. Herramientas como Pi, OpenClaw, Claude Code y Codex le abrieron los ojos a mucha gente sobre lo que un agente de IA puede hacer cuando tiene acceso a archivos, puede escribir y ejecutar código, y además carga memoria de lo que ha aprendido. De repente, el asunto dejó de parecer una herramienta para desarrolladores y empezó a parecerse a un asistente de verdad — capaz de gestionar calendarios, analizar conjuntos de datos, negociar compras, declarar impuestos y automatizar flujos de trabajo enteros.
El patrón siempre es el mismo: el agente lee contexto, razona sobre él, escribe código para actuar, observa el resultado e itera. El código es el medio universal de acción.
Solo que ahí llegó el problema real. Estos agentes mueren cuando cierras el portátil. Cuestan dinero incluso cuando no están haciendo nada. Y cada uno necesita configuración manual, gestión de dependencias y un entorno propio para ejecutarse. Escala eso para un equipo o una empresa entera y las cuentas no cuadran.
Y hay una cuestión estructural todavía más profunda. Las aplicaciones tradicionales sirven a muchos usuarios desde una única instancia. Los agentes de IA son uno a uno. Cada agente es una instancia única, sirviendo a un usuario, ejecutando una tarea. Si cien millones de profesionales del conocimiento usan un asistente basado en agentes con una concurrencia incluso modesta, necesitas capacidad para decenas de millones de sesiones simultáneas. Con los costes actuales por contenedor, eso es insostenible.
Cloudflare pasó bastante tiempo analizando este problema y llegó a una conclusión que tiene mucho sentido: los agentes de IA necesitan una base completamente diferente a la de las aplicaciones tradicionales para escalar de verdad. Ahí es donde entra el Project Think, la próxima generación del Agents SDK de Cloudflare, construida desde cero para resolver exactamente estos dolores. Vamos a ver qué hay dentro de esta caja. 🧠
Qué es Project Think y por qué importa
El Project Think no es solo una actualización del Agents SDK existente. Es un conjunto de nuevos primitivos que cambian fundamentalmente la forma en que Cloudflare piensa sobre infraestructura para AI agents. La propuesta central es simple de entender, pero compleja de ejecutar: hacer que los agentes de IA funcionen de forma continua, resiliente y económica, sin exigir que el desarrollador gestione cada detalle de la ejecución por debajo.
Los nuevos primitivos incluyen:
- Durable execution con fibers: recuperación de fallos, checkpointing y keepalive automático
- Sub-agents: agentes hijos aislados con su propio SQLite y RPC tipado
- Sesiones persistentes: mensajes en estructura de árbol, forks, compactación y búsqueda full-text
- Ejecución sandboxed de código: Dynamic Workers, codemode y resolución npm en tiempo de ejecución
- La escalera de ejecución: workspace, isolate, npm, browser y sandbox
- Extensiones autoescritas: agentes que crean sus propias herramientas en tiempo de ejecución
Cada uno de estos primitivos se puede usar directamente con la clase base Agent. Montas exactamente lo que necesitas con los bloques individuales, o usas la clase base Think para empezar rápido. La elección es tuya.
Agentes de larga duración: el fin de lo efímero
Los agentes, tal como existen hoy, son efímeros. Funcionan durante una sesión, atados a un único proceso o dispositivo, y después desaparecen. Un coding agent que muere cuando tu portátil entra en modo de suspensión es solo una herramienta. Un agente que persiste — que puede despertar bajo demanda, continuar el trabajo tras interrupciones y mantener el estado sin depender de tu runtime local — empieza a parecer infraestructura de verdad.
El gran diferencial del Project Think comienza con el concepto de durable execution. En términos prácticos, esto significa que un agente puede pausarse en medio de una tarea, sobrevivir a un reinicio de servidor, retomar donde lo dejó y seguir trabajando sin perder contexto. Parece básico, pero es exactamente ese comportamiento el que falta en la mayoría de las implementaciones de agentes hoy.
El Agents SDK está construido sobre los Durable Objects de Cloudflare, dando a cada agente una identidad, estado persistente y la capacidad de despertar mediante un mensaje. Este es el modelo de actores: cada agente es una entidad direccionable con su propia base de datos SQLite. Consume cero computación cuando está hibernado. Cuando algo ocurre — una petición HTTP, un mensaje WebSocket, una alarma programada, un correo recibido — la plataforma despierta al agente, carga su estado y le entrega el evento. El agente hace su trabajo y vuelve a dormir.
Reciba el mejor contenido sobre innovación en su correo electrónico.
Todas las noticias, consejos, tendencias y recursos que buscas, directamente en tu bandeja de entrada.
Al suscribirte al boletín informativo, aceptas recibir comunicaciones de Método Viral. Nos comprometemos a proteger y respetar siempre tu privacidad.
Para ponerlo en perspectiva, aquí va la comparación entre el modelo tradicional y el modelo de Cloudflare:
- Coste en reposo: Las VMs y contenedores mantienen el coste total de computación todo el tiempo. Los Durable Objects tienen coste cero cuando están hibernados.
- Escala: En el modelo tradicional, provisionas y gestionas capacidad. Con Durable Objects, la escala es automática, por agente.
- Estado: Las VMs necesitan base de datos externa. Los Durable Objects tienen SQLite integrado.
- Recuperación: Con VMs, construyes la recuperación tú mismo (process managers, health checks). La plataforma de Cloudflare reinicia automáticamente y el estado sobrevive.
- 10.000 agentes, cada uno activo el 1% del tiempo: en el modelo tradicional, son 10.000 instancias siempre encendidas. Con Durable Objects, unas 100 activas en cualquier momento.
Esto cambia la economía de ejecutar agentes a escala. En vez de tener un agente caro por usuario avanzado, puedes construir un agente por cliente, por tarea o por hilo de correo. El coste marginal de crear un nuevo agente es efectivamente cero.
Sobreviviendo a fallos: durable execution con fibers
Una llamada a un LLM tarda unos 30 segundos. Un loop de agente multi-turno puede funcionar mucho más tiempo. En cualquier punto de esa ventana, el entorno de ejecución puede desaparecer: un deploy, un reinicio de la plataforma, límites de recursos alcanzados. La conexión con el proveedor de modelo se corta permanentemente, el estado en memoria se pierde y los clientes conectados ven el stream detenerse sin explicación.
El runFiber() resuelve esto. Un fiber es una invocación de función durable: registrada en SQLite antes del inicio de la ejecución, capaz de hacer checkpoint en cualquier momento mediante stash(), y recuperable en el reinicio vía onFiberRecovered. El SDK mantiene al agente vivo automáticamente durante la ejecución del fiber, sin necesidad de configuración especial. Para trabajos que llevan minutos, keepAlive() y keepAliveWhile() previenen la evicción durante trabajo activo. Para operaciones más largas, como pipelines de CI o generación de vídeo, el agente inicia el trabajo, persiste el ID del job, hiberna y despierta con el callback.
Sub-agents: cuando un agente no es suficiente
Una de las adiciones más interesantes del Project Think es el soporte nativo a sub-agents. La idea aquí es que las tareas complejas raramente se resuelven con un único agente haciendo todo solo. El patrón más eficiente es tener un agente orquestador que descompone una tarea grande en partes más pequeñas y delega cada parte a un sub-agente especializado.
En la implementación de Cloudflare, los sub-agents son Durable Objects hijos colocalizados con el padre vía Facets, cada uno con su propio SQLite aislado y contexto de ejecución. Los sub-agents están aislados a nivel de almacenamiento — cada uno recibe su propia base de datos, sin compartición implícita de datos entre ellos. La comunicación ocurre vía RPC tipado, y TypeScript captura errores de uso en tiempo de compilación.
En la práctica, esto abre posibilidades que antes requerían arquitecturas bastante más complicadas. Imagina un agente principal recibiendo una solicitud para auditar el código de un repositorio entero, identificar vulnerabilidades y generar un informe detallado. Con sub-agents, puede lanzar múltiples agentes en paralelo, cada uno analizando un módulo diferente del código al mismo tiempo, y después consolidar los resultados en una respuesta final coherente. El tiempo de ejecución baja drásticamente, y el coste también, porque cada sub-agente trabaja de forma enfocada y eficiente sin cargar contexto innecesario.
Sesiones persistentes: conversaciones que sobreviven
Los agentes que funcionan durante días o semanas necesitan más que la típica lista plana de mensajes. La Session API experimental modela esto de forma explícita. Las conversaciones se almacenan como árboles, donde cada mensaje tiene un parent_id. Esto permite ramificación (explorar una alternativa sin perder el camino original), compactación no destructiva (resumir mensajes más antiguos en vez de eliminarlos) y búsqueda full-text en el historial de conversaciones vía FTS5.
Las sesiones son flexibles. Puedes ejecutar múltiples conversaciones por agente y hacer fork de ellas para probar una dirección diferente sin perder la original. Conforme el contexto crece, Think gestiona los límites a través de compactación no destructiva — los mensajes más antiguos se resumen en vez de eliminarse, mientras el historial completo permanece almacenado en SQLite.
Ejecución de código: el modelo escribe, la plataforma ejecuta con seguridad
El tool-calling convencional tiene un formato incómodo. El modelo llama a una herramienta, trae el resultado de vuelta a la ventana de contexto, llama a otra herramienta, lo trae de vuelta, y así sucesivamente. Cien archivos significan cien round-trips por el modelo. Eso es caro y lento.
Pero los modelos son mejores escribiendo código para usar un sistema que jugando al juego del tool-calling. Esa es la idea detrás de @cloudflare/codemode: en vez de llamadas secuenciales a herramientas, el LLM escribe un único programa que maneja la tarea entera. En vez de 100 round-trips al modelo, ejecutas un solo programa. Menos tokens usados, ejecución más rápida y mejores resultados.
Para dar una idea de la escala: el servidor MCP de la API de Cloudflare expone solo dos herramientas (search() y execute()), consumiendo alrededor de 1.000 tokens, frente a aproximadamente 1,17 millones de tokens en el equivalente ingenuo de una herramienta por endpoint. Eso es una reducción del 99,9%. 🤯
El primitivo que faltaba: sandboxes seguros
Una vez que aceptas que los modelos deben escribir código en nombre de los usuarios, la pregunta se convierte en: ¿dónde se ejecuta ese código? Los Dynamic Workers son ese sandbox. Un isolate V8 nuevo creado en tiempo de ejecución, en milisegundos, con pocos megabytes de memoria. Eso es aproximadamente 100 veces más rápido y hasta 100 veces más eficiente en memoria que un contenedor. Puedes crear uno nuevo para cada petición, ejecutar un fragmento de código y descartarlo.
La decisión de diseño crítica es el modelo de capabilities. En vez de empezar con una máquina de propósito general e tratar de restringirla, los Dynamic Workers comienzan sin casi ninguna autoridad ambiente (sin acceso a la red) y el desarrollador concede capabilities explícitamente, recurso por recurso, a través de bindings. La pregunta deja de ser cómo impedir que esta cosa haga de más y pasa a ser qué exactamente queremos que esta cosa pueda hacer.
La escalera de ejecución: cinco niveles de potencia computacional
El modelo de capabilities lleva naturalmente a un espectro de entornos de computación, una escalera de ejecución que el agente sube según lo necesite:
- Tier 0 — Workspace: un sistema de archivos virtual durable respaldado en SQLite y R2. Leer, escribir, editar, buscar, grep, diff.
- Tier 1 — Dynamic Worker: JavaScript generado por el LLM ejecutándose en un isolate sandboxed sin acceso a la red.
- Tier 2 — npm: el @cloudflare/worker-bundler descarga paquetes del registro, hace el bundle con esbuild y carga el resultado en el Dynamic Worker. El agente escribe import y simplemente funciona.
- Tier 3 — Browser: navegador headless vía Cloudflare Browser Run. Navegar, hacer clic, extraer, capturar screenshots. Útil cuando el servicio aún no soporta agentes vía MCP o APIs.
- Tier 4 — Sandbox: un Cloudflare Sandbox configurado con tus toolchains, repositorios y dependencias: git clone, npm test, cargo build, sincronizado bidireccionalmente con el Workspace.
El principio de diseño principal: el agente debe ser útil solo en el Tier 0, y cada tier adicional es acumulativo. El usuario puede añadir capabilities conforme avanza.
La base técnica que hace posible todo esto
Detrás del Project Think, Cloudflare está usando su propia infraestructura de Workers y Durable Objects para sostener toda la arquitectura de ejecución persistente. Los Durable Objects son la pieza central — permiten que cada agente tenga su propio estado aislado, persistido automáticamente, accesible desde cualquier punto de la red global de Cloudflare. Esto elimina la necesidad de bases de datos externas solo para guardar el contexto de ejecución, y coloca el estado del agente mucho más cerca de donde está ocurriendo la computación, reduciendo la latencia de forma significativa.
Otro aspecto técnico relevante es la forma en que Project Think gestiona el modelo de memoria de los AI agents. La plataforma diferencia claramente entre memoria de corto plazo — el contexto de la conversación o tarea actual — y memoria de largo plazo, que persiste entre sesiones y permite que el agente aprenda de interacciones anteriores a través de context blocks. Estas son secciones estructuradas del system prompt que el modelo puede leer y actualizar a lo largo del tiempo, y que persisten a través de la hibernación. El modelo ve indicadores de uso de tokens y puede recordar proactivamente información relevante.
Esta separación no es solo conceptual: tiene implicaciones directas en cómo se ejecuta el agente, cuánto contexto carga hacia el modelo de lenguaje en cada llamada y, en consecuencia, cuánto cuesta cada operación. Un agente bien gestionado en este sentido es dramáticamente más barato que uno que empuja todo el historial de conversaciones al LLM en cada turno.
La clase base Think: todo conectado en un solo lugar
Ahora que hemos visto los primitivos, aquí está lo que ocurre cuando los conectas todos.
Think es una clase con opiniones definidas que gestiona el ciclo de vida completo de chat: loop agéntico, persistencia de mensajes, streaming, ejecución de herramientas, reanudación de stream y extensiones. Tú te enfocas en lo que hace único a tu agente.
La subclase mínima es sorprendentemente simple. Basta con definir el modelo, hacer deploy con npx wrangler deploy, y ya tienes un agente de chat funcional con streaming, persistencia, abort/cancel, manejo de errores, streams reanudables y un sistema de archivos workspace integrado.
Herramientas que usamos a diario
Think toma decisiones por ti. Cuando necesitas más control, puedes sobrescribir lo que quieras:
- getModel(): devuelve el LanguageModel a utilizar
- getSystemPrompt(): define el system prompt
- getTools(): herramientas compatibles con el AI SDK para el loop agéntico
- maxSteps: máximo de rondas de tool-call por turno
- configureSession(): bloques de contexto, compactación, búsqueda, habilidades
Por debajo, Think ejecuta el loop agéntico completo en cada turno: monta el contexto (instrucciones base + descripciones de herramientas + habilidades + memoria + historial de conversación), llama a streamText, ejecuta tool calls con truncamiento de salida para evitar explosión de contexto, añade resultados y hace loop hasta que el modelo termina o se alcanza el límite de pasos. Todos los mensajes se persisten después de cada turno.
Extensiones autoescritas: agentes que crean sus propias herramientas
Think lleva la ejecución de código un paso más allá. Un agente puede escribir sus propias extensiones: programas TypeScript que se ejecutan en Dynamic Workers, declarando permisos para acceso a la red y operaciones en el workspace. El ExtensionManager de Think hace el bundle de la extensión (opcionalmente con dependencias npm), la carga en un Dynamic Worker y registra las nuevas herramientas. La extensión persiste en el almacenamiento del Durable Object y sobrevive a la hibernación.
La próxima vez que el usuario pregunte sobre pull requests, el agente tiene una herramienta github_create_pr que no existía 30 segundos antes. Este es el tipo de loop de automejora que hace que los agentes sean genuinamente más útiles con el tiempo. No a través de fine-tuning o RLHF, sino a través de código. El agente puede escribir nuevas capabilities para sí mismo, todo en TypeScript sandboxed, auditable y revocable.
Las tres olas de los AI agents
Cloudflare identifica tres olas en la evolución de los agentes de IA:
La primera ola fueron los chatbots. Sin estado, reactivos y frágiles. Cada conversación empezaba de cero, sin memoria, sin herramientas y sin capacidad de actuar. Útiles para responder preguntas, pero limitados a solo eso.
La segunda ola fueron los coding agents. Herramientas con estado y capacidad de usar herramientas, como Pi, Claude Code, OpenClaw y Codex. Estos agentes pueden leer codebases, escribir código, ejecutarlo e iterar. Demostraron que un LLM con las herramientas adecuadas es una máquina de propósito general. Pero funcionan en tu portátil, para un único usuario, sin garantías de durabilidad.
Ahora estamos entrando en la tercera ola: agentes como infraestructura. Durables, distribuidos, estructuralmente seguros y serverless. Agentes que funcionan en internet, sobreviven a fallos, no cuestan nada cuando están ociosos y refuerzan la seguridad a través de la arquitectura, no del comportamiento. Agentes que cualquier desarrollador puede construir y desplegar para cualquier número de usuarios.
Lo que Cloudflare está construyendo con Project Think es, esencialmente, una apuesta de que el futuro de los AI agents en producción va a exigir plataformas que traten a los agentes como ciudadanos de primera clase — no como scripts que se ejecutan en servidores genéricos. Durable execution, sub-agents nativos, gestión de estado automática, ejecución sandboxed de código, coordinación entre agentes y extensiones autoescritas son los pilares de esta visión.
El Agents SDK ya está alimentando miles de agentes en producción. Con Project Think y los primitivos que introduce, Cloudflare está añadiendo las piezas que faltaban para hacer estos agentes dramáticamente más capaces. El proyecto está disponible hoy en preview, con APIs que pueden evolucionar conforme se incorpore el feedback de la comunidad. 🚀
