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

La découverte d'une perte inattendue

Un mardi matin, à 9h03, un agent de recherche a salué le dirigeant, 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é. Le dirigeant avait 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é, il a 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 qui a été exécuté, les éléments qui ont échoué, et l'erreur qui 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 l'exécution est gérée par l'utilisateur. 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. L'utilisateur configure un environnement auto-hébergé via la console Claude. Une fois l'application lancée, Anthropic met en file d'attente le travail, l'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 entièrement contrôlé par l'utilisateur. Anthropic n'intervient jamais directement. L'utilisateur définit l'apparence de cet environnement, ses accès, et ce qui se passe entre les sessions. L'intelligence d'Anthropic est constante. L'ingénierie de l'utilisateur 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.

Le projet et son importance

L'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, une session était lancée à 20 heures, laissée fonctionner jusqu'à minuit, puis reprise 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 qui a été prise.

Des besoins insoupçonnés

Au départ, il était pensé qu'un simple environnement Linux suffirait pour exécuter les agents gérés Claude. Finalement, il a été compris que trois éléments essentiels étaient nécessaires. Ils ont tous été 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. Elles ont été découvertes à travers une série d'erreurs.

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

Pour lancer une session, l'orchestrateur de référence est utilisé 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 le 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 l'utilisateur l'arrête. 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 le 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

La première hypothèse était qu'une plateforme capable d'exécuter efficacement les agents gérés Claude était nécessaire. Cloudflare est optimisé pour une exécution à haute concurrence. Le problème s'est avéré différent. L'agent en construction 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 qu'il a été réalisé que ce n'était pas de calcul qui était recherché, mais 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, il a été voulu 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, il a fallu 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 la deuxième exigence a été découverte. Préserver l'état n'était pas suffisant. Un moyen de bifurquer à partir d'un état existant sans répéter des heures de travail était également nécessaire.

Troisième tentative : Tensorlake

La première chose qui a attiré l'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 qu'un design abordait directement le problème auquel il était confronté. Il a été voulu savoir si cela fonctionnait réellement. L'expérimentation a commencé avec…