Noqta
écrits/blog/2026/07
● Blog10 juil. 2026·6 min

Project Think : le runtime Cloudflare d'agents IA durables

Project Think fait des agents IA une infrastructure durable : des fibres qui survivent aux crashs, des agents gratuits au repos, du code exécuté isolé.

Équipe Noqta
·EN · FR · AR
Visualisation abstraite d'un runtime d'agents durables avec des chemins d'exécution jalonnés de points de reprise

La plupart des agents IA en production aujourd'hui vivent sur du temps emprunté. Ils tournent dans un processus de longue durée — un conteneur, une VM, un worker Python — et ce processus est facturé à la seconde, que l'agent réfléchisse ou qu'il attende. Pire : quand le processus meurt en cours de route, la tâche de recherche en douze étapes meurt avec lui.

La réponse de Cloudflare, annoncée sous le nom de Project Think le 15 avril 2026 puis élargie pendant l'Agents Week, consiste à cesser de traiter les agents comme des applications pour les traiter comme de l'infrastructure. La promesse : des agents qui survivent aux pannes, ne coûtent rien au repos, et imposent la sécurité par l'architecture plutôt que par la bonne conduite.

Le glissement est important, et il vaut la peine de distinguer ce qui est réellement nouveau de ce qui relève du réemballage.

Le problème du modèle par processus

Le cloud dont nous disposons a été conçu autour d'une hypothèse simple : une application sert de nombreux utilisateurs. Un serveur web absorbe des milliers de requêtes concurrentes parce que chaque requête est courte, sans état, et interchangeable.

Les agents brisent chaque partie de cette hypothèse.

Une session d'agent est longue — un seul appel de LLM prend environ 30 secondes, et une boucle agentique multi-tours peut durer des heures. Elle est à état — l'agent accumule mémoire, résultats d'outils et historique de conversation, impossibles à reconstruire depuis la requête suivante. Et elle est par utilisateur — si chaque collaborateur fait tourner trois ou quatre agents, l'infrastructure doit encaisser des dizaines de millions de sessions simultanées, et non des dizaines de millions de requêtes séquentielles.

La correction naïve, c'est un conteneur par agent. C'est aussi la correction coûteuse. Avec 10 000 agents actifs chacun 1 % du temps, vous payez 10 000 conteneurs toujours allumés pour faire le travail de 100.

Les fibres : l'exécution durable comme primitive de langage

L'idée technique centrale de Project Think est la fibre — une invocation durable qui jalonne sa propre progression dans une base SQLite colocalisée.

Un appel de fonction serverless classique est atomique et jetable : soit il aboutit, soit il n'a jamais eu lieu. Une fibre n'est ni l'un ni l'autre. Elle s'exécute, enregistre où elle en est, et si la plateforme redémarre sous elle, elle reprend au dernier point de reprise plutôt qu'au début.

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);
      ctx.stash({ findings, step: i, topic });
      this.broadcast({ type: "progress", step: i });
    }
    return { findings };
  });
}

L'appel ctx.stash() contient toute l'astuce. Chaque itération écrit l'état accumulé dans SQLite avant de poursuivre. Si le worker est évincé à l'étape sept, un hook onFiberRecovered réhydrate l'agent et la boucle repart de l'étape sept — pas de zéro, et sans rejouer sept appels LLM coûteux.

Si vous avez utilisé Temporal ou Inngest, cela vous semblera familier, et c'est voulu. La différence tient au lieu. Temporal offre l'exécution durable comme un service que l'on appelle depuis l'extérieur. Project Think l'offre comme une méthode sur la classe dont votre agent hérite déjà, avec le magasin de points de reprise logé dans le même isolat que la mémoire de l'agent. Nous avions couvert les orchestrateurs autonomes dans l'exécution durable pour agents IA ; Project Think, c'est la même idée repliée dans le runtime.

Hibernation et économie du repos

Chaque agent Think est un Durable Object — la primitive acteur de Cloudflare, où chaque instance possède une identité stable, sa propre base SQLite, et la capacité de se réveiller à la réception d'un message.

