Project Think: Cómo construir agentes de IA de próxima generación en Cloudflare

• Cloudflare anunció Project Think, la próxima versión de su Agents SDK, que ofrece nuevos primitives clave para agentes de larga ejecución, como ejecución duradera, subagentes, ejecución de código en sandbox y sesiones persistentes
• Los agentes de programación existentes tenían limitaciones: solo corrían en laptops locales, generaban costos incluso cuando estaban inactivos y requerían configuración y administración manuales
• A diferencia de las aplicaciones tradicionales, los agentes operan con un modelo 1:1 (una instancia por usuario y por tarea), por lo que una estructura de costos basada en contenedores no es sostenible para soportar decenas de millones de sesiones concurrentes
• Aprovechando el modelo de actores basado en Durable Objects, los agentes logran economías de escala al tener costo de cómputo cero en reposo y reactivarse automáticamente al recibir mensajes
• Como tercera ola de los agentes de IA, apunta a agentes como infraestructura (durabilidad, distribución, serverless y seguridad estructural), con la meta de ofrecer una plataforma donde cualquier desarrollador pueda construir y desplegar agentes para miles de millones de usuarios

---

Resumen de Project Think

• Próxima versión de Cloudflare Agents SDK, con un nuevo conjunto de primitives para construir agentes de larga ejecución y una clase base que las integra
• Primitives principales: ejecución duradera (fibers), subagentes, sesiones persistentes, ejecución de código en sandbox, execution ladder y extensiones autoredactadas
• Las primitives pueden usarse por separado o iniciarse rápidamente mediante la clase base Think

Limitaciones actuales de los agentes de programación

• Herramientas como Pi, OpenClaw, Claude Code y Codex demostraron que, al darle a un LLM la capacidad de leer archivos, escribir código, ejecutarlo y aprender, puede comportarse como un asistente de propósito general
• Estos agentes de programación se usan no solo para código, sino también para administrar calendarios, analizar datasets, negociar compras, presentar impuestos y automatizar flujos de trabajo empresariales
• El patrón siempre es el mismo: el agente lee el contexto, razona, escribe código para actuar, observa el resultado y repite → el código es el medio universal de acción
• Limitaciones actuales:
  • Solo se ejecutan en laptops o VPS costosos: no permiten compartir, colaborar ni cambiar entre dispositivos
  • Generan costos incluso inactivos: el costo mensual fijo se dispara al escalar a nivel de equipo o empresa
  • Requieren instalación y administración manuales: instalar dependencias, gestionar actualizaciones, autenticación y secretos

Problema estructural de los agentes: modelo 1:1

• Las aplicaciones tradicionales procesan a muchos usuarios con una sola instancia, pero los agentes son 1:1: cada agente ejecuta una tarea para un usuario en su propia instancia
• Si 100 millones de trabajadores del conocimiento usan cada uno un asistente agente, se necesitan decenas de millones de sesiones concurrentes
• Con la estructura de costos por contenedor actual, eso no es sostenible; hace falta otra base

Agentes de larga ejecución

• Los agentes actuales son efímeros: desaparecen al terminar la sesión y se interrumpen cuando la laptop entra en suspensión
• Agents SDK, basado en Durable Objects, da a todos los agentes identidad, estado persistente y arranque automático al recibir mensajes
• Modelo de actores: cada agente es una entidad direccionable con su propia base de datos SQLite, y tiene costo de cómputo cero cuando está inactivo
• Ante eventos como solicitudes HTTP, mensajes WebSocket, alarmas programadas o correos entrantes, la plataforma despierta al agente y carga su estado
• Comparación entre Durable Objects y VM/contenedores:
  • Costo en reposo: las VM siempre pagan cómputo completo vs DO cero (hibernación)
  • Escalado: las VM requieren aprovisionamiento manual vs DO escala automáticamente por agente
  • Estado: las VM necesitan una BD externa vs DO SQLite integrada
  • Recuperación: en VM hay que construirla manualmente vs DO reinicio automático de la plataforma, con conservación del estado
  • Enrutamiento: en VM hay que construir load balancers y sticky sessions vs DO mapeo integrado de nombre → agente
  • 10,000 agentes (1% activos cada uno): VM = 10,000 instancias siempre encendidas vs DO = solo unas 100 activas
• El costo marginal de crear un agente nuevo es prácticamente cero → habilita modelos de agentes de “uno por usuario”, “uno por tarea” o “uno por hilo de correo”

Ejecución duradera: Fibers

• Una llamada a LLM puede durar 30 segundos, y un loop de agente multiturno puede durar más; entre tanto, el entorno de ejecución puede desaparecer (deploy, reinicio de plataforma, límites de recursos)
• runFiber(): invocación de función duradera que se registra en SQLite antes de iniciar la ejecución; puede crear checkpoints con stash() y recuperarse al reiniciar mediante onFiberRecovered
• El SDK mantiene al agente automáticamente durante la ejecución del fiber, sin configuración especial
• Para tareas de varios minutos, keepAlive() / keepAliveWhile() evitan la expulsión
• Para trabajos más largos, como pipelines de CI, revisiones de diseño o generación de video, se guarda el job ID y se hiberna tras iniciar el trabajo, reactivándose con el callback

