Project Think: desarrollar la próxima generación de agentes de IA en Cloudflare

Hoy presentamos Project Think: la nueva generación del SDK de agentes. Project Think es un conjunto de nuevas primitivas para el desarrollo de agentes de larga duración (ejecución duradera, subagentes, ejecución de código en un sandbox, sesiones persistentes) y una clase base prescriptiva que conecta todas ellas. Utiliza las primitivas para crear exactamente lo que necesitas, o utiliza la clase base para empezar rápidamente.

A principios de este año un suceso cambió nuestra forma de pensar sobre la IA. Herramientas como Pi, OpenClaw, Claude Code y Codex demostraron una idea sencilla pero muy interesante: si equipas a un LLM con la capacidad para leer archivos, escribir código, ejecutarlo y recordar lo que ha aprendido, el resultado es algo que se parece menos a una herramienta para desarrolladores y más a un asistente de uso general.

Estos agentes de programación ya no solo escriben código. Los usuarios los utilizan para gestionar calendarios, analizar conjuntos de datos, negociar compras, declarar impuestos y automatizar flujos de trabajo empresariales completos. El patrón es siempre el mismo: el agente lee el contexto, razona sobre él, escribe el código necesario para realizar determinadas acciones, observa el resultado y repite el proceso. El código es el marco universal de acción.

Nuestro equipo ha estado utilizando estos agentes de programación a diario. Y seguíamos topándonos con los mismos obstáculos:

• Su ejecución solo es posible en tu portátil o en un costoso VPS: no es posible el uso compartido, la colaboración ni la transferencia entre dispositivos.

• Son caros cuando están inactivos: tienen un coste mensual fijo, utilices o no el agente. Si amplías su uso a un equipo o a una empresa, el coste aumenta rápidamente.

• Requieren gestión y configuración manual: como la instalación de dependencias, la gestión de actualizaciones, la configuración de identidad y los secretos.

Además, presentan un problema estructural más profundo. Las aplicaciones tradicionales dan servicio a muchos usuarios desde una sola instancia. Como mencionamos en nuestra publicación de bienvenida a la Agents Week, los agentes ofrecen un modelo uno a uno. Cada agente es una instancia exclusiva que da servicio a un usuario y que ejecuta una tarea. Un restaurante tiene una carta y una cocina optimizada para elaborar los platos en gran cantidad. Un agente es más como un chef personal: distintos ingredientes, distintas técnicas y distintas herramientas cada vez.

Eso cambia fundamentalmente el desafío de su ampliación. Si cien millones de profesionales del conocimiento utilizaran cada uno un asistente agéntico, incluso con un grado de simultaneidad no muy alto, necesitarías capacidad para decenas de millones de sesiones simultáneas. Con los costes actuales por contenedor, eso es insostenible. Necesitamos una base distinta.

Y eso es en lo que hemos estado trabajando.

Project Think incluye un conjunto de nuevas primitivas para el SDK de agentes:

• Ejecución duradera con fibras: recuperación tras fallos, puntos de control, keepalive automático.

• Subagentes: agentes secundarios aislados con su propio SQLite y RPC con tipo.

• Sesiones persistentes: mensajes con estructura de árbol, bifurcación, compactación y búsqueda de texto completo.

• Ejecución del código en sandbox: Dynamic Workers, codemode, resolución npm en tiempo de ejecución.

• La secuencia de ejecución: espacio de trabajo, aislamiento, npm, navegador, espacio aislado.

• Extensiones de creación propia: agentes que escriben sus propias herramientas en tiempo de ejecución.

Cada una de estas primitivas se puede utilizar directamente con la clase base Agent. Crea exactamente lo que necesitas con las primitivas, o utiliza la clase base Think para empezar rápidamente. Veamos qué hace cada una.

Los agentes, tal como existen hoy en día, son efímeros. Se ejecutan durante una sesión, vinculados a un único proceso o dispositivo, y luego desaparecen. Un agente de programación que desaparece cuando tu portátil está en reposo, eso es una herramienta. Un agente persistente, es decir, que puede activarse bajo demanda, continuar funcionando después de una interrupción y mantener el estado sin depender de tu entorno de ejecución local, empieza a parecerse a una infraestructura. Y cambia por completo el modelo de ampliación de los agentes.

