Project Think: construindo a próxima geração de agentes de IA na Cloudflare

• A Cloudflare anunciou o Project Think, a próxima geração do Agents SDK, oferecendo novos primitivos essenciais para agentes de longa duração, como execução durável, subagentes, execução de código em sandbox e sessões persistentes
• Os agentes de codificação existentes tinham limitações: rodavam apenas em notebooks locais, geravam custo mesmo quando estavam ociosos e exigiam configuração e gerenciamento manuais
• Diferentemente de aplicações tradicionais, os agentes operam em um modelo 1:1 (uma instância por usuário e por tarefa), então dar suporte a dezenas de milhões de sessões simultâneas é inviável com uma estrutura de custos baseada em contêineres
• Usando o modelo de atores baseado em Durable Objects, os agentes têm custo de computação zero quando estão em repouso e despertam automaticamente ao receber mensagens, garantindo economia para escalar em grande escala
• Como a terceira onda dos agentes de IA, a proposta é agentes como infraestrutura (durabilidade, distribuição, serverless e segurança estrutural), com a meta de oferecer uma plataforma onde qualquer desenvolvedor possa criar e implantar agentes para bilhões de usuários

---

Visão geral do Project Think

• Próxima geração do Agents SDK da Cloudflare, com um novo conjunto de primitivos para construir agentes de longa duração e uma classe base que os integra
• Principais primitivos: execução durável (fibers), subagentes, sessões persistentes, execução de código em sandbox, escada de execução e extensões autoescritas
• Os primitivos podem ser usados individualmente ou é possível começar rapidamente com a classe base Think

Limites atuais dos agentes de codificação

• Ferramentas como Pi, OpenClaw, Claude Code e Codex provaram que, ao dar a um LLM a capacidade de ler arquivos, escrever código, executá-lo e aprender, ele pode funcionar como um assistente de uso geral
• Esses agentes de codificação podem ser usados não só para código, mas também para gerenciar calendários, analisar datasets, negociar compras, declarar impostos e automatizar fluxos de trabalho de negócios
• O padrão é sempre o mesmo: o agente lê o contexto, raciocina, escreve código para agir, observa o resultado e repete → código é o meio universal da ação
• Limites atuais:
  • Rodam apenas em notebooks ou VPSs caros: não permitem compartilhamento, colaboração nem troca entre dispositivos
  • Geram custo mesmo quando ociosos: o custo mensal fixo cresce rapidamente quando se expande para times ou empresas
  • Exigem instalação e administração manuais: instalar dependências, gerenciar atualizações, configurar autenticação e segredos

O problema estrutural dos agentes: modelo 1:1

• Aplicações tradicionais usam uma única instância para atender muitos usuários, mas agentes são 1:1 — cada agente é uma instância própria para um usuário e uma tarefa
• Se 100 milhões de trabalhadores do conhecimento usarem cada um um assistente agente, serão necessárias dezenas de milhões de sessões simultâneas
• Com a atual estrutura de custos por contêiner, isso é inviável; é preciso outra base

Agentes de longa duração

• Os agentes atuais são efêmeros (ephemeral): desaparecem quando a sessão termina e param quando o notebook entra em suspensão
• O Agents SDK, com base em Durable Objects, dá a cada agente identidade, estado persistente e inicialização automática ao receber mensagens
• Modelo de ator: cada agente é uma entidade endereçável com seu próprio banco de dados SQLite, e custa zero em computação quando está em repouso
• Quando ocorre um evento como requisição HTTP, mensagem WebSocket, alarme agendado ou e-mail de entrada, a plataforma desperta o agente e carrega seu estado
• Comparação entre Durable Objects e VMs/contêineres:
  • Custo em idle: VM tem custo total de computação o tempo todo vs DO é zero (em repouso)
  • Escalabilidade: VM exige provisionamento manual vs DO faz escala automática por agente
  • Estado: VM precisa de banco externo vs DO tem SQLite embutido
  • Recuperação: em VM é preciso construir isso manualmente vs DO tem reinício automático da plataforma com preservação de estado
  • Roteamento: em VM é preciso construir balanceador e sticky sessions vs DO tem mapeamento nome→agente embutido
  • 10.000 agentes (1% ativos cada): VM exige 10.000 instâncias sempre ligadas vs DO mantém cerca de 100 ativos
• O custo marginal de criar um novo agente é praticamente zero → viabiliza o modelo de agentes “um por usuário”, “um por tarefa” e “um por thread de e-mail”

Execução durável: Fibers

• Chamadas de LLM podem durar 30 segundos, e loops de agentes multiturno podem durar ainda mais; nesse intervalo, o ambiente de execução pode desaparecer (deploy, reinício da plataforma, limite de recursos)
• runFiber(): uma invocação de função durável registrada no SQLite antes do início da execução; com stash() é possível criar checkpoints, e com onFiberRecovered recuperar após reinício
• O SDK mantém automaticamente o agente ativo durante a execução de uma fiber, sem necessidade de configuração especial
• Para tarefas de duração em minutos, keepAlive() / keepAliveWhile() evitam despejo
• Para tarefas mais longas, como pipelines de CI, revisão de design e geração de vídeo, o agente salva o job ID e entra em repouso após iniciar o trabalho, sendo reativado no callback

