Project Think : construire la prochaine génération d’agents IA avec Cloudflare

• Cloudflare a annoncé Project Think, la prochaine version de l’Agents SDK, qui apporte de nouveaux primitives clés pour les agents de longue durée d’exécution : exécution durable, sous-agents, exécution de code en sandbox et sessions persistantes
• Les agents de code existants avaient des limites : ils ne s’exécutaient que sur un laptop local, généraient des coûts même à l’arrêt, et nécessitaient une configuration et une gestion manuelles
• Contrairement aux applications classiques, les agents fonctionnent selon un modèle 1:1 (une instance par utilisateur et par tâche) ; prendre en charge des dizaines de millions de sessions simultanées n’est donc pas viable avec une structure de coûts basée sur des conteneurs
• En s’appuyant sur le modèle d’acteurs des Durable Objects, Cloudflare obtient une économie d’échelle où le coût de calcul tombe à zéro quand l’agent est en veille, avec réveil automatique à la réception d’un message
• Comme troisième vague des agents IA, le projet vise des agents en tant qu’infrastructure (durabilité, distribution, serverless, sécurité structurelle) et une plateforme permettant à tous les développeurs de concevoir et déployer des agents pour des milliards d’utilisateurs

---

Vue d’ensemble de Project Think

• Nouvelle version de l’Agents SDK de Cloudflare, avec un nouvel ensemble de primitives pour créer des agents de longue durée et une classe de base qui les unifie
• Principales primitives : exécution durable (fibers), sous-agents, sessions persistantes, exécution de code en sandbox, échelle d’exécution, extensions auto-rédigées
• Ces primitives peuvent être utilisées séparément ou via la classe de base Think pour démarrer rapidement

Limites actuelles des agents de code

• Des outils comme Pi, OpenClaw, Claude Code et Codex ont montré que donner à un LLM la capacité de lire des fichiers, d’écrire du code, de l’exécuter et d’apprendre lui permet d’agir comme un assistant généraliste
• Ces agents de code servent non seulement au développement, mais aussi à la gestion de calendrier, l’analyse de datasets, la négociation d’achats, la déclaration fiscale ou l’automatisation de workflows métier
• Le schéma est toujours le même : l’agent lit le contexte, raisonne, écrit du code pour agir, observe le résultat et recommence → le code devient le médium universel de l’action
• Limites actuelles :
  • Exécution uniquement sur laptop ou VPS coûteux : pas de partage, de collaboration ni de continuité entre appareils
  • Coûts même à l’inactivité : les coûts mensuels fixes explosent à l’échelle d’une équipe ou d’une entreprise
  • Installation et gestion manuelles requises : installation des dépendances, gestion des mises à jour, configuration de l’authentification et des secrets

Problème structurel des agents : le modèle 1:1

• Les applications traditionnelles traitent de nombreux utilisateurs avec une seule instance, mais les agents sont en 1:1 — chaque agent exécute une tâche pour un utilisateur dans sa propre instance
• Si 100 millions de travailleurs du savoir utilisent chacun un agent assistant, il faut des dizaines de millions de sessions simultanées
• La structure de coûts par conteneur actuelle n’est pas soutenable ; il faut une autre base

Agents de longue durée

• Les agents actuels sont éphémères : ils disparaissent à la fin de la session et s’interrompent quand le laptop se met en veille
• L’Agents SDK, basé sur les Durable Objects, donne à chaque agent une identité, un état persistant et la capacité de démarrer automatiquement à la réception d’un message
• Modèle d’acteurs : chaque agent est une entité adressable disposant de sa propre base SQLite ; quand il dort, le coût de calcul tombe à zéro
• Lorsqu’un événement survient — requête HTTP, message WebSocket, alarme planifiée, e-mail entrant — la plateforme réveille l’agent et recharge son état
• Comparaison Durable Objects vs VM/conteneurs :
  • Coût à l’inactivité : une VM paie toujours le coût complet de calcul, contre zéro (veille) pour un DO
  • Scalabilité : provisionnement manuel pour les VM, contre scalabilité automatique par agent pour les DO
  • État : une VM nécessite une base externe, contre SQLite intégré pour les DO
  • Reprise : à construire soi-même pour les VM, contre redémarrage automatique et conservation de l’état côté plateforme pour les DO
  • Routage : avec les VM, il faut construire load balancer et sticky sessions ; avec les DO, le mapping nom → agent est intégré
  • 10 000 agents (avec 1 % d’activité chacun) : une VM exige 10 000 instances permanentes, contre environ 100 actives pour les DO