El SDK de agentes se basa en Durable Objects para equipar a cada agente con una identidad, un estado persistente y la capacidad de activarse al recibir un mensaje. El modelo actor es el siguiente: cada agente es una entidad direccionable con su propia base de datos SQLite. No consume recursos de proceso cuando está en hibernación. Cuando se produce algún evento (una solicitud HTTP, un mensaje WebSocket, una alarma programada, un correo electrónico entrante), la plataforma activa al agente, carga su estado y le entrega el evento. El agente completa su trabajo y se desactiva de nuevo.

	Máquinas virtuales/contenedores	Durable Objects
Coste por inactividad	Coste de proceso completo, siempre	Cero (en hibernación)
Escalabilidad	Suministro y gestión de la capacidad	Automática, por agente
Estado	Base de datos externa necesaria	SQLite integrada
Recuperación	Función que debes desarrollar tú (gestores de procesos, comprobaciones de estado)	Mantenimiento del estado cuando se reinicia la plataforma
Identidad/enrutamiento	Función que debes desarrollar tú (equilibradores de carga, sesiones persistentes)	Función integrada (nombre → agente)
10 000 agentes, cada uno activo el 1 % del tiempo	10 000 instancias siempre activas	Unos 100 activos en cualquier momento

Esto cambia el modelo económico de la ejecución de agentes a escala. En lugar de "un costoso agente por usuario avanzado", puedes crear "un agente por cliente" o "un agente por tarea" o "un agente por hilo de correo electrónico". El coste marginal de generar un nuevo agente es prácticamente cero.

Una llamada a un LLM tarda 30 segundos. Un bucle de agente de varios turnos puede durar mucho más tiempo. En cualquier momento durante ese intervalo, el entorno de ejecución puede desaparecer (ya sea por una implementación, por un reinicio de la plataforma o porque se ha alcanzado el límite de algún recurso). La conexión ascendente con el proveedor de modelos se interrumpe de forma permanente, se pierde el estado guardado en la memoria y los clientes conectados ven cómo se detiene la transmisión, sin ninguna explicación.

runFiber() resuelve este problema. Una fibra es una invocación de función duradera: se registra en SQLite antes de que comience la ejecución, se puede comprobar en cualquier punto de control mediante stash() y se puede recuperar al reiniciar mediante onFiberRecovered.

import { Agent } from "agents";

export class ResearchAgent extends Agent {
  async startResearch(topic: string) {
    void this.runFiber("research", async (ctx) => {
      const findings = [];

      for (let i = 0; i < 10; i++) {
        const result = await this.callLLM(`Research step ${i}: ${topic}`);
        findings.push(result);

        // Checkpoint: if evicted, we resume from here
        ctx.stash({ findings, step: i, topic });

        this.broadcast({ type: "progress", step: i });
      }

      return { findings };
    });
  }

  async onFiberRecovered(ctx) {
    if (ctx.name === "research" && ctx.snapshot) {
      const { topic } = ctx.snapshot;
      await this.startResearch(topic);
    }
  }
}

El SDK mantiene el agente activo automáticamente durante la ejecución de la fibra, sin necesidad de una configuración especial. Para los trabajos que duran unos minutos, keepAlive()/keepAliveWhile() evita el desalojo mientras el trabajo está activo. Para operaciones más largas (canalizaciones de CI, revisiones de diseño, generación de vídeo), el agente inicia el trabajo, conserva el ID del trabajo, hiberna y se activa cuando se devuelve la llamada.

Un único agente no debería hacerlo todo por sí mismo. Los subagentes son Durable Objects secundarios coubicados con el Durable Object principal a través de Facets, cada uno con su propio SQLite aislado y su contexto de ejecución:

import { Agent } from "agents";

export class ResearchAgent extends Agent {
  async search(query: string) { /* ... */ }
}

export class ReviewAgent extends Agent {
  async analyze(query: string) { /* ... */ }
}

export class Orchestrator extends Agent {
  async handleTask(task: string) {
    const researcher = await this.subAgent(ResearchAgent, "research");
    const reviewer = await this.subAgent(ReviewAgent, "review");

    const [research, review] = await Promise.all([
      researcher.search(task),
      reviewer.analyze(task)
    ]);

    return this.synthesize(research, review);
  }
}