Subagentes: Facets

• Um único agente não precisa fazer todo o trabalho
• Subagentes são Durable Objects filhos coimplantados com o pai, cada um com SQLite isolado e contexto de execução próprio
• Com base em Facets, eles ficam posicionados junto do agente pai, sem compartilhamento implícito de dados entre subagentes
• A latência de RPC entre subagentes é do nível de chamada de função, e o TypeScript detecta usos incorretos em tempo de compilação

Sessões persistentes: Session API

• Agentes que rodam por dias ou semanas precisam de algo além de uma lista plana de mensagens
• A Session API experimental modela a conversa como uma árvore, atribuindo parent_id a cada mensagem
  • Forking: explorar alternativas sem perder o caminho original
  • Compressão não destrutiva: em vez de apagar mensagens antigas, elas são resumidas
  • Busca textual completa: pesquisa full-text em todo o histórico da conversa com base em FTS5
• Pode ser usada diretamente na classe base Agent e funciona como camada de armazenamento da classe base Think

De chamadas de ferramenta para execução de código

• No modelo tradicional de tool calling, o modelo faz uma chamada de ferramenta → recupera o resultado para a janela de contexto → repete; conforme cresce o número de ferramentas, aumentam custo e ineficiência
• 100 arquivos = 100 idas e voltas com o modelo
• O modelo é melhor em escrever código para usar sistemas do que em jogar o jogo de chamadas de ferramenta — esse é o insight central do @cloudflare/codemode
• Em vez de chamadas sequenciais de ferramentas, o LLM escreve um único programa que resolve toda a tarefa
• No caso do servidor MCP da API da Cloudflare, expor apenas duas ferramentas (search(), execute()) consumiu cerca de 1.000 tokens, contra cerca de 1,17 milhão de tokens no modelo de uma ferramenta por endpoint → redução de 99,9%

Sandbox segura: Dynamic Workers

• Se o modelo escreve código em nome do usuário, a grande questão passa a ser o ambiente onde esse código será executado
• Dynamic Workers: um novo ambiente isolado V8 criado em tempo de execução na escala de milissegundos, com alguns megabytes de memória
  • Em comparação com contêineres, é cerca de 100 vezes mais rápido e até 100 vezes mais eficiente em memória
  • Pode ser criado a cada requisição e descartado após a execução do código
• Princípio central do design: modelo de capabilities — em vez de restringir uma máquina de uso geral, ele começa quase sem permissões (globalOutbound: null, sem acesso à rede) e o desenvolvedor concede permissões explícitas por recurso via bindings
• A pergunta muda de “como impedir que isso faça demais?” para “o que exatamente isso poderá fazer?”

Escada de execução (Execution Ladder)

• Um espectro em que o agente escala gradualmente para ambientes computacionais mais avançados conforme a necessidade:
  • Tier 0 — Workspace: sistema de arquivos virtual durável baseado em SQLite + R2, com suporte a leitura, escrita, edição, busca, grep e diff, executando @cloudflare/shell
  • Tier 1 — Dynamic Worker: executa JavaScript gerado por LLM em um ambiente isolado em sandbox sem acesso à rede, usando @cloudflare/codemode
  • Tier 2 — adicionar npm: @cloudflare/worker-bundler busca pacotes no registro, faz bundle com esbuild e os carrega no Dynamic Worker, permitindo usar import { z } from "zod" diretamente
  • Tier 3 — navegador headless: Cloudflare Browser Run para navegação, cliques, extração e screenshots, útil para serviços sem suporte a MCP ou API
  • Tier 4 — Cloudflare Sandbox: executa git clone, npm test, cargo build etc. em um ambiente com toolchain, repositório e dependências configurados, com sincronização bidirecional com o Workspace
• Princípio central do design: o agente precisa ser útil só com o Tier 0; cada tier adicional é complementar

Blocos de construção, não um framework

• Todos os primitivos são fornecidos como pacotes independentes: Dynamic Workers, @cloudflare/codemode, @cloudflare/worker-bundler, @cloudflare/shell
• É possível combiná-los diretamente com a classe base Agent para usar workspace, execução de código e resolução de pacotes em runtime sem adotar um framework proprietário

A stack completa da plataforma

• Isolamento por agente: Durable Objects — cada agente tem seu próprio mundo
• Custo zero em idle: DO Hibernation — $0 até o agente acordar
• Estado persistente: DO SQLite — armazenamento com consultas e transações
• Sistema de arquivos durável: Workspace (SQLite + R2)
• Execução de código em sandbox: Dynamic Workers + @cloudflare/codemode
• Dependências em runtime: @cloudflare/worker-bundler — import * from react funciona como está
• Automação web: Browser Run
• Acesso total ao SO: Sandboxes — git, compiladores, test runners
• Execução agendada: DO Alarms + Fibers
• Streaming em tempo real: WebSockets
• Conexão com ferramentas externas: MCP
• Coordenação entre agentes: subagentes (Facets) — RPC tipado
• Acesso a modelos: AI Gateway + Workers AI (ou modelos próprios)