• Le coût marginal de création d’un nouvel agent devient pratiquement nul → modèles d’agents « un par utilisateur », « un par tâche » ou « un par fil d’e-mail »

Exécution durable : Fibers

• Un appel LLM peut durer 30 secondes et une boucle d’agent multi-tours encore plus ; pendant ce temps, l’environnement d’exécution peut disparaître (déploiement, redémarrage plateforme, limites de ressources)
• runFiber() : appel de fonction durable enregistré dans SQLite avant le début de l’exécution ; stash() crée des checkpoints et onFiberRecovered permet la reprise après redémarrage
• Le SDK maintient automatiquement l’agent en vie pendant l’exécution d’un fiber, sans configuration particulière
• Pour des tâches de plusieurs minutes, keepAlive() / keepAliveWhile() évitent l’éviction
• Pour des travaux plus longs comme des pipelines CI, des revues de design ou la génération vidéo, l’agent enregistre un job ID puis se met en veille, avant de redémarrer au callback

Sous-agents : Facets

• Un agent unique n’a pas besoin de tout faire lui-même
• Les sous-agents sont des Durable Objects enfants co-localisés avec le parent, chacun avec son propre SQLite isolé et son contexte d’exécution
• Basés sur Facets, ils résident avec l’agent parent et n’impliquent aucun partage implicite de données entre sous-agents
• La latence RPC vers un sous-agent est du niveau d’un appel de fonction, et TypeScript détecte les usages incorrects à la compilation

Sessions persistantes : Session API

• Pour des agents qui s’exécutent sur plusieurs jours ou semaines, une simple liste plate de messages ne suffit pas
• La Session API expérimentale modélise la conversation sous forme d’arbre, avec un parent_id pour chaque message
  • Forking : exploration d’alternatives sans perdre le chemin d’origine
  • Compression non destructive : les anciens messages sont résumés au lieu d’être supprimés
  • Recherche plein texte : recherche dans tout l’historique conversationnel via FTS5
• Utilisable directement depuis la classe de base Agent, elle sert aussi de couche de stockage à la classe de base Think

Des appels d’outils à l’exécution de code

• Modèle classique d’appel d’outils : le modèle appelle un outil → récupère le résultat dans la fenêtre de contexte → recommence ; plus il y a d’outils, plus le coût et l’inefficacité augmentent
• 100 fichiers = 100 allers-retours avec le modèle
• Les modèles sont meilleurs pour écrire du code afin d’utiliser un système que pour jouer au jeu des appels d’outils — c’est l’intuition centrale de @cloudflare/codemode
• Au lieu d’appels d’outils séquentiels, le LLM écrit un seul programme qui gère toute la tâche
• Exemple du serveur MCP de l’API Cloudflare : seulement 2 outils exposés (search(), execute()) pour environ 1 000 tokens consommés, contre environ 1,17 million de tokens avec un outil par endpoint → 99,9 % de réduction

Sandbox sécurisée : Dynamic Workers

• Si le modèle écrit du code au nom de l’utilisateur, la question clé devient l’environnement dans lequel ce code s’exécute
• Dynamic Workers : nouvel environnement isolé V8 créé à l’exécution en quelques millisecondes, avec quelques mégaoctets de mémoire
  • Environ 100 fois plus rapide qu’un conteneur et jusqu’à 100 fois plus efficace en mémoire
  • Peut être créé à chaque requête, exécuter le code, puis être détruit