Los subagentes están aislados a nivel de almacenamiento. Cada uno tiene su propia base de datos SQLite, y no hay ningún intercambio implícito de datos entre ellos. Esto lo aplica el entorno de ejecución, donde la latencia de RPC del subagente es una llamada a función. TypeScript detecta el uso indebido en tiempo de compilación.

Los agentes que se ejecutan durante días o semanas necesitan algo más que la típica lista plana de mensajes. La API Session experimental modela esto explícitamente. Disponible en la clase base Agent, las conversaciones se almacenan como árboles, donde cada mensaje tiene un parent_id. Esto permite la bifurcación (es decir, explorar una alternativa sin perder la ruta original), la compactación no destructiva (esto es, resumir los mensajes más antiguos en lugar de suprimirlos) y la búsqueda de texto completo en el historial de conversaciones a través de FTS5.

import { Agent } from "agents";
import { Session, SessionManager } from "agents/experimental/memory/session";

export class MyAgent extends Agent {
  sessions = SessionManager.create(this);

  async onStart() {
    const session = this.sessions.create("main");
    const history = session.getHistory();
    const forked = this.sessions.fork(session.id, messageId, "alternative-approach");
  }
}

Session se puede utilizar directamente con Agent, y es la capa de almacenamiento sobre la que se basa la clase base Think.

El proceso convencional de la llamada a herramientas resulta engorroso. El modelo llama a una herramienta, extrae el resultado a través de la ventana de contexto, llama a otra herramienta, la vuelve a extraer, y así sucesivamente. A medida que crece la superficie de ataque, este proceso resulta caro y complicado. Cien archivos significan cien recorridos de ida y vuelta a través del modelo.

Pero los modelos son mejores escribiendo código para utilizar un sistema que invocando repetidamente herramientas. Esta es la idea en la que se basa @cloudflare/codemode: el LLM, en lugar de invocar secuencialmente las herramientas, escribe un único programa que se encarga de toda la tarea.

// The LLM writes this. It runs in a sandboxed Dynamic Worker.
const files = await tools.find({ pattern: "**/*.ts" });
const results = [];
for (const file of files) {
  const content = await tools.read({ path: file });
  if (content.includes("TODO")) {
    results.push({ file, todos: content.match(/\/\/ TODO:.*/g) });
  }
}
return results;

En lugar de 100 viajes de ida y vuelta al modelo, solo tienes que ejecutar un único programa. Esto reduce el uso de tokens, acelera la ejecución y mejora los resultados. El servidor MCP de la API de Cloudflare demuestra este proceso a gran escala. Solo exponemos dos herramientas (search() y execute()) que consumen unos 1000 tokens, frente a los aproximadamente 1,17 millones de tokens para el método equivalente no optimizado de una herramienta por cada punto final. Esto supone una reducción del 99,9 %.

Una vez aceptado que los modelos deben escribir código en nombre de los usuarios, la cuestión que se plantea es: ¿dónde se ejecuta ese código? Al final no, no después de que un equipo de producto lo integre como un elemento de su hoja de ruta. Ahora mismo, para este usuario, en este sistema, con permisos estrictamente definidos.

Dynamic Workers son ese sandbox. Un nuevo aislamiento de V8 se activa en tiempo de ejecución, en milisegundos, con unos pocos megabytes de memoria. Es aproximadamente 100 veces más rápido y hasta 100 veces más eficiente en términos de memoria que un contenedor. Puedes iniciar un aislamiento nuevo para cada solicitud, ejecutar un fragmento de código y desecharlo.

La elección de diseño fundamental es el modelo de capacidad. En lugar de empezar con una máquina de uso general e intentar restringirla, los Dynamic Workers empiezan casi sin autoridad de entorno (globalOutbound: null, sin acceso a la red) y el desarrollador otorga funciones explícitamente, recurso a recurso, mediante vinculaciones. Pasamos de preguntarnos "¿cómo evitamos que esto haga demasiado?" a "¿qué queremos que pueda hacer exactamente?"

Esta es la pregunta adecuada para la infraestructura de agentes.

Este modelo de capacidad genera naturalmente un espectro de entornos informáticos, una secuencia de ejecución por la que el agente avanza según sea necesario:

El nivel 0 es Workspace, un sistema de archivos virtual duradero respaldado por SQLite y R2. Lectura, escritura, edición, búsqueda, grep, diff. Basado en @cloudflare/shell.

