Claude : l'état des agents gérés, plus crucial que le calcul

La découverte d'une perte inattendue

Un mardi matin, à 9h03, mon agent de recherche m'a salué, mais ce fut pour constater un vide inquiétant dans le répertoire de travail. Les six heures d'analyse effectuées la nuit précédente avaient disparu. Tout, du dépôt cloné aux paquets installés, en passant par les notes méticuleusement rédigées, s'était volatilisé. J'avais naïvement cru qu'un agent pouvait simplement reprendre son travail là où il l'avait laissé après une pause nocturne. Cette hypothèse s'est avérée erronée. Pour comprendre ce qui s'était passé, j'ai dû reconstruire le même flux de travail sur trois plateformes différentes : Tensorlake, Cloudflare et Daytona. Ce qui s'est révélé le plus complexe dans la gestion des agents Claude n'était pas le modèle lui-même, mais tout ce qui se trouvait en dessous.

Voici le code exact que j'ai exécuté, les éléments qui ont échoué, et l'erreur qui m'a coûté deux semaines à comprendre.

Comprendre les agents gérés Claude

Pour ceux qui ne sont pas familiers avec les agents gérés Claude, il est crucial de comprendre leur architecture. Si vous connaissez déjà ce système, vous pouvez passer cette section. Anthropic est responsable du raisonnement, tandis que vous gérez l'exécution. La boucle de l'agent, l'état de session, la file de travail et la logique de réessai sont toutes hébergées sur l'infrastructure d'Anthropic. Vous configurez un environnement auto-hébergé via la console Claude. Une fois votre application lancée, Anthropic met en file d'attente le travail, votre orchestrateur le récupère, crée un bac à sable, et le modèle commence à émettre des appels d'outils dans ce bac à sable. Chaque commande, qu'il s'agisse de bash, read, write, grep ou edit, s'exécute dans un environnement que vous contrôlez entièrement. Anthropic n'intervient jamais directement. Vous définissez l'apparence de cet environnement, ses accès, et ce qui se passe entre les sessions. L'intelligence d'Anthropic est constante. Votre ingénierie détermine si cette intelligence opère dans un environnement stable et persistant ou sur une ardoise vierge qui oublie tout dès qu'elle devient inactive.

Mon projet et son importance

Mon objectif était de créer un agent capable de mener des recherches approfondies sur une base de code : cloner un dépôt, analyser la structure des modules, comprendre comment les différentes parties s'assemblent, rédiger des notes et proposer des stratégies de refactorisation. Ce type de travail, qui prendrait une journée entière à un ingénieur senior, peut être accompli en environ six heures par un agent IA. La contrainte principale était que l'agent ne pouvait pas tout faire d'un coup. Parfois, je lançais une session à 20 heures, la laissais fonctionner jusqu'à minuit, puis la reprenais le lendemain matin. Le système de fichiers créé lors de cette première session — avec les notes d'analyse, les outils installés, et les fichiers source partiellement lus — devait être disponible lorsque la session suivante commençait. Reconstruire à chaque fois n'était pas une option viable. Cette contrainte a guidé chaque décision de fournisseur que j'ai prise.

Des besoins insoupçonnés

Au départ, je pensais qu'un simple environnement Linux suffirait pour exécuter les agents gérés Claude. Finalement, j'ai compris que j'avais besoin de trois éléments essentiels. Je les ai tous trouvés au même endroit, mais seulement après avoir exploré deux autres options.

• Un système de fichiers qui survive entre les sessions de travail.
• Un coût quasi nul pendant que l'agent était inactif.
• La capacité de bifurquer à partir d'un état d'analyse déjà complété.

Ces exigences ne se sont pas révélées immédiatement. Je les ai découvertes à travers une série d'erreurs.

Le démarrage d'une session : le code avant le bac à sable

Pour lancer une session, vous utilisez l'orchestrateur de référence avec une commande simple :

[make](/outil/make) session [PROMPT](/glossaire/prompt)="Clone the repository at github.com/tensorlakeai/tensorlake. \Read through the module structure. Write a summary to /workspace/analysis.md. \Note any components that look like they could be simplified."

L'orchestrateur envoie cette invite à Anthropic comme une nouvelle session. Anthropic la prend en charge, démarre la boucle de l'agent et commence immédiatement à émettre des appels d'outils. Ces appels d'outils arrivent dans votre bac à sable. L'agent lit des fichiers, exécute des commandes bash, écrit des notes. La session se déroule jusqu'à ce que la tâche soit terminée ou que vous l'arrêtiez. Le flux de l'agent ressemble à peu près à ceci pendant qu'il fonctionne :

• [thinking] Le dépôt semble être un SDK Python pour…
• [bash] git clone https://github.com/tensorlakeai/tensorlake
• [bash] ls -la /workspace/tensorlake/
• [read] /workspace/tensorlake/tensorlake/sandbox.py
• [write] /workspace/analysis.md
• [thinking] La classe Sandbox gère…

Chaque événement entre crochets est un appel d'outil entrant dans votre bac à sable. La session accumule un état à l'intérieur de /workspace/ à travers tous ces appels. À la fin d'une session de six heures, ce répertoire contient le dépôt cloné, les paquets installés, les fichiers d'analyse et les notes intermédiaires. C'est cet état qui doit survivre à la nuit.

Première tentative : Cloudflare

Ma première hypothèse était que j'avais besoin d'une plateforme capable d'exécuter efficacement les agents gérés Claude. Cloudflare est optimisé pour une exécution à haute concurrence. Mon problème s'est avéré différent. L'agent que je construisais accumulait des heures d'état de système de fichiers entre les périodes de travail. Notes, dépôts clonés, dépendances installées et analyses intermédiaires devaient survivre à la nuit. Le modèle d'exécution de Cloudflare n'était pas conçu autour de cette exigence. C'était la première fois que je réalisais que je ne cherchais pas de calcul. Je cherchais un état persistant.

Deuxième tentative : Daytona

La deuxième construction a résolu une partie du problème. L'agent pouvait accumuler un état tout au long d'une session, ce qui semblait initialement être un progrès. Ensuite, je voulais tester trois stratégies de refactorisation différentes en partant de la même analyse de six heures. Au lieu de bifurquer à partir de cet état, je me suis retrouvé à répéter le travail de configuration à chaque fois : reconstruire le contexte, réinstaller les dépendances et relancer l'analyse avant de pouvoir commencer l'expérience réelle. C'est à ce moment-là que j'ai découvert ma deuxième exigence. Préserver l'état n'était pas suffisant. J'avais également besoin d'un moyen de bifurquer à partir d'un état existant sans répéter des heures de travail.

Troisième tentative : Tensorlake

La première chose qui a attiré mon attention n'était pas une fonctionnalité. C'était une décision architecturale. La plupart des plateformes préservent l'état en maintenant le calcul actif. Celle-ci traitait le calcul et l'état comme des problèmes distincts. La documentation décrivait un bac à sable suspendu capable de préserver son état et de reprendre en environ 0,6 secondes. C'était la première fois que je voyais un design qui abordait directement le problème auquel j'étais confronté. Je voulais savoir si cela fonctionnait réellement. J'ai commencé avec…