Subagentes: Facets

• No hace falta que un solo agente haga todo el trabajo
• Los subagentes son Durable Objects hijos, colocados junto con el padre, y cada uno tiene SQLite aislado y su propio contexto de ejecución
• Basados en Facets, se ubican junto al agente padre y no comparten datos implícitamente entre subagentes
• La latencia del RPC entre subagentes es similar a una llamada de función, y TypeScript detecta usos indebidos en tiempo de compilación

Sesiones persistentes: Session API

• Los agentes que se ejecutan por días o semanas necesitan algo más que una lista plana de mensajes
• La Session API experimental modela las conversaciones como un árbol, asignando parent_id a cada mensaje
  • Forking: explorar alternativas sin perder la ruta original
  • Compresión no destructiva: en vez de borrar mensajes antiguos, los resume
  • Búsqueda de texto completo: búsqueda full-text de todo el historial con FTS5
• Puede usarse directamente desde la clase base Agent y funciona como la capa de almacenamiento de la clase base Think

De llamadas a herramientas a ejecución de código

• En el enfoque tradicional, el modelo hace una llamada a herramienta → recupera el resultado en la ventana de contexto → repite; cuando hay muchas herramientas, aumentan el costo y la ineficiencia
• 100 archivos = 100 viajes de ida y vuelta con el modelo
• El modelo es mejor escribiendo código para usar sistemas que jugando al juego de llamar herramientas: esa es la idea central de @cloudflare/codemode
• En lugar de llamadas secuenciales a herramientas, el LLM escribe un solo programa que resuelve toda la tarea
• Caso del servidor MCP de la API de Cloudflare: al exponer solo 2 herramientas (search(), execute()), consume unos 1,000 tokens vs unos 1.17 millones de tokens con el enfoque de una herramienta por endpoint → 99.9% menos

Sandbox seguro: Dynamic Workers

• Si el modelo va a escribir código en nombre del usuario, el entorno donde se ejecuta ese código se vuelve la pregunta central
• Dynamic Workers: nuevo entorno aislado V8 creado en tiempo de ejecución en milisegundos, con algunos megabytes de memoria
  • Frente a contenedores, es cerca de 100 veces más rápido y hasta 100 veces más eficiente en memoria
  • Puede crearse de nuevo por solicitud y desecharse tras ejecutar el código
• Diseño clave: modelo de capacidades — en lugar de restringir una máquina de propósito general, parte de un estado casi sin permisos (globalOutbound: null, sin acceso de red), y el desarrollador concede permisos explícitos por recurso mediante bindings
• Cambia la pregunta de “¿cómo evito que esto haga demasiado?” a “¿qué exactamente voy a permitir que haga?”

Execution Ladder

• Un espectro donde el agente escala gradualmente a entornos de cómputo superiores según lo necesite:
  • Tier 0 — Workspace: sistema de archivos virtual duradero basado en SQLite + R2, con lectura, escritura, edición, búsqueda, grep y diff; ejecuta @cloudflare/shell
  • Tier 1 — Dynamic Worker: ejecuta JavaScript generado por LLM en un sandbox aislado sin acceso de red; ejecuta @cloudflare/codemode
  • Tier 2 — agregar npm: @cloudflare/worker-bundler obtiene paquetes del registro, los empaqueta con esbuild y los carga en Dynamic Worker; import { z } from "zod" funciona tal cual
  • Tier 3 — navegador headless: Cloudflare Browser Run para navegar, hacer clic, extraer datos y tomar screenshots; útil para servicios que no soportan MCP o API
  • Tier 4 — Cloudflare Sandbox: ejecuta git clone, npm test, cargo build y más en un entorno con toolchain, repositorios y dependencias configuradas, con sincronización bidireccional con Workspace
• Principio de diseño clave: el agente debe ser útil incluso solo con Tier 0, y cada tier adicional debe ser optativo

Bloques de construcción, no un framework

• Todas las primitives se ofrecen como paquetes independientes: Dynamic Workers, @cloudflare/codemode, @cloudflare/worker-bundler, @cloudflare/shell
• Pueden combinarse directamente con la clase base Agent para usar workspace, ejecución de código y resolución de paquetes en runtime sin adoptar un framework propietario

Stack completo de la plataforma

• Aislamiento por agente: Durable Objects — cada agente tiene su propio mundo
• Costo cero en reposo: DO Hibernation — $0 hasta que el agente despierte
• Estado persistente: DO SQLite — almacenamiento con consultas y transacciones
• Sistema de archivos duradero: Workspace (SQLite + R2)
• Ejecución de código en sandbox: Dynamic Workers + @cloudflare/codemode
• Dependencias en runtime: @cloudflare/worker-bundler — import * from react funciona tal cual
• Automatización web: Browser Run
• Acceso completo al OS: Sandboxes — git, compiladores, test runners
• Ejecución programada: DO Alarms + Fibers
• Streaming en tiempo real: WebSockets
• Conexión con herramientas externas: MCP
• Coordinación entre agentes: subagentes (Facets) — RPC tipado
• Acceso a modelos: AI Gateway + Workers AI (o modelos propios)