El nivel 1 es un Dynamic Worker: JavaScript generado por un LLM que se ejecuta en un aislamiento en sandbox sin acceso a la red. Basado en @cloudflare/codemode.

El nivel 2 añade npm. @cloudflare/worker-bundler obtiene los paquetes del registro, los agrupa con esbuild y carga el resultado en el Dynamic Worker. El agente escribe import { z } from "zod" y simplemente funciona.

El nivel 3 es un navegador sin interfaz gráfica a través de Cloudflare Browser Run. Navegación, clic, extracción, captura de pantalla. Resulta útil cuando el servicio aún no admite agentes a través de MCP o las API.

El nivel 4 es un Cloudflare Sandbox configurado con tus cadenas de herramientas, repositorios y dependencias: git clone, npm test, cargo build, sincronizado bidireccionalmente con Workspace.

El principio clave del diseño: el agente debe ser útil solo en el nivel 0, sobre el que se añade cada uno de los otros niveles. El usuario puede añadir funciones sobre la marcha.

Todas estas primitivas están disponibles como paquetes independientes. Dynamic Workers, @cloudflare/codemode, @cloudflare/worker-bundler y @cloudflare/shell (un sistema de archivos duradero con herramientas) se pueden utilizar directamente con la clase base Agent. Puedes combinarlas para equipar a cualquier agente con un espacio de trabajo, la ejecución de código y la resolución de paquetes en tiempo de ejecución sin adoptar un marco prescriptivo.

Te presentamos la pila completa para el desarrollo de agentes en Cloudflare:

Funciones	¿Qué hace?	Basado en
Aislamiento por agente	Cada agente tiene un entorno propio	Durable Objects (DO)
Sin coste cuando está inactivo	0 USD hasta la activación del agente	Hibernación DO
Estado persistente	Almacenamiento transaccional consultable	SQLite DO
Sistema de archivos duradero	Archivos que se conservan después de un reinicio	Workspace (SQLite + R2)
Ejecución de código en un sandbox	Ejecución segura de código generado por un LLM	Dynamic Workers + @cloudflare/codemode
Dependencias del entorno de ejecución	import * from react simplemente funciona	@cloudflare/worker-bundler
Automatización web	Exploración, navegación, cumplimentación de formularios	Browser Run
Acceso total al sistema operativo	git, compiladores, ejecutores de pruebas	Sandboxes
Ejecución programada	Proactivo, no solo reactivo	Alarmas + Fibras DO
Transmisión en tiempo real	Token por token a cualquier cliente	WebSockets
Herramientas externas	Conexión a cualquier servidor de herramientas	MCP
Coordinación de agentes	RPC con tipo entre agentes	Subagentes (Facets)
Acceso a los modelos	Conexión a un LLM para mejorar el agente	AI Gateway + Workers AI (o trae tu propio modelo)

Cada una de estas primitivas es un elemento esencial. Juntas, forman algo nuevo: una plataforma en la que cualquier persona puede desarrollar, implementar y ejecutar agentes de IA tan capacitados como los que se ejecutan hoy en tu máquina local, pero sin servidor, duraderos y con seguridad integrada por diseño.

Ahora que has visto las primitivas, esto es lo que sucede cuando las conectas todas.

Think es una infraestructura preceptiva que gestiona todo el ciclo de vida del chat: el bucle agéntico, la persistencia de los mensajes, la transmisión, la ejecución de las herramientas, la reanudación de la transmisión y las extensiones. Tu prioridad es que lo que hace que tu agente sea exclusivo.

La subclase mínima tiene este aspecto:

import { Think } from "@cloudflare/think";
import { createWorkersAI } from "workers-ai-provider";

export class MyAgent extends Think<Env> {
  getModel() {
    return createWorkersAI({ binding: this.env.AI })(
      "@cf/moonshotai/kimi-k2.5"
    );
  }
}

Eso es todo lo que necesitas para tener un agente de chat operativo con funciones de transmisión, persistencia, interrupción/cancelación, gestión de errores, transmisiones reanudables y un sistema de archivos de espacio de trabajo integrado. Implementa con npx wrangler deploy.

Think toma las decisiones por ti. Cuando necesites tener un mayor control, puedes anular las que te interesen:

Invalidar	Propósito
getModel()	Devolver el LanguageModel a utilizar
getSystemPrompt()	Instrucción del sistema
getTools()	Conjunto de herramientas compatible con AI SDK para el bucle agéntico
maxSteps	Máximo de rondas de llamadas a herramientas por turno
configureSession()	Bloques de contexto, compactación, búsqueda, competencias

A nivel interno, Think ejecuta el bucle agéntico completo en cada turno: ensambla el contexto (instrucciones básicas + descripciones de las herramientas + competencias + memoria + historial de conversaciones), llama a streamText, ejecuta las llamadas a las herramientas (con truncamiento de salida para evitar el inflado del contexto), añade los resultados y repite este proceso hasta que se completa el modelo o hasta que se alcanza el límite de pasos. Todos los mensajes se conservan después de cada turno.

Think te ofrece enlaces en cada etapa del turno de chat, sin necesidad de que seas el propietario de todo el proceso:

beforeTurn()
  → streamText()
    → beforeToolCall()
    → afterToolCall()
  → onStepFinish()
→ onChatResponse()

Cambia a un modelo de menor coste para los turnos de seguimiento, limita las herramientas que puede utilizar y pasa el contexto del lado cliente en cada turno. Registra también la llamada a cada herramienta en los análisis y activa automáticamente un turno de seguimiento más después de que el modelo se haya completado, todo ello sin reemplazar onChatMessage.

Think se basa en la API Session como su capa de almacenamiento, lo que te ofrece mensajes con estructura de árbol con bifurcación integrada.

Además, añade memoria persistente a través de bloques de contexto. Se trata de secciones estructuradas de las instrucciones del sistema que el modelo puede leer y actualizar a lo largo del tiempo, y que persisten durante la hibernación. El modelo ve "MEMORY (Important facts, use set_context to update) [42%, 462/1100 tokens]" y puede recordar cosas de forma proactiva.

configureSession(session: Session) {
  return session
    .withContext("soul", {
      provider: { get: async () => "You are a helpful coding assistant." }
    })
    .withContext("memory", {
      description: "Important facts learned during conversation.",
      maxTokens: 2000
    })
    .withCachedPrompt();
}

Las sesiones son flexibles. Puedes ejecutar varias conversaciones por agente y bifurcarlas para intentar tomar una dirección distinta sin perder el original. 

A medida que crece el contexto, Think maneja los límites con una compactación no destructiva. Los mensajes más antiguos se resumen en lugar de suprimirse, mientras que el historial completo permanece almacenado en SQLite. 

La búsqueda también está integrada. Con FTS5, puedes consultar el historial de conversaciones dentro de una sesión o en todas las sesiones. El agente también puede buscar en su propio pasado utilizando la herramienta search_context.

Think integra toda la secuencia de ejecución en un único retorno de getTools().

import { Think } from "@cloudflare/think";
import { createWorkspaceTools } from "@cloudflare/think/tools/workspace";
import { createExecuteTool } from "@cloudflare/think/tools/execute";
import { createBrowserTools } from "@cloudflare/think/tools/browser";
import { createSandboxTools } from "@cloudflare/think/tools/sandbox";
import { createExtensionTools } from "@cloudflare/think/tools/extensions";

export class MyAgent extends Think<Env> {
  extensionLoader = this.env.LOADER;

  getModel() {
    /* ... */
  }

  getTools() {
    return {
      execute: createExecuteTool({
        tools: createWorkspaceTools(this.workspace),
        loader: this.env.LOADER
      }),
      ...createBrowserTools(this.env.BROWSER),
      ...createSandboxTools(this.env.SANDBOX), // configured per-agent: toolchains, repos, snapshots
      ...createExtensionTools({ manager: this.extensionManager! }),
      ...this.extensionManager!.getTools()
    };
  }
}

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 el acceso a la red y las operaciones en el espacio de trabajo.

{
  "name": "github",
  "description": "GitHub integration: PRs, issues, repos",
  "tools": ["create_pr", "list_issues", "review_pr"],
  "permissions": {
    "network": ["api.github.com"],
    "workspace": "read-write"
  }
}

ExtensionManager de Think agrupa la extensión (opcionalmente con npm deps a través de @cloudflare/worker-bundler), la carga en un Dynamic Worker y registra las nuevas herramientas. La extensión persiste en el almacenamiento DO y se conserva después de la hibernación. La próxima vez que el usuario pregunte por las solicitudes de extracción, el agente tendrá una herramienta github_create_pr que no existía 30 segundos antes.