• Principe de conception central : le modèle de capabilities — au lieu de restreindre une machine généraliste, on part d’un état quasi sans privilèges (globalOutbound: null, pas d’accès réseau) puis le développeur accorde des permissions explicites ressource par ressource via des bindings
• On passe de « comment empêcher cela d’en faire trop ? » à « qu’allons-nous lui permettre de faire exactement ? »

Échelle d’exécution (Execution Ladder)

• Les agents peuvent monter progressivement vers des environnements de calcul plus puissants selon leurs besoins :
  • Tier 0 — Workspace : système de fichiers virtuel persistant basé sur SQLite + R2, avec lecture, écriture, édition, recherche, grep, diff et exécution de @cloudflare/shell
  • Tier 1 — Dynamic Worker : exécution de JavaScript généré par LLM dans un environnement isolé sandboxé sans accès réseau ; exécute @cloudflare/codemode
  • Tier 2 — ajout de npm : @cloudflare/worker-bundler récupère les packages du registre, les bundle avec esbuild et les charge dans un Dynamic Worker ; import { z } from "zod" fonctionne tel quel
  • Tier 3 — navigateur headless : Cloudflare Browser Run pour naviguer, cliquer, extraire, prendre des captures d’écran ; utile pour les services sans MCP ni API
  • Tier 4 — Cloudflare Sandbox : exécution de git clone, npm test, cargo build, etc., dans un environnement avec toolchain, repo et dépendances configurés, avec synchronisation bidirectionnelle avec Workspace
• Principe clé : Tier 0 seul doit déjà rendre l’agent utile, chaque tier supplémentaire étant optionnel

Des briques de base, pas un framework

• Toutes les primitives sont fournies comme packages indépendants : Dynamic Workers, @cloudflare/codemode, @cloudflare/worker-bundler, @cloudflare/shell
• En les combinant directement avec la classe de base Agent, il est possible d’utiliser workspace, exécution de code et résolution de packages à l’exécution sans adopter de framework propriétaire

L’ensemble de la stack plateforme

• Isolation par agent : Durable Objects — chaque agent possède son propre univers
• Coût nul à l’inactivité : DO Hibernation — $0 tant que l’agent ne se réveille pas
• État persistant : DO SQLite — stockage interrogeable et transactionnel
• Système de fichiers persistant : Workspace (SQLite + R2)
• Exécution de code sandboxée : Dynamic Workers + @cloudflare/codemode
• Dépendances runtime : @cloudflare/worker-bundler — import * from react fonctionne tel quel
• Automatisation web : Browser Run
• Accès OS complet : Sandboxes — git, compilateurs, test runners
• Exécution planifiée : DO Alarms + Fibers
• Streaming temps réel : WebSockets
• Connexion aux outils externes : MCP
• Coordination entre agents : sous-agents (Facets) — RPC typé
• Accès aux modèles : AI Gateway + Workers AI (ou modèles propriétaires)

Classe de base Think

• Harnais unifié qui gère tout le cycle de vie du chat : boucle d’agent, persistance des messages, streaming, exécution d’outils, reprise de flux, extensions, etc.
• Sous-classe minimale : il suffit d’implémenter getModel() pour obtenir un agent conversationnel avec streaming, persistance, interruption/annulation, flux reprenables et système de fichiers Workspace intégré
• Déploiement via npx wrangler deploy
• Éléments surchargeables : getModel(), getSystemPrompt(), getTools(), maxSteps, configureSession()
• À chaque tour, exécute la boucle agentique complète : assemblage du contexte (instructions de base + description des outils + skills + mémoire + historique conversationnel) → appel à streamText → exécution des appels d’outils (avec découpe de sortie pour éviter l’explosion de contexte) → ajout des résultats → répétition jusqu’à la fin du modèle ou la limite d’étapes

Hooks de cycle de vie

