Project Think : développer la nouvelle génération d’agents IA sur Cloudflare

Aujourd’hui, nous lançons Project Think : la nouvelle génération du SDK Agents. Project Think propose un ensemble de nouvelles primitives dédié à la création d’agents à longue durée d’exécution (exécution durable, sous-agents, exécution de code en sandbox, sessions persistantes) et une classe de base prescriptive, permettant de toutes les connecter. Vous pouvez utiliser les primitives pour créer précisément l’agent dont vous avez besoin ou utiliser la classe de base pour vous lancer rapidement.

Un événement survenu plus tôt cette année a bouleversé notre perception de l’IA. Des outils tels que Pi, OpenClaw, Claude Code et Codex ont démontré une idée simple, mais puissante : si vous donnez à un LLM la capacité de lire des fichiers, d’écrire du code, de l’exécuter et de mémoriser ce qu’il a appris, vous obtiendrez une solution qui ressemble davantage à un assistant généraliste qu’à un outil de développement.

Ces agents de codage ne se contentent plus d’écrire du code. Les utilisateurs s’en servent pour gérer leurs calendriers, analyser des ensembles de données, négocier des achats, remplir leurs déclarations d’impôts et automatiser des processus opérationnels entiers. Le schéma est toujours le même : l’agent analyse le contexte, exécute un raisonnement, écrit du code pour agir, observe le résultat, puis recommence. Le code est le moyen d’action universel.

Notre équipe, qui utilise ces agents de codage tous les jours, se heurtait continuellement aux mêmes obstacles :

• Les agents s’exécutent uniquement sur votre ordinateur portable ou sur un serveur virtuel privé (VPS) coûteux : il n’y a ni partage, ni collaboration, ni transfert entre les appareils.

• Ils sont coûteux lorsqu’ils sont inactifs : un agent comporte un coût mensuel fixe, qu’il fonctionne ou non. Si vous transposez ce coût à une équipe, voire à une entreprise, le montant augmente rapidement.

• Les agents nécessitent une gestion et une configuration manuelles : installation des dépendances, gestion des mises à jour, configuration des identités et des secrets.

Il existe par ailleurs un problème structurel plus profond. Les applications traditionnelles servent une multitude d’utilisateurs depuis une instance unique. Comme nous l’avons indiqué dans notre article « Bienvenue dans l’Agents Week », les agents opèrent selon un principe « un pour un ». Chaque agent est une instance unique, qui sert un utilisateur et exécute une tâche. Un restaurant propose un menu et dispose d’une cuisine optimisée pour préparer des plats en grande quantité. Un agent ressemble davantage à un chef à domicile : à chaque fois, il utilise d’autres ingrédients, d’autres techniques et d’autres outils.

Cela modifie radicalement les calculs concernant l’évolutivité. Si cent millions de travailleurs du savoir utilisent chacun un assistant agentique, même avec un nombre modeste de sessions simultanées, vous devez disposer d’une capacité permettant de gérer des dizaines de millions de sessions simultanées. Compte tenu des coûts par conteneur actuels, cette approche n’est pas viable. Nous avons besoin d’une fondation différente.

Et c’est ce que nous avons développé, dernièrement.

Project Think propose un ensemble de nouvelles composantes primitives pour le SDK Agents :

• Exécution durable avec les « fibers » : reprise après incident, points de sauvegarde et persistance automatique

• Sous-agents : agents enfants isolés disposant chacun de leur propre instance SQLite et d’un RPC typé

• Sessions persistantes : messages structurés en arborescence, création de branches, compaction, recherche en texte intégral

• Exécution de code en sandbox : instances Dynamic Workers, codemode, résolution dynamique des packages npm lors de l’exécution

• L’échelle d’exécution : espace de travail, isolat, npm, navigateur, sandbox

• Extensions auto-générées : les agents créent leurs propres outils lors de l’exécution