Este es el tipo de bucle de automejora que hace que los agentes realmente mejoren su utilidad con el tiempo. No mediante ajustes o RLHF, sino gracias al código. El agente puede escribir nuevas funciones por sí mismo, todo en TypeScript en sandbox, auditable y revocable.

Think también funciona como un subagente, al que se invoca a través de chat() sobre RPC desde un agente principal, con eventos de transmisión mediante la devolución de llamada:

const researcher = await this.subAgent(ResearchSession, "research");
const result = await researcher.chat(`Research this: ${task}`, streamRelay);

Cada subagente tiene su propio árbol de conversación, su memoria, sus herramientas y su modelo. El agente principal no necesita conocer los detalles.

Project Think es experimental. La superficie de la API es estable, pero seguirá evolucionando en los próximos días y semanas. Ya lo utilizamos internamente para desarrollar nuestra propia infraestructura de agentes en segundo plano, y te proporcionamos un adelanto para que puedas desarrollar con nosotros.

npm install @cloudflare/think agents ai @cloudflare/shell zod workers-ai-provider

// src/server.ts
import { Think } from "@cloudflare/think";
import { createWorkersAI } from "workers-ai-provider";
import { routeAgentRequest } from "agents";

export class MyAgent extends Think<Env> {
  getModel() {
    return createWorkersAI({ binding: this.env.AI })(
      "@cf/moonshotai/kimi-k2.5"
    );
  }
}

export default {
  async fetch(request: Request, env: Env) {
    return (
      (await routeAgentRequest(request, env)) ||
      new Response("Not found", { status: 404 })
    );
  }
} satisfies ExportedHandler<Env>;

// src/client.tsx
import { useAgent } from "agents/react";
import { useAgentChat } from "@cloudflare/ai-chat/react";

function Chat() {
  const agent = useAgent({ agent: "MyAgent" });
  const { messages, sendMessage, status } = useAgentChat({ agent });
  // Render your chat UI
}

Think utiliza el mismo protocolo WebSocket que @cloudflare/ai-chat, por lo que los componentes de la interfaz de usuario existentes no requieren configuración. Si has desarrollado en AIChatAgent, tu código de cliente no cambia.

Vemos tres olas de agentes de IA:

La primera ola fueron los bots de chat. No tenían estado y eran reactivos y frágiles. Cada conversación empezaba desde cero, sin memoria, sin herramientas y sin capacidad de acción. Por ello, resultaban útiles para responder preguntas, pero se veían limitados a esta tarea.

La segunda ola fueron los agentes de programación. Se trata de herramientas con estado, que utilizan herramientas, y ofrecen funciones mucho más potentes, como Pi, Claude Code, OpenClaw y Codex. Estos agentes pueden leer bases de código, escribir y ejecutar código y realizar iteraciones. Demostraron que un LLM con las herramientas adecuadas es una máquina de uso general, pero se ejecutan en tu portátil, para un usuario, sin garantía de durabilidad.

Ahora estamos entrando en la tercera ola: los agentes como infraestructura. Duraderos, distribuidos, estructuralmente seguros y sin servidor. Se trata de agentes que se ejecutan en Internet, se mantienen después de un fallo, que no tienen ningún coste cuando están inactivos y que aplican la seguridad a través de la arquitectura, no mediante el comportamiento. Son agentes que cualquier desarrollador puede crear e implementar para cualquier número de usuarios.

Esta es la dirección por la que apostamos.

El SDK de agentes ya funciona en miles de agentes de producción. Con Project Think y las primitivas que incorpora, añadimos las funciones que faltaban para que esos agentes estén mucho mejor capacitados: espacios de trabajo persistentes, ejecución de código en un sandbox, tareas duraderas de larga ejecución, seguridad estructural, coordinación de subagentes y extensiones de autoría propia.

Ya está disponible en versión preliminar. Estamos desarrollando al mismo tiempo que tú, y nos encantaría ver lo que tú (y tu agente de programación) creáis con él.

---

^{Think forma parte del SDK de agentes de Cloudflare, disponible como @cloudflare/think. Las funciones descritas en esta publicación están en versión preliminar. Las API pueden cambiar a medida que incorporemos sugerencias. Consulta la documentación y el ejemplo para empezar.}