Classe base Think

• Um harness integrado que cobre todo o ciclo de vida do chat, incluindo loop do agente, persistência de mensagens, streaming, execução de ferramentas, retomada de stream e extensões
• Subclasse mínima: basta implementar o método getModel() para ter um agente de chat com streaming, persistência, interrupção/cancelamento, tratamento de erros, streams retomáveis e sistema de arquivos de workspace embutido
• Implantação com npx wrangler deploy
• Itens que podem ser sobrescritos: getModel(), getSystemPrompt(), getTools(), maxSteps, configureSession()
• A cada turno, executa todo o loop agêntico: monta o contexto (comandos base + descrição de ferramentas + skills + memória + histórico da conversa) → chama streamText → executa chamadas de ferramenta (com truncamento de saída para evitar explosão de contexto) → adiciona os resultados → repete até o modelo concluir ou atingir o limite de passos

Hooks de ciclo de vida

• O Think oferece hooks em todas as etapas do turno de chat sem precisar controlar todo o pipeline:
  • beforeTurn() → streamText() → beforeToolCall() → afterToolCall() → onStepFinish() → onChatResponse()
• Assim, é possível trocar para um modelo mais barato em turnos seguintes, limitar ferramentas, passar contexto do cliente, registrar logs analíticos de todas as chamadas de ferramenta e disparar turnos automáticos sem substituir onChatMessage

Memória persistente e conversas longas

• O Think é construído sobre a Session API, com mensagens em estrutura de árvore e branching embutido
• Memória persistente via blocos de contexto: seções estruturadas do prompt de sistema que o modelo pode ler e atualizar ao longo do tempo, permanecendo entre períodos de repouso
• O modelo pode ver algo como "MEMORY (Important facts, use set_context to update) [42%, 462/1100 tokens]" e lembrar ativamente
• É possível manter múltiplas conversas por agente, e o forking permite explorar direções diferentes sem perder a conversa original
• Quando o contexto cresce, há compressão não destrutiva: mensagens antigas são resumidas em vez de apagadas, e o histórico completo permanece no SQLite
• Busca baseada em FTS5: dá para consultar o histórico dentro de uma sessão ou em todas as sessões; o próprio agente pode pesquisar seu passado com a ferramenta search_context

Integração da escada de execução completa

• O Think integra toda a escada de execução por meio de um único retorno de getTools(): ferramentas de workspace, execução, navegador, sandbox e extensões podem ser configuradas de uma vez

Extensões autoescritas (Self-authored Extensions)

• O agente pode escrever seus próprios plugins: programas TypeScript executados em Dynamic Workers, declarando acesso à rede e permissões de trabalho no workspace
• O ExtensionManager do Think faz o bundle da extensão (incluindo dependências npm), carrega no Dynamic Worker e registra novas ferramentas
• As extensões ficam persistidas no armazenamento do DO, sobrevivendo mesmo em repouso
• Exemplo: quando o usuário pergunta sobre um PR, pode surgir a ferramenta github_create_pr, que não existia 30 segundos antes
• Não é fine-tuning nem RLHF, mas sim um loop de autoaperfeiçoamento via código — TypeScript em sandbox, auditável e revogável

RPC entre subagentes

• O Think também funciona como subagente chamado pelo pai via chat() over RPC, com suporte a eventos de streaming por callback
• Cada filho tem sua própria árvore de conversa, memória, ferramentas e modelo, sem que o pai precise conhecer os detalhes

Como começar

• O Project Think está em estado experimental, com a superfície de API estável, mas ainda em evolução
• Já está sendo usado internamente na Cloudflare para construir sua própria infraestrutura de agentes em background
• O Think usa o mesmo protocolo WebSocket de @cloudflare/ai-chat, então os componentes de UI existentes continuam funcionando
• Se você construiu com base em AIChatAgent, não é necessário mudar o código do cliente

As três ondas dos agentes de IA

• Primeira onda — chatbots: sem estado, reativos, frágeis, recomeçam do zero a cada conversa, sem memória, ferramentas ou capacidade de agir, úteis apenas para responder perguntas
• Segunda onda — agentes de codificação: mantêm estado, usam ferramentas; soluções como Pi, Claude Code, OpenClaw e Codex conseguem ler codebases, escrever código, executá-lo e iterar, provando que um LLM com as ferramentas certas é uma máquina de uso geral; porém, ainda rodam só em notebooks para um usuário e não têm garantias de durabilidade
• Terceira onda — agentes como infraestrutura: duráveis, distribuídos, estruturalmente seguros, serverless, executados na internet, resistentes a falhas, com custo zero em idle e segurança imposta pela arquitetura, não apenas pelo comportamento