Chacune de ces composantes primitives est utilisable directement avec la classe de base Agent. Vous pouvez utiliser les primitives pour développer précisément les agents dont vous avez besoin ou utiliser la classe de base de Think pour vous lancer rapidement. Examinons ce que fait chacune d’elles.

Les agents, tels qu’ils existent aujourd’hui, sont éphémères. Ils s’exécutent le temps d’une session, liés à un processus ou à un appareil unique, puis ils s’arrêtent. Un agent de codage qui s’arrête lorsque votre ordinateur se met en veille est un simple outil. Un agent qui persiste (c’est-à-dire un agent capable de se réveiller à la demande, de poursuivre le travail après une interruption et de transférer l’état sans dépendre de votre environnement d’exécution local) commence à ressembler à une infrastructure – et cela modifie complètement le modèle d’évolutivité des agents.

Le SDK Agents s’appuie sur Durable Objects pour fournir à chaque agent une identité, un état persistant et la capacité de se réveiller à la réception d’un message. Il s’agit du modèle acteur : chaque agent est une entité adressable disposant de sa propre base de données SQLite. Il ne consomme aucune puissance de calcul lorsqu’il est en veille prolongée. Lorsqu’un événement se produit (une requête HTTP, un message WebSocket, une alerte programmée, un e-mail entrant), la plateforme réveille l’agent, charge son état et lui transmet l’événement. L’agent effectue son travail, puis se remet en veille.

	VM/Conteneurs	Durable Objects
Coût en veille	Coût total en puissance de calcul, en permanence	Zéro (veille prolongée)
Mise à l'échelle	Provisionnement et gestion de la capacité	Automatique, par agent
État	Base de données externe requise	Base de données SQLite intégrée
Reprise	Développement par vos soins (gestionnaires de processus, vérifications d’intégrité)	Redémarrage de la plateforme, persistance de l’état
Identité/routage	Développés par vos soins (équilibrage de charge, sessions persistantes)	Intégrés (nom → agent)
10 000 agents, actifs 1 % du temps	10 000 instances toujours actives	Env. 100 instances actives à tout moment

Cette approche modifie les paramètres économiques de l’exécution d’agents à grande échelle. Au lieu de déployer « un agent coûteux par utilisateur expérimenté », vous pouvez créer « un agent par client », « un agent par tâche » ou « un agent par fil de discussion par e-mail ». Le coût marginal qu’entraîne la création d’un nouvel agent est pratiquement nul.

L’exécution d’un appel à un LLM demande 30 secondes. L’exécution d’une boucle d’agent à plusieurs tours peut durer beaucoup plus longtemps. À tout moment pendant cette période, l’environnement d’exécution peut être arrêté en raison d’un déploiement, d’un redémarrage de la plateforme ou du dépassement des limites des ressources. La connexion en amont vers le fournisseur de modèles est définitivement interrompue, l’état en mémoire est perdu et, pour les clients connectés, le flux s’arrête sans aucune explication.

runFiber() résout ce problème. Un « fiber » est un appel de fonction persistant : il est enregistré dans SQLite avant le début de l’exécution, peut être sauvegardé à tout moment via stash() et peut être restauré au redémarrage via 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);
    }
  }
}

Le SDK maintient automatiquement l’activité de l’agent pendant l’exécution du fiber, sans qu’aucune configuration particulière ne soit nécessaire. Pour les tâches mesurées en minutes, les fonctions keepAlive()/keepAliveWhile() empêchent l’éviction pendant son fonctionnement actif. Pour les opérations plus longues (pipelines CI, revues de conception, génération de vidéos), l’agent démarre l’exécution de la tâche, enregistre l’identifiant de la tâche, se met en veille prolongée, puis se réactive en cas de rappel.

Un agent unique ne devrait pas exécuter toutes les tâches lui-même. Les sous-agents sont des instances enfant Durable Objects colocalisées avec l’instance parent via Facets, disposant chacune de leur propre base de données SQLite et d’un contexte d’exécution isolé :

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