Conséquence : un agent qui attend un webhook, une validation humaine ou un tick planifié ne tourne pas. Il hiberne : son état persiste, son adresse reste valide, il ne consomme aucun calcul. Le calcul avancé par Cloudflare est que 10 000 agents actifs chacun 1 % du temps réclament environ 100 instances actives, et non 10 000.

Pour quiconque a regardé une facture de conteneurs d'agents au repos, ce chiffre compte plus que n'importe quel benchmark. Il convertit l'hébergement d'agents d'un problème de dimensionnement de capacité en un problème de facturation à l'usage.

Des sous-agents réellement isolés

Les systèmes multi-agents se décomposent d'ordinaire en un superviseur et des travailleurs. L'implémentation typique partage un processus et un espace mémoire, ce qui signifie que « l'isolation » entre agents relève de la convention de nommage.

Project Think s'appuie sur les Facets de Durable Object : chaque agent enfant est un Durable Object réellement distinct, avec sa propre base SQLite, adressé via un RPC typé que TypeScript vérifie à la compilation.

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)
]);

Deux conséquences. D'abord, un sous-agent ne peut pas lire par accident l'état de son voisin, faute de magasin partagé à lire — une vraie réponse aux fuites de contexte évoquées dans la cohérence des agents sur longue durée. Ensuite, la surface RPC est une interface typée : le contrat d'un sous-agent est imposé par le compilateur, non par la discipline du prompt.

L'échelle d'exécution

Les agents qui écrivent et exécutent leur propre code sont les plus utiles et les plus dangereux. Project Think structure cela en une échelle d'exécution à cinq niveaux, du niveau 0 (Workspace — de simples opérations de système de fichiers) au niveau 1 (Dynamic Workers — des isolats V8 neufs) jusqu'au niveau 4 (Sandboxes — accès complet à l'OS, shell et processus d'arrière-plan).

Le modèle de sécurité mérite d'être nommé précisément, car il inverse l'usage courant. Les Dynamic Workers démarrent sans aucune autorité ambiante et ne reçoivent des capacités que par des bindings explicites. Vous ne verrouillez pas une machine généraliste ; vous confiez à une boîte fermée exactement les clés dont elle a besoin.

Un Dynamic Worker démarre en quelques millisecondes — environ 100 fois plus vite qu'un conteneur — ce qui rend praticable qu'un agent génère un outil, l'exécute et le jette dans un même tour. Les agents peuvent même rédiger leurs propres extensions TypeScript, qui survivent à l'hibernation. C'est une posture de sécurité différente de l'approche par conteneurs décrite dans les sandboxes sécurisées pour l'exécution de code, et elle échange un peu de souplesse contre un rayon d'explosion nettement réduit.

Sessions, mémoire et budget de tokens

Dans Think, les conversations sont stockées sous forme d'arbres, pas de listes. Les messages portent des références vers leur parent, ce qui permet de bifurquer une conversation pour tenter une autre direction sans détruire la branche d'origine.

La mémoire se déclare au lieu de s'élaguer à la main :

configureSession(session: Session) {
  return session
    .withContext("memory", {
      description: "Important facts learned during conversation.",
      maxTokens: 2000
    })
    .withCachedPrompt();
}

Le budget maxTokens est le détail qui compte. Les blocs de contexte sont compactés pour tenir dans la limite, et les sessions supportent la recherche plein texte FTS5 : un agent peut récupérer un fait ancien sans traîner toute la transcription dans son prompt. C'est l'architecture que nous recommandions dans la mémoire persistante des agents, désormais fournie par le runtime au lieu d'être assemblée à la main.

Démarrer

L'agent Think minimal est réellement compact. Installez les paquets :

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

Étendez la classe de base et fournissez un modèle. C'est la seule méthode requise — Think prend en charge le protocole de chat WebSocket, la persistance des messages, la boucle agentique, l'assainissement des messages, la reprise de flux et les outils de fichiers du workspace :

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.6",
    );
  }
}