Clase base Think

• Un harness unificado que maneja todo el ciclo de vida del chat: loop del agente, persistencia de mensajes, streaming, ejecución de herramientas, reanudación de stream y extensiones
• Subclase mínima: basta implementar getModel() para tener un agente de chat con streaming, persistencia, interrupción/cancelación, manejo de errores, streams reanudables y sistema de archivos Workspace integrado
• Se despliega con npx wrangler deploy
• Elementos sobreescribibles: getModel(), getSystemPrompt(), getTools(), maxSteps, configureSession()
• En cada turno ejecuta el loop agéntico completo: ensamblaje de contexto (comandos base + descripción de herramientas + skills + memoria + historial de conversación) → llamada a streamText → ejecución de llamadas a herramientas (recortando salidas para evitar explosión de contexto) → agrega resultados → repite hasta que el modelo termine o se alcance el límite de pasos

Hooks del ciclo de vida

• Think ofrece hooks en todas las etapas del turno de chat, sin apropiarse de todo el pipeline:
  • beforeTurn() → streamText() → beforeToolCall() → afterToolCall() → onStepFinish() → onChatResponse()
• Así se puede cambiar a un modelo más barato en turnos posteriores, limitar herramientas, pasar contexto del cliente, registrar análisis de todas las llamadas a herramientas o disparar turnos de seguimiento automáticos sin reemplazar onChatMessage

Memoria persistente y conversaciones largas

• Think está construido sobre la Session API, con mensajes en estructura de árbol y branching integrado
• Memoria persistente mediante bloques de contexto: secciones estructuradas del system prompt que el modelo puede leer y actualizar con el tiempo, y que persisten incluso durante la hibernación
• El modelo puede ver algo como "MEMORY (Important facts, use set_context to update) [42%, 462/1100 tokens]" y recordar activamente
• Es posible ejecutar múltiples conversaciones por agente, y hacer forks para explorar caminos distintos sin perder la conversación original
• Cuando el contexto crece, aplica compresión no destructiva: resume mensajes antiguos en lugar de borrarlos, y conserva todo el historial en SQLite
• Búsqueda con FTS5: se puede consultar el historial dentro de una sesión o entre todas las sesiones, y el propio agente puede buscar su pasado con la herramienta search_context

Integración de toda la execution ladder

• Think integra toda la execution ladder con un solo getTools(): configura de una vez las herramientas de workspace, ejecución, navegador, sandbox y extensiones

Extensiones autoredactadas (Self-authored Extensions)

• El agente puede escribir sus propias extensiones: programas TypeScript que se ejecutan en Dynamic Workers y declaran acceso de red y permisos sobre Workspace
• El ExtensionManager de Think empaqueta la extensión (incluyendo dependencias npm si hace falta), la carga en Dynamic Worker y registra nuevas herramientas
• Las extensiones persisten en el almacenamiento DO, por lo que sobreviven incluso cuando el agente entra en hibernación
• Ejemplo: si el usuario hace una pregunta sobre un PR, puede crearse una herramienta github_create_pr que no existía 30 segundos antes
• No se trata de fine-tuning ni RLHF, sino de un bucle de auto-mejora mediante código — TypeScript sandboxeado, auditable y revocable

RPC de subagentes

• Think también funciona como subagente, invocado desde el padre mediante chat() sobre RPC, con soporte para eventos de streaming vía callback
• Cada hijo tiene su propio árbol de conversación, memoria, herramientas y modelo, sin que el padre necesite conocer los detalles

Primeros pasos

• Project Think está en estado experimental; la superficie del API es estable, pero seguirá evolucionando
• Cloudflare ya lo usa internamente para construir su propia infraestructura de agentes en background
• Think usa el mismo protocolo WebSocket que @cloudflare/ai-chat, por lo que los componentes de UI existentes funcionan tal cual
• Si se construyó sobre AIChatAgent, no hace falta cambiar el código del cliente

Las tres olas de los agentes de IA

• Primera ola — chatbots: sin estado, reactivos, frágiles, empiezan desde cero en cada conversación, sin memoria, herramientas ni capacidad de acción; útiles solo para responder preguntas
• Segunda ola — agentes de programación: conservan estado, usan herramientas; herramientas como Pi, Claude Code, OpenClaw y Codex pueden leer codebases, escribir código, ejecutarlo y repetir; demostraron que un LLM con las herramientas adecuadas es una máquina de propósito general, pero solo corren en laptops para un usuario y no garantizan durabilidad
• Tercera ola — agentes como infraestructura: duraderos, distribuidos, estructuralmente seguros, serverless, se ejecutan en internet, sobreviven a fallos, cuestan cero cuando están inactivos y hacen cumplir la seguridad mediante arquitectura, no solo por comportamiento