Les sous-agents sont isolés au niveau du stockage. Chacun dispose de sa propre base de données SQLite, et il n’y a aucun partage implicite de données entre eux. Cet isolement est imposé par l’environnement d’exécution, où la latence d’un appel RPC vers un sous-agent équivaut à un simple appel de fonction. TypeScript détecte les utilisations abusives lors de la compilation.

Le fonctionnement d’agents qui s’exécutent pendant plusieurs jours, voire plusieurs semaines nécessite plus qu’une liste linéaire standard de messages. L’API Session expérimentale modélise explicitement ce processus. Dans la classe de base Agent, les conversations sont stockées sous forme d’arborescences, chaque message disposant d’un parent_id. Cette configuration permet la création de branches (c’est-à-dire l’exploration d’une approche alternative sans perdre le chemin d’origine), la compaction non destructive (le résumé d’anciens messages, plutôt que leur suppression) et la recherche en texte intégral dans l’historique des conversations via 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");
  }
}

L’API Session est utilisable directement avec Agent et constitue la couche de stockage sur laquelle s’appuie la classe de base Think.

La syntaxe conventionnelle des appels d’outils est peu pratique. Le modèle appelle un outil, récupère le résultat par le biais de la fenêtre de contexte, appelle un autre outil, récupère ce résultat, et ainsi de suite. À mesure que la surface des outils s’accroît, cette approche devient à la fois coûteuse et peu pratique. Une centaine de fichiers correspond à une centaine d’allers-retours dans le modèle.

Toutefois, les modèles sont plus à même d’écrire du code permettant d’utiliser un système que de se livrer au jeu de l’exécution d’appels d’outils. C’est l’idée sur laquelle repose @cloudflare/codemode : au lieu d’exécuter des appels d’outils séquentiels, le LLM écrit un programme unique qui gère l’ensemble de la tâche.

// 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;

Au lieu d’effectuer 100 allers-retours vers le modèle, il suffit d’exécuter un programme unique. Cela permet de réduire le nombre de jetons utilisés, d’accélérer l’exécution et d’obtenir de meilleurs résultats. Le serveur MCP de l’API Cloudflare le démontre à grande échelle. Nous n’exposons que deux outils (search() et execute()), qui consomment environ 1 000 jetons, contre environ 1,17 million de jetons pour l’approche équivalente naïve, reposant sur un outil par point de terminaison. Cela représente une réduction de 99,9 %.

Lorsque vous avez admis le postulat que les modèles doivent écrire du code pour le compte des utilisateurs, la question qui se pose est la suivante : où s’exécute ce code ? Pas finalement, pas après qu’une équipe produit en ait fait un élément de la feuille de route. À l’heure actuelle, pour cet utilisateur, sur ce système, avec des autorisations étroitement définies.

Dynamic Workers est cette sandbox. Un nouvel isolat V8 est lancé lors de l’exécution, en quelques millisecondes, avec quelques mégaoctets de mémoire seulement. Cette approche est environ 100 fois plus rapide et jusqu’à 100 fois plus économe en mémoire qu’un conteneur. Vous pouvez démarrer un nouvel isolat pour chaque requête, exécuter un fragment de code, puis le supprimer.

Le choix conceptuel déterminant est le modèle de capacité. Au lieu de partir d’une machine polyvalente et d’essayer de la contraindre, les instances Dynamic Workers commencent pratiquement sans aucune autorité ambiante (globalOutbound: null, aucun accès réseau) et le développeur accorde les capacités de manière explicite, ressource par ressource, par le biais de liaisons. La question n’est plus « Comment empêcher cet agent d’en faire trop ? » à « Que voulons-nous exactement qu’il soit capable de faire ? ».

Il s’agit de la question pertinente concernant l’infrastructure des agents.

