Agents à longue exécution — qu’est-ce qui change quand un agent fonctionne pendant plusieurs jours ?

• Un nouveau paradigme émerge : des agents IA s’exécutent de façon autonome pendant plusieurs jours à plusieurs semaines au lieu d’une simple session de chat, naviguent entre plusieurs fenêtres de contexte et sandboxes, récupèrent après un échec et reprennent à partir d’un point d’interruption
• Les agents existants se heurtent aux limites structurelles d’une session unique : épuisement de la fenêtre de contexte, excès de confiance dans l’auto-évaluation, réintroduction de modifications précédemment corrigées, etc.
• De grandes entreprises comme Anthropic, Google et Cursor convergent vers une architecture séparant boucle du modèle, sandbox d’exécution et journaux de session
• Les défis clés des agents à longue exécution sont la gestion d’un état persistant, l’auto-vérification et la compression du contexte, avec cinq modèles de conception proposés pour les résoudre
• Plus que le modèle lui-même, la couche d’état, de session et de handoff structuré qui l’entoure constitue aujourd’hui le principal domaine d’investissement qui crée un vrai différentiel de productivité

---

Les trois sens de « longue exécution »

• Long-horizon reasoning : la capacité à planifier et exécuter sur de nombreuses étapes dépendantes, ce qui relève surtout de la qualité du modèle. Selon l’indicateur time horizon de METR, la durée des tâches que les modèles de pointe peuvent terminer avec 50 % de fiabilité double environ tous les 7 mois depuis 2019 ; si cette tendance se maintient, ils pourraient accomplir des tâches à l’échelle du jour en 2028, puis de l’année en 2034
• Long-running execution : une structure où le processus d’agent tourne pendant des heures ou des jours, avec potentiellement des milliers d’appels au modèle ; cela relève surtout de la conception du harness
• Persistent agency : une forme où l’agent conserve une identité au-delà d’une tâche unique, accumule de la mémoire et apprend les préférences utilisateur. Memory Bank de Google en est un exemple représentatif
• En production, les agents réels combinent souvent les trois, mais les problèmes d’ingénierie et les solutions associées diffèrent pour chacun

Pourquoi les agents à longue exécution sont importants

• Un agent qui s’exécute 10 minutes reste cantonné aux réponses à des questions ou aux petites corrections de bugs, alors qu’un agent qui s’exécute 10 heures peut développer une fonctionnalité complète, terminer une migration en retard depuis 6 trimestres ou mener une recherche au niveau d’un analyste junior
• Lors de l’annonce de Claude Sonnet, Anthropic a révélé des cas de codage autonome pendant plus de 30 heures selon ses tests internes, avec la création en une seule exécution d’une application de type Slack d’environ 11 000 lignes
• Dans Project Vend, une instance de Claude a exploité pendant un mois une véritable activité de distributeur automatique de bureau, gérant le stock, la tarification et la communication avec les fournisseurs. La première phase a mis en évidence des échecs significatifs, puis la deuxième a montré de fortes améliorations
  • L’enjeu n’était pas la rentabilité, mais l’observation des problèmes de cohérence qui apparaissent quand un agent conserve une identité sur des semaines plutôt que sur des tours de dialogue

Les trois murs que tous les agents à longue exécution rencontrent

• Contexte fini : même une fenêtre de 1M tokens finit par se remplir, et une context rot (dégradation progressive des performances du modèle) apparaît avant même saturation. Une exécution de 24 heures ne correspond aujourd’hui à aucune feuille de route réaliste de fenêtre de contexte
• Absence d’état persistant : une nouvelle session démarre à blanc. Anthropic compare cela à un ingénieur qui arrive en prise de poste sans avoir la moindre idée de ce qui s’est passé pendant l’équipe précédente
• Absence d’auto-vérification : quand un modèle évalue son propre travail, il manifeste systématiquement un biais positif. À la question « est-ce terminé ? », il répond plus souvent « oui » que la réalité ne le justifie, et sans signal de validation distinct, il peut livrer un résultat avec une confiance totale alors qu’il n’est achevé qu’à 30 %

La boucle Ralph : une implémentation simple d’agent à longue exécution pour les praticiens

• La boucle Ralph (technique Ralph Wiggum) est un motif d’agent à longue exécution popularisé par Geoffrey Huntley et Ryan Carson, avec une implémentation de référence tenant dans un simple script bash
• Ordre de fonctionnement : choisir une tâche inachevée (prd.json) → construire un prompt à partir de la tâche, du contexte et de notes → appeler l’agent → lancer les tests → ajouter les résultats à progress.txt → mettre à jour la liste de tâches → recommencer
• Principe central : l’agent lui-même est amnésique, mais le système de fichiers conserve la mémoire. prd.json sert de plan, progress.txt de cahier de labo et AGENTS.md de manuel de règles évolutif
• Le Compound Product de Ryan Carson enchaîne plusieurs boucles — boucle d’analyse (lecture des rapports quotidiens) → boucle de planification (création du PRD) → boucle d’exécution (écriture du code) — ce qui correspond à une version open source de la structure tripartite planner-generator-evaluator à laquelle Anthropic est parvenu de son côté
• Avec un script bash et quelques fichiers JSON, il est possible de construire en une nuit un agent à longue exécution opérationnel. Ce que Google et Anthropic ont industrialisé, c’est la transformation de ce motif en quelque chose de récupérable, sûr et observable

Anthropic : du harness à la séparation Brain/Hands/Session

• Première approche (structure du harness) : un harness à 2 agents pour le développement full-stack autonome. L’agent Initializer prépare l’environnement initial du projet, développe le prompt en feature-list.json et écrit le script de démarrage (init.sh). L’agent Coding se réveille de manière répétée, progresse fonctionnalité par fonctionnalité, lance les tests, écrit dans claude-progress.txt et effectue des commits
  • Règle du test ratchet : « supprimer ou modifier les tests n’est pas autorisé » — afin d’éviter l’échec fréquent où l’agent supprime les tests qui échouent pour obtenir un succès artificiel
  • Dans la version étendue par InfoQ, l’approche évolue vers une structure tripartite planner, generator, evaluator. La séparation entre génération et évaluation est importante parce qu’un modèle juge son propre travail avec trop d’indulgence
• Deuxième approche (séparation Brain/Hands/Session) : l’architecture de Claude Managed Agents (lancée début avril 2026)
  • Brain : le modèle et la boucle du harness
  • Hands : l’environnement d’exécution temporaire sandboxé où les outils sont réellement utilisés
  • Session : un journal d’événements append-only de toutes les pensées, appels d’outils et observations
• Le cadrage clé d’Anthropic : « tous les composants du harness encodent des hypothèses sur ce que le modèle ne peut pas faire seul » ; lorsqu’ils sont couplés, un changement d’hypothèse oblige à revoir tout le système, tandis qu’en les séparant, le harness devient sans état et la sandbox peut être traitée comme du bétail consommable
• Un nouveau conteneur peut appeler wake(sessionId) et reconstruire l’état à partir du journal. Le time-to-first-token diminue d’environ 60 % au p50 et de plus de 90 % au p95 — car le raisonnement peut commencer avant même que la sandbox soit prête
• Le concept de journal d’événements de session est probablement la partie la plus sous-estimée. C’est lui qui rend un agent à longue exécution récupérable. Sans cela, une panne de conteneur devient immédiatement une panne de session
• Pour le calcul scientifique, la pile comprend : CLAUDE.md (plan vivant que l’agent apprend et modifie), CHANGELOG.md (notes de laboratoire portables), tmux + SLURM + git (couche d’exécution et de coordination), et la boucle Ralph (pour revérifier les affirmations d’achèvement)
  • Exemple représentatif : un solveur de Boltzmann construit par Claude Opus sur plusieurs jours a atteint moins de 1 % d’écart avec l’implémentation de référence CLASS, condensant plusieurs mois voire années de travail de recherche

Cursor : structure Planner, Worker, Judge

• Cursor a traversé trois itérations de conception pour étendre le codage autonome de longue durée
  • Première itération (coordination plate) : des agents au même niveau écrivent dans des fichiers partagés avec des verrous → apparition de goulets d’étranglement et d’un comportement d’évitement du risque produisant du churning (répétitions sans commit)
  • Deuxième itération (contrôle de concurrence optimiste) : le goulot a été résolu, mais les problèmes de coordination non
  • Troisième itération (production actuelle) : Planner (exploration du codebase et création de tâches, avec possibilité de lancer récursivement des sous-planners), Worker (exécution concentrée sur des tâches indépendantes sans coordination mutuelle), Judge (détermine la fin d’une itération et décide d’un redémarrage)
• Découverte majeure : « une part étonnamment importante du comportement du système dépend davantage du prompt que du harness ou du modèle »
• L’association modèle-rôle fait partie de la surface de conception : les modèles GPT surpassent Opus sur les travaux autonomes de longue durée. Opus a tendance à s’arrêter trop tôt et à prendre des raccourcis. Même tâche, rôles différents, modèles différents
• Composer 2 (modèle frontier de codage maison) et les agents cloud en arrière-plan : les tâches longues ne s’exécutent plus en local mais dans l’infrastructure cloud d’Anysphere. Des refactorings de 8 heures et des migrations à l’échelle du codebase entier continuent même si le laptop est fermé
  • Le travail peut démarrer en local puis basculer vers le cloud s’il est estimé à plus de 30 minutes, avec reprise possible ensuite depuis le mobile
  • Chaque agent fonctionne dans un git worktree isolé, puis fusionne via PR
• La structure finale ressemble à celle d’Anthropic : séparation des rôles, persistance de session, juge placé à côté du worker, tâches longues pilotées dans des sandboxes cloud avec coordination basée sur git

Google : les agents à longue exécution sur l’Agent Platform

• Lors de Cloud Next '26, Google a intégré Vertex AI dans la Gemini Enterprise Agent Platform, transformant les agents à longue exécution en produit officiel avec SLA explicites
• Agent Runtime : prise en charge d’une « exécution autonome pendant plusieurs jours », avec cold start sub-second et provisioning de sandboxes à la demande. Cas d’usage cité : une séquence de prospection commerciale qui prend une semaine
• Agent Sessions : persistance de l’historique conversationnel et événementiel. Un identifiant de session personnalisé peut être mappé à un enregistrement CRM ou base de données pour stocker l’état de l’agent avec l’état métier
• Agent Memory Bank : couche de mémoire longue durée passée en GA à la date de Next '26. Elle permet de curer la mémoire depuis les sessions, de la scoper par identifiant utilisateur et fournit une API de recherche. Dans le cas de Payhawk, un agent fondé sur Memory Bank a réduit de plus de 50 % le temps de soumission des notes de frais
• Agent Sandbox (exécution de code renforcée), Agent-to-Agent Orchestration, Agent Registry, Agent Identity, Agent Gateway, Agent Observability, Agent Simulation, etc. couvrent presque tous les sujets nécessaires à l’exploitation en production. Les identifiants chiffrés et journaux d’audit requis en entreprise sont inclus
• Sur le plan architectural, c’est la même structure que la séparation brain/hands/session d’Anthropic, mais industrialisée à l’échelle d’une plateforme, avec ADK (kit de développement code-first) et Agent Studio (outil visuel) fournis ensemble. Là où il fallait tout construire soi-même il y a trois ans, il s’agit désormais de choisir « quelle version de la séparation brain/hands/session emprunter »

Cinq motifs pour des agents à longue exécution en production

• Checkpoint-and-resume : l’échec multi-jours le plus courant est la perte de contexte. Si une erreur survient au 201e document après en avoir traité 200, l’absence de checkpoint impose de repartir de zéro. Il faut traiter l’agent comme un processus serveur longue durée : persistance de l’état intermédiaire sur disque, checkpoint tous les N travaux, reprise après incident. Le point clé est de déterminer la bonne granularité de checkpoint — ni à chaque étape, ni seulement à la fin
• Delegated approval(human-in-the-loop) : les implémentations classiques sérialisent l’état en JSON → webhook → attente de réponse, mais cela entraîne un état stale et des notifications perdues. Dans un runtime longue durée, l’agent peut se mettre en pause tout en conservant sa chaîne de raisonnement, sa mémoire de travail, son historique d’outils et l’ensemble des actions en attente. Pendant la revue humaine, consommation de calcul nulle, puis reprise avec une latence sub-second. Mission Control de Google sert de boîte de réception pour cela
• Memory-layered context : un agent qui tourne 7 jours a besoin de plus qu’un état de session. Memory Bank (mémoire curée de long terme) + Memory Profiles (consultation à faible latence). Le mode d’échec en production est la memory drift — l’agent apprend des raccourcis procéduraux à partir d’interactions non structurées et les applique trop largement. Il faut donc gouverner la mémoire comme un microservice. Agent Identity (droits de lecture/écriture), Agent Registry (suivi des versions d’agent), Agent Gateway (application des politiques)
• Ambient processing : des agents qui ne dialoguent pas avec un humain mais réagissent à des événements provenant de flux Pub/Sub ou de tables BigQuery (modération de contenu, détection d’anomalies, tri de boîte de réception). En définissant les politiques dans le Gateway plutôt que dans le code de l’agent, on peut appliquer un changement de politique à des centaines d’agents sans redéploiement
• Fleet orchestration : dans les systèmes réels, il n’y a pas un agent unique mais un coordinateur qui délègue des sous-tâches à des spécialistes (Lead Researcher Agent, Scoring Agent, Outreach Agent). Chaque spécialiste possède sa propre Identity (par exemple, Outreach Agent ne peut pas accéder aux données financières utilisées pour le scoring), ses propres politiques et sa propre entrée dans le Registry. ADK traite cela de manière déclarative comme un workflow basé sur un graphe
• Ces motifs sont combinables. Exemple pour un système de conformité : checkpointing pour le traitement documentaire + delegated approval aux points de revue + memory layering pour la connaissance inter-session + fleet orchestration pour coordonner les spécialistes

Comment construire cela en pratique

• Pour les développeurs qui veulent des tâches de codage longues sur leur propre repo : utiliser Claude Code, Antigravity, Cursor, Codex, etc. Gérer AGENTS.md comme une checklist de pilote (courte, uniquement issue d’échecs réellement observés). Ajouter des hooks de typecheck et lint, écrire un fichier de plan avant de démarrer, puis revérifier via la boucle Ralph quand l’agent affirme avoir terminé. Pour les travaux de plusieurs heures ou de nuit, exécuter dans un worktree afin que cela continue même laptop fermé, et commit à chaque unité de travail significative. C’est la voie au plus fort levier pour la plupart des gens
• Pour construire un produit d’agents hébergés : ne pas construire soi-même le runtime ; choisir une solution managée. Les trois options réellement crédibles aujourd’hui : Google Agent Platform (Agent Engine + Memory Bank + Sessions), Claude Managed Agents, ou un hébergement maison au-dessus d’ADK, du Claude Agent SDK ou du Codex SDK. Le managé fournit par défaut la séparation brain/hands/session, l’observabilité, l’identité et les traces d’audit. L’auto-hébergement offre davantage de contrôle et l’accès à des modèles spécialisés
• Pour des tâches autonomes ou opérationnelles (monitoring, recherche, opérations) : une persistance de type Memory Bank est nécessaire. ADK + Memory Bank + Cloud Run + Cloud Scheduler forment la pile la plus propre pour « exécuter un agent toutes les N heures, accumuler l’état et alerter à un seuil »

Les pratiques essentielles, quel que soit le chemin choisi

• Formaliser les critères d’achèvement avant de lancer l’agent : c’est le levier le plus puissant sur les longues exécutions. Écrire dans un fichier externe des critères explicites et testables empêche l’agent de redéfinir en cours de route ce que signifie « terminé »
• Séparer l’évaluateur du générateur : l’auto-notation est un mode d’échec central. Un pipeline planner/worker/judge ou une paire generator/evaluator n’est pas une simple préférence de style, mais un véritable motif architectural. Même modèle possible, mais rôles et prompts distincts
• Investir dans les journaux de session plutôt que dans le prompt : un journal d’événements append-only rend l’agent récupérable, déboguable et auditable. Si l’on ne peut pas reconstruire à partir d’un stockage persistant les 24 dernières heures d’activité d’un agent, ce n’est qu’un script shell longue durée qui appelle un LLM
• Traiter la compression et les resets de contexte comme des citoyens de première classe : Anthropic a constaté que, sur des tâches très longues, la compression fondée sur le résumé était insuffisante ; le harness doit parfois démonter entièrement la session puis la reconstruire depuis un fichier de handoff structuré. En pratique, cela revient à onboarder un nouvel ingénieur

Les limites réelles aujourd’hui

• Coût : faire tourner un modèle frontier pendant 24 heures coûte cher. Sans budget, coupe-circuit ni plafond strict sur les dépenses d’outils, une demi-journée peut suffire à brûler un budget API hebdomadaire
• Sécurité : un agent à longue exécution disposant de clés API, d’accès cloud et de droits d’exécuter des commandes shell présente une surface d’attaque bien plus large qu’une session de chat. Le motif brain/hands est donc crucial — le code généré par le modèle doit s’exécuter dans une sandbox sans accès aux credentials
• Alignment drift : au fil de plusieurs fenêtres de contexte, l’agent dérive. L’objectif initial est résumé, puis rerésumé, avec perte de fidélité. Les hooks et le judge servent précisément à s’en prémunir, et c’est la cause la plus fréquente des situations où l’agent réalise un travail non demandé
• Vérification : auditer 24 heures d’activité autonome reste un vrai problème de temps humain. L’observabilité et les sorties structurées (PR, commits, briefings, exécutions de tests) sont ce qui rend cette tâche tractable
• Rôle humain : définir un travail avec assez de précision pour qu’un agent puisse l’exécuter pendant une journée est plus difficile que le faire soi-même. La compétence qui prend de la valeur n’est plus l’écriture de code, mais la rédaction de spécifications capables de survivre au contact avec un exécuteur autonome

Direction future

• Google, Anthropic et Cursor convergent tous vers la même structure : séparation entre boucle du modèle, sandbox d’exécution et journal de session, séparation entre planification, génération et évaluation, avec compression, hooks et resets de contexte intégrés, et exposition de la mémoire comme service managé
• Les différences sont surtout de surface : Google Agent Platform est une pile entreprise (identité et audit intégrés), Claude Managed Agents est en pratique « la version hébergée du harness d’Anthropic », et les agents en arrière-plan de Cursor sont « du codage longue durée déplacé de l’IDE vers le cloud »
• Le problème le plus difficile de l’année à venir ne concernera pas chaque couche prise isolément, mais la coordination au-dessus : faire tourner de multiples agents longue durée sur un codebase partagé, des agents capables de lire leurs propres traces et de patcher leur propre harness, et des harness assemblant outils et contexte en JIT (just-in-time) selon la tâche
• Le modèle reste central, mais l’écart entre une fenêtre de chat et un agent capable de tourner toute la nuit se situe surtout dans l’état, la session et le handoff structuré ; c’est donc là qu’il faut investir du temps d’apprentissage aujourd’hui

[jjpark78]

J’ai commencé à utiliser hermes pour essayer de résoudre ce problème, et ça ne m’a pas l’air mal du tout haha