• Sans posséder tout le pipeline, Think fournit des hooks à chaque étape d’un tour de chat :
  • beforeTurn() → streamText() → beforeToolCall() → afterToolCall() → onStepFinish() → onChatResponse()
• Changement vers un modèle moins coûteux au tour suivant, restriction des outils, transmission du contexte client, journalisation analytique de tous les appels d’outils, déclenchement automatique d’un tour de suivi, etc. : tout cela est possible sans remplacer onChatMessage

Mémoire persistante et longues conversations

• Think est construit sur la Session API, avec messages arborescents et branching intégrés
• Mémoire persistante via des context blocks : sections structurées du prompt système que le modèle peut lire et mettre à jour dans le temps, y compris pendant les périodes de veille
• Le modèle peut voir quelque chose comme "MEMORY (Important facts, use set_context to update) [42%, 462/1100 tokens]" et mémoriser activement
• Plusieurs conversations peuvent s’exécuter par agent, et le forking permet d’explorer d’autres directions sans perdre la conversation d’origine
• Quand le contexte grossit, compression non destructive : les anciens messages sont résumés au lieu d’être supprimés, tout l’historique restant conservé dans SQLite
• Recherche basée sur FTS5 : interrogation de l’historique dans une session ou sur l’ensemble des sessions ; l’agent peut aussi fouiller son propre passé via l’outil search_context

Intégration de l’échelle d’exécution complète

• Think unifie toute l’Execution Ladder via un simple retour de getTools() : outils Workspace, d’exécution, de navigateur, de sandbox et d’extension peuvent être configurés d’un seul coup

Extensions auto-rédigées (Self-authored Extensions)

• L’agent peut écrire lui-même ses propres extensions : programmes TypeScript exécutés dans Dynamic Workers et déclarant des permissions d’accès réseau et d’opérations sur le Workspace
• L’ExtensionManager de Think bundle l’extension (y compris avec des dépendances npm), la charge dans un Dynamic Worker et enregistre de nouveaux outils
• Les extensions sont persistées dans le stockage DO et survivent donc à l’hibernation
• Exemple : lorsqu’un utilisateur pose une question sur une PR, un outil github_create_pr qui n’existait pas 30 secondes plus tôt peut être créé
• Il ne s’agit pas de fine-tuning ni de RLHF, mais d’une boucle d’auto-amélioration par le code — du TypeScript sandboxé, auditable et révocable

RPC de sous-agents

• Think peut aussi fonctionner comme sous-agent appelé depuis le parent via chat() over RPC, avec prise en charge d’événements de streaming par callback
• Chaque enfant possède son propre arbre de conversation, sa mémoire, ses outils et son modèle ; le parent n’a pas besoin d’en connaître les détails

Pour commencer

• Project Think est expérimental, avec une surface d’API déjà stable mais appelée à continuer d’évoluer
• Il est déjà utilisé en interne chez Cloudflare pour construire leur propre infrastructure d’agents en arrière-plan
• Think utilise le même protocole WebSocket que @cloudflare/ai-chat, donc les composants UI existants fonctionnent tels quels
• Si vous avez construit sur AIChatAgent, aucun changement de code côté client n’est nécessaire

Les trois vagues des agents IA

• Première vague — chatbots : sans état, réactifs, fragiles, redémarrant à zéro à chaque conversation, sans mémoire, outils ni capacité d’action ; utiles seulement pour répondre aux questions
• Deuxième vague — agents de code : conservent un état, utilisent des outils ; des outils comme Pi, Claude Code, OpenClaw et Codex peuvent lire une codebase, écrire du code, l’exécuter et itérer, prouvant qu’un LLM équipé des bons outils est une machine généraliste ; mais ils ne s’exécutent que sur laptop pour un seul utilisateur à la fois, sans garantie de durabilité
• Troisième vague — agents en tant qu’infrastructure : durables, distribués, structurellement sûrs, serverless, exécutés sur Internet, résistants aux pannes, coût nul à l’inactivité, avec une sécurité imposée par l’architecture plutôt que par l’action