Ce modèle de capacité engendre naturellement un éventail d’environnements de calcul, une échelle d’exécution que l’agent peut gravir à mesure que ses besoins évoluent :

Le niveau Tier 0 correspond à Workspace, un système de fichiers virtuel durable reposant sur SQLite et R2. Lecture, écriture, édition, recherche, grep, diff. Repose sur @cloudflare/shell.

Le niveau Tier 1 est une instance Workers dynamique : du code JavaScript généré par LLM, exécuté dans un isolat en sandbox sans accès au réseau. Repose sur @cloudflare/codemode.

Le niveau Tier 2 ajoute npm. @cloudflare/worker-bundler récupère les packages dans le registre, les regroupe avec esbuild, puis charge le résultat dans l’instance Dynamic Workers. L’agent écrit import { z } from "zod", et ça fonctionne – tout simplement.

Le niveau Tier 3 correspond à un navigateur headless via Cloudflare Browser Run. Navigation, clic, extraction, capture d’écran. Utile lorsque le service ne prend pas encore en charge les agents via MCP ou les API.

Le niveau Tier 4 est une sandbox Cloudflare configurée avec vos chaînes d’outils, vos référentiels et vos dépendances (git clone, npm test, cargo build), qui bénéficie d’une synchronisation bidirectionnelle avec Workspace.

Le principe de conception fondamental : l’agent doit être utile dès le niveau Tier 0, chaque niveau étant additif. L’utilisateur peut ajouter des fonctionnalités au fur et à mesure.

Toutes ces composantes primitives sont disponibles sous forme de packages autonomes. Dynamic Workers, @cloudflare/codemode, @cloudflare/worker-bundler et @cloudflare/shell (un système de fichiers durable avec des outils) sont tous utilisables directement avec la classe de base Agent. Vous pouvez les associer pour fournir à n’importe quel agent une instance Workspace, ainsi que la capacité d’exécuter du code et de résoudre des packages de l’environnement d’exécution sans adopter un cadre prescriptif.

Voici la pile complète pour développer des agents sur Cloudflare :

Fonctionnalités	Ses actions	Repose sur
Isolement par agent	Chaque agent est un environnement à part entière	Durable Objects (DO)
Aucun coût en cas d’inactivité	0 $ jusqu’à ce que l’agent se réveille	Veille prolongée de DO
État persistant	Stockage transactionnel et interrogeable	SQLite pour DO
Système de fichiers durable	Fichiers survivant aux redémarrages	Workspace (SQLite + R2)
Exécution de code dans une sandbox	Exécution sécurisée de code généré par LLM	Dynamic Workers + @cloudflare/codemode
Dépendances du runtime	import * from react fonctionne, tout simplement	@cloudflare/worker-bundler
Automatisation web	Consultation, navigation, renseignement de formulaires	Browser Run
Accès intégral au système d’exploitation	git, compilateurs, outils d’exécution de tests	Sandboxes
Exécution programmée	Proactif, pas uniquement réactif	Alertes DO et fibers
Streaming en temps réel	Jeton par jeton vers n’importe quel client	Protocoles WebSocket
Outils externes	Connexion à n’importe quel serveur d’outils	MCP
Coordination d’agents	RPC typé entre agents	Sous-agents (Facets)
Accès aux modèles	Connexion à un LLM afin de piloter l’agent	AI Gateway + Workers AI (ou Bring Your Own Model)

Chacun de ces éléments est un composant fondamental. Ensemble, ils forment quelque chose de nouveau : une plateforme sur laquelle chacun peut développer, déployer et exécuter des agents IA aussi performants que ceux qui s’exécutent actuellement sur votre machine locale. Toutefois, ces agents sont serverless, durables et intrinsèquement sûrs.

Maintenant que vous avez découvert les composantes primitives, voici ce qui se passe lorsque vous les connectez toutes.

Think est un cadre de travail prescriptif, qui gère l’intégralité du cycle de vie de la conversation : boucle agentique, persistance des messages, streaming, exécution d’outils, reprise de flux et extensions. Vous vous concentrez ainsi sur ce qui rend votre agent unique.

La sous-classe minimale se présente ainsi :

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

En pratique, c’est tout ce dont vous avez besoin pour disposer d’un agent de discussion fonctionnel avec streaming, persistance, interruption/annulation, traitement des erreurs, des flux avec reprise et un système de fichiers intégré dans l’espace de travail. Déployez avec npx wrangler deploy.

Think prend des décisions pour vous. Si vous avez besoin de davantage de contrôle, vous pouvez vous réserver celles qui importent pour vous :

Substitution	Objectif
getModel()	Renvoyer le LanguageModel à utiliser
getSystemPrompt()	Invite système
getTools()	ToolSet compatible avec le SDK IA pour la boucle agentique
maxSteps	Nombre maximum d’appels d’outils par tour
configureSession()	Blocs de contexte, compaction, recherche, fonctionnalités

En coulisses, Think exécute la boucle agentique complète à chaque tour : il assemble le contexte (instructions de base + descriptions d’outils + compétences + mémoire + historique de la conversation), appelle streamText, exécute les appels d’outil (avec troncature de la sortie afin d’éviter l’explosion du contexte), ajoute les résultats, puis répète la boucle jusqu’à ce que le modèle ait terminé ou que la limite d’étape soit atteinte. Tous les messages sont persistants après chaque tour.

Think met à votre disposition des hooks (c’est-à-dire des points d’ancrage) à chaque étape du tour de conversation, sans vous contraindre à gérer l’ensemble du pipeline :

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

Optez pour un modèle moins coûteux pour les tours de suivi, restreignez le choix d’outils que peut utiliser le modèle et transmettez le contexte côté client à chaque tour. Vous pouvez également enregistrer chaque appel d’outil dans le système d’analyse de données et déclencher automatiquement un tour de suivi supplémentaire, une fois l’exécution du modèle terminée – et tout cela, sans remplacer onChatMessage.

Think utilise l’API Session comme couche de stockage, mettant ainsi à votre disposition des messages structurés sous forme d’arborescence avec une gestion des branches intégrée.

Par ailleurs, Think ajoute de la mémoire persistante par le biais de blocs de contexte. Il s’agit de sections structurées de l’invite système que le modèle peut lire et mettre à jour au fil du temps, et qui persistent pendant toute la durée de la mise en veille prolongée. Le modèle voit « MEMORY (infos importantes, utiliser set_context pour mettre à jour) [42%, 462/1100 jetons] » et peut mémoriser proactivement des informations.

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();
}

Les sessions sont flexibles. Vous pouvez exécuter plusieurs conversations par agent et créer des branches afin d’explorer une autre approche, sans toutefois perdre le chemin original. 

À mesure que le contexte s’étoffe, Think gère les limites grâce à une compaction non destructive. Les messages les plus anciens sont résumés, et non supprimés, tandis que l’historique complet reste stocké dans SQLite.

Une fonction de recherche est également intégrée. Avec FTS5, vous pouvez interroger l’historique des conversations d’une session ou de l’ensemble des sessions. L’agent peut également effectuer des recherches dans son propre passé avec l’outil search_context.

Think intègre la totalité de la chaîne d’exécution dans le retour d’une fonction getTools() unique :

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 va encore plus loin dans l’exécution du code. Un agent peut écrire ses propres extensions : des programmes TypeScript qui s’exécutent dans des instances Dynamic Workers et définissent les autorisations d’accès au réseau et d’exécution d’opérations dans Workspace.

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

Le service ExtensionManager de Think regroupe l’extension (éventuellement avec des dépendances npm, via @cloudflare/worker-bundler), charge celle-ci dans une instance Dynamic Workers, puis et enregistre les nouveaux outils. L’extension reste enregistrée dans le stockage de DO et survit à la mise en veille prolongée. La prochaine fois que l’utilisateur interroge les requêtes pull, l’agent disposera d’un outil github_create_pr qui n’existait pas encore 30 secondes plus tôt.

C’est ce genre de boucle d’amélioration qui permet aux agents de devenir véritablement plus utiles au fil du temps – pas grâce à des réglages précis ou à l’apprentissage par renforcement à partir de retours humains, mais par le biais du code. L’agent est capable d’écrire de nouvelles fonctionnalités pour lui-même, et cela, en TypeScript, dans un environnement en sandbox, vérifiable et révocable.

Think peut également fonctionner comme un sous-agent, appelé via l’instruction chat() par l’intermédiaire de RPC depuis un agent parent, avec la transmission des événements de streaming via une fonction de rappel :

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

Chaque agent enfant isolé dispose d’une arborescence de conversation, d’une mémoire, d’outils et d’un modèle propres. L’agent parent n’a pas besoin de connaître les détails.

Le projet Think est expérimental. La surface de l’API est stable, mais l’API continuera d’évoluer au fil des jours et des semaines à venir. Nous l’utilisons déjà en interne pour créer notre propre infrastructure d’agents en arrière-plan, et nous la partageons précocement pour vous permettre de développer des solutions avec nous.

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 utilise le même protocole WebSocket que @cloudflare/ai-chat ; ainsi, les composants d’IU existants fonctionnent immédiatement. Si vous avez développé une solution avec AIChatAgent, votre code client n’a pas besoin d’être modifié.

Nous distinguons trois vagues d’agents IA :

La première vague a été celle des chatbots. Ils étaient réactifs et fragiles, et s’exécutaient sans état. Chaque conversation partait de zéro, sans mémoire, sans outils et sans capacité d’agir. Les chatbots étaient utiles pour répondre aux questions d’utilisateurs, mais leur utilité se limitait à cette seule fonction.

La deuxième vague a été celle des agents de codage. Ces outils avec état sont capables d’utiliser des outils et sont dotés de capacités considérablement supérieures (Pi, Claude Code, OpenClaw et Codex, entre autres). Ces agents peuvent lire des bases de code, écrire du code, l’exécuter et réaliser des améliorations itératives. S’ils ont démontré qu’un LLM doté d’outils pertinents est une machine polyvalente, ils s’exécutent sur votre ordinateur portable, pour un utilisateur seulement, sans aucune garantie de durabilité.

Nous abordons maintenant dans la troisième vague : les agents en tant qu’infrastructure. Ils sont durables, distribués, structurellement sûrs et proposent une exécution serverless. Il s’agit d’agents qui s’exécutent sur Internet, survivent aux défaillances, n’entraînent aucun coût lorsqu’ils sont inactifs et assurent une sécurité reposant sur leur architecture, plutôt que sur leur comportement. Ces agents peuvent être créés et déployés par n’importe quel développeur pour un nombre illimité d’utilisateurs.

C’est l’approche que nous privilégions.

Des milliers d’agents de production reposent déjà sur le SDK Agents. Avec Project Think et les primitives qu’il introduit, nous ajoutons les pièces manquantes permettant de rendre ces agents considérablement plus performants : espaces de travail persistants, exécution de code en sandbox, tâches durables à longue durée d’exécution, sécurité structurelle, coordination de sous-agents et extensions auto-générées.

Project Think est disponible dès aujourd’hui dans une version préliminaire. Nous développons à vos côtés, et nous avons vraiment hâte de découvrir ce que vous (et votre agent de codage) allez créer avec cet outil.

---

^{Think fait partie du SDK Agents de Cloudflare, disponible sous @cloudflare/think. Les fonctionnalités décrites dans cet article sont disponibles en version préliminaire. Les API sont susceptibles d’être modifiées à mesure que nous intégrons les commentaires. Consultez la documentation et l’exemple pour vous lancer.}