Câblez ensuite le binding Durable Object et la migration SQLite dans wrangler.jsonc :

{
  "compatibility_date": "2026-07-10",
  "compatibility_flags": ["nodejs_compat"],
  "ai": { "binding": "AI" },
  "durable_objects": {
    "bindings": [
      { "class_name": "MyAgent", "name": "MyAgent" }
    ]
  },
  "migrations": [
    { "new_sqlite_classes": ["MyAgent"], "tag": "v1" }
  ]
}

Les tours sont admis via runTurn() selon trois modes. Utilisez "wait" quand l'appelant attend un résultat, "submit" pour du travail durable en fire-and-forget avec une clé d'idempotence, et "stream" pour pousser les événements vers un callback :

const result = await this.runTurn({ input: "Your prompt" });
 
const submission = await this.runTurn({
  mode: "submit",
  input: "Process webhook",
  idempotencyKey: eventId
});

Le mode "submit" avec clé d'idempotence est celui à privilégier quand un agent est déclenché par un webhook : une livraison rejouée ne lancera pas un second tour.

La place de Think dans la pile

Le 17 juin 2026, Cloudflare a publié un billet de suivi clarifiant les couches, et c'est l'énoncé stratégique le plus net à ce jour. La plateforme est désormais explicitement à trois étages.

Le Agents SDK est le runtime — calcul, état, stockage et primitives de fibres. Au-dessus, un harness exécute la boucle agentique et gère outils et contexte ; Project Think est le harness maison et assumé de Cloudflare, Pi en est un autre. Au sommet, un framework apporte l'expérience développeur et les intégrations ; le premier tiers est Flue, un framework open source signé par l'équipe d'Astro, avec des intégrations Slack, GitHub, Linear et Discord, plus des hooks React via @flue/react.

Cette structure compte, car elle signifie que Cloudflare ne mise pas uniquement sur l'adoption de Think. L'entreprise ouvre les primitives durables du dessous à n'importe quel harness — une position bien meilleure qu'un framework isolé affrontant LangGraph et le Claude Agent SDK sur la seule ergonomie.

Limites, sans détour

Project Think est en préversion expérimentale. La surface d'API bougera, et bâtir un système de production sur des primitives en préversion est une décision, pas un défaut.

Le verrouillage fournisseur est réel et doit être valorisé. Fibres, Facets et Dynamic Workers sont spécifiques à Cloudflare d'une manière qu'une application LangGraph ou Pydantic AI n'est pas. Il n'y a pas ici d'histoire de portabilité sérieuse : vous choisissez une architecture, et le coût de sortie est une réécriture.

Enfin, le modèle acteur récompense une forme précise de problème. Des agents durables, majoritairement au repos, par utilisateur et à état se projettent magnifiquement sur les Durable Objects. Un pipeline de classification court, sans état et à fort débit, non — un Worker ordinaire ou un job batch conviendra mieux.

À retenir

L'affirmation intéressante de Project Think n'est aucune primitive prise isolément. L'exécution durable existe ailleurs. Le sandboxing existe ailleurs. La mémoire persistante existe ailleurs.

L'affirmation, c'est que tout cela devrait relever de garanties du runtime plutôt que de bibliothèques à assembler. Quand la reprise après crash est un appel de méthode, l'isolation une frontière de stockage, et le coût du repos nul par construction, toute une catégorie d'ingénierie d'agents — les wrappers de retry, les tables de points de reprise, l'autoscaling de conteneurs — cesse d'être votre problème.

Cloudflare tiendra-t-elle cette position à mesure que les frameworks au-dessus se consolident ? C'est la question ouverte. Mais la direction est juste, et c'est à ce jour la formulation la plus claire de ce que « les agents comme infrastructure » est censé signifier.

Vous construisez des agents pour la production ? Noqta accompagne les équipes MENA dans la conception, le déploiement et la gouvernance d'infrastructures d'agents IA qui résistent au contact des vrais utilisateurs. Parlez à notre équipe.

Sources