Concevoir des agents capables de tenir sur plusieurs jours

Le problème n’est pas seulement la taille du contexte

Un agent de langage peut aujourd’hui enchaîner plusieurs appels, utiliser des outils et produire un résultat utile en quelques minutes. Le problème change de nature lorsqu’on lui demande de suivre une remédiation opérationnelle, une enquête de conformité ou un programme de recherche pendant plusieurs jours. Le travail dépasse alors la fenêtre de contexte, la durée de vie d’un processus et l’intervalle pendant lequel une personne peut rester attentive.

Le preprint An Architecture for Long-Horizon Agents: Levels, Ticks and Cascaded Intelligence part de cette situation. Sa thèse est précise : avant de parler d’apprentissage continu, il faut donner à l’agent une opération continue qui ne perde pas son état lorsque le contexte ou la session se termine. Cette propriété appartient principalement au harness, c’est-à-dire à l’ensemble qui décide quand le modèle se réveille, quelles informations il lit, ce qu’il peut faire et comment il rend son état durable.

Cette distinction évite une réponse trop simple au problème. Une fenêtre plus longue repousse une limite, mais ne supprime pas la fin du projet. Une nouvelle session peut encore oublier une contrainte. Une synthèse peut effacer la preuve d’une décision. Un modèle plus puissant peut aussi coûter trop cher s’il est utilisé à chaque étape. L’article propose donc une architecture temporelle et des protocoles de reprise plutôt qu’une simple augmentation de capacité du modèle.

Sept goulots d’étranglement

Les auteurs décrivent le problème avec deux axes : l’autonomie, qui mesure la part de l’initiative et du contrôle prise par l’agent, et l’horizon, qui mesure la longueur de la trajectoire en actions, en tokens ou en temps réel. Lorsque les deux augmentent, sept difficultés apparaissent.

Quatre viennent des seuils franchis par une campagne longue. L’agent doit continuer à agir quand l’attention humaine n’est plus immédiate. Il doit survivre à la fin d’une fenêtre de contexte. Il doit reprendre après la fin d’un processus ou d’une session. Il doit aussi résister aux défaillances d’un composant. Une campagne suffisamment longue rencontre nécessairement ces seuils : le fichier qui contenait l’objectif n’est plus dans la fenêtre, le conteneur redémarre, le service externe tombe ou la personne responsable ne répond que le lendemain.

Deux autres difficultés combinent autonomie et horizon. La correction devient plus délicate parce que personne ne vérifie chaque étape et que les erreurs peuvent se composer. Le coût augmente également : si chaque unité de travail est confiée au modèle le plus cher, le budget limite rapidement la durée de la campagne. Enfin, la délégation apparaît lorsque le travail dépasse la capacité d’un seul processus et doit être transmis entre niveaux ou travailleurs.

Cette grille est utile parce qu’elle transforme une demande vague — « faire durer l’agent » — en propriétés observables : reprise, état borné, déclenchement, vérification, résilience, délégation et coût. Elle indique aussi où chercher une panne. Une perte d’objectif après redémarrage relève de l’état et de la reprise ; une escalade trop fréquente relève de la vérification ou du contrôle du coût.

Les quatre abstractions de l’architecture

La première abstraction est le level, ou niveau. Chaque niveau agit à une échelle temporelle donnée, conserve un état borné qui résume le niveau inférieur et lui envoie des directives peu fréquentes. L’article décrit sept niveaux, du simple appel d’outil à l’objectif hebdomadaire. Les appels d’outils et le travail routinier vivent aux échelles courtes ; les décisions, les revues et l’intervention humaine vivent à des échelles plus longues.

Le deuxième élément est le tick. Un tick est une unité d’action autonome : le driver se réveille, lit l’état disponible, applique les règles déjà enregistrées, décide, agit puis réécrit l’état. Le tick ne doit pas se terminer avant que l’état de son niveau et le checkpoint soient sauvegardés. Cette règle donne une frontière nette à la reprise. Si le processus disparaît ensuite, la prochaine session ne repart pas d’un souvenir implicite, mais d’un état durable.

Le troisième élément est le protocole. Un canal ou un fichier d’état n’est pas traité comme un espace partagé sans responsable. Il possède un écrivain, un lecteur, une cadence et un contrôle. Cette formalisation rend les échanges entre niveaux vérifiables. Les directives descendent ; l’état compressé, les escalades et les éléments nécessitant une attention remontent. Les verdicts d’arrêt sont traités comme des messages qui ne doivent pas être cachés par la compression.

Le quatrième élément est la cascade d’intelligence. L’architecture distingue le jugement, le travail et les processus déterministes. Une tâche peut commencer à un niveau ou avec un modèle moins coûteux, puis être escaladée vers une capacité supérieure si une revue échoue. L’escalade n’est donc pas une préférence permanente pour le modèle le plus capable ; elle devient une décision contrôlée par le résultat d’une vérification.

Une mémoire hiérarchique et bornée

La mémoire proposée n’est pas un journal illimité que le modèle relirait à chaque réveil. Chaque niveau conserve un fichier borné qui résume le niveau inférieur. Le niveau supérieur agit à sa propre cadence et formule des directives qui peuvent être lues sans parcourir les sorties brutes. Cette compression est une contrainte d’architecture, pas seulement une optimisation de prompt.

Le bénéfice attendu est double. D’une part, une campagne peut franchir la limite de contexte sans perdre entièrement son fil. D’autre part, la lecture devient proportionnée à l’horizon : le driver n’a pas besoin de charger toutes les traces d’outils pour savoir quel est le prochain essai et quelle condition d’arrêt s’applique. La contrepartie est évidente : toute compression peut supprimer une information. C’est pourquoi l’article réserve une place explicite aux checkpoints, aux journaux, aux rapports d’escalade et aux décisions persistantes.

Cette idée fournit une règle de conception plus exigeante qu’un simple stockage de messages. Une mémoire utile doit avoir un format, un propriétaire, une cadence de mise à jour et un lecteur attendu. Elle doit permettre à une nouvelle session de reprendre l’action, mais aussi à un niveau supérieur de vérifier ce qui s’est passé. Une synthèse qui ne permet ni reprise ni contrôle est seulement une réduction de texte.

Ce que montre la campagne de dix jours

L’expérience rapportée dure dix jours. Un agent construit avec cette architecture reproduit un résultat publié en apprentissage par renforcement, avec une personne qui intervient environ une fois par jour. Les auteurs indiquent que la campagne a franchi chaque réinitialisation de contexte et chaque frontière de session. Le travail a dépassé deux cents ticks et a donné lieu à environ deux douzaines d’escalades vers l’humain.

Trois observations sont mises en avant. Premièrement, le fil de travail a été conservé malgré les resets et les changements de session. Deuxièmement, des connaissances opératoires écrites au début de la campagne ont modifié le comportement ultérieur sans modification des poids du modèle. Il s’agit d’un apprentissage au niveau du système et de ses artefacts durables, pas d’un nouvel entraînement du modèle. Troisièmement, l’expérience rend visibles les endroits où des composants appris pourraient être introduits plus tard, notamment dans les contrôles déjà réalisés par le harness.

Ces résultats ne constituent pas une mesure générale de fiabilité. Ils montrent plutôt qu’une architecture peut rendre une campagne longue exécutable et observable. La réussite de la reproduction est un exemple d’usage ; elle ne prouve pas que la même organisation fonctionnerait sans adaptation pour une enquête réglementaire ou une intervention sur une infrastructure critique.

Vérification et escalade

Un agent autonome ne peut pas simplement produire des actions jusqu’à l’épuisement du budget. Il doit savoir ce qui a été contrôlé et à quel niveau. Dans l’architecture décrite, chaque niveau vérifie le niveau inférieur et remonte les éléments qui ne peuvent pas être compressés sans risque. La revue devient ainsi une partie du rythme de l’agent, au même titre que l’action.

La cascade propose une manière de contenir le coût : les tâches ordinaires restent dans un tier de travail, tandis qu’un échec de revue peut déclencher un jugement plus capable. Mais cette stratégie dépend de la qualité de la revue. Si le contrôle accepte une sortie incorrecte, l’économie de calcul masque une erreur ; s’il escalade tout, le système perd son avantage économique et sa capacité à fonctionner sans attention constante.

Pour un système réel, il faut donc définir les critères d’escalade avant la campagne : état incohérent, absence de progrès, dépassement d’un budget d’essais, contradiction avec une contrainte ou résultat impossible à vérifier. Ces critères ne sont pas fournis comme une recette universelle par le preprint ; ils découlent de la nécessité de rendre la cascade explicable.

Ce que l’étude ne prouve pas

Le document rapporte une expérience longue, mais pas une comparaison exhaustive avec d’autres architectures, modèles, budgets ou domaines. La campagne de dix jours ne suffit pas à estimer une probabilité générale d’échec. La conservation d’un état ne garantit pas que cet état soit correct, complet ou correctement interprété par la session suivante.

La compression hiérarchique crée également un risque de perte d’information. Les contrôles, les fichiers bornés et les protocoles réduisent ce risque sans l’annuler. De même, une escalade vers un humain une fois par jour peut être acceptable pour une campagne de recherche et insuffisante pour une action urgente. Le bon intervalle dépend du domaine, du coût de l’erreur et de la possibilité d’arrêter le système.

Enfin, il s’agit d’un preprint ArXiv. Les résultats doivent être lus comme une proposition d’architecture accompagnée d’une expérience, et non comme une validation indépendante ou une garantie de sûreté. L’intérêt du texte est surtout de nommer les obligations que les systèmes d’agents longs ont tendance à laisser implicites.

Une grille pour concevoir un harness

Avant de lancer une campagne, on peut reprendre la grille proposée sous forme de questions. Quel état doit survivre à un reset ? Quel fichier permet à une nouvelle session de reprendre sans relire toutes les traces ? Quelle cadence réveille le driver ? Quel niveau vérifie le travail inférieur ? Que se passe-t-il si un outil échoue ? Quand une tâche est-elle déléguée ? Quel événement déclenche une escalade ? Quel budget borne l’usage du tier le plus coûteux ?

Ces questions déplacent la discussion du modèle vers le système complet. Elles rendent aussi les tests plus précis. Un test de reprise peut interrompre le processus entre deux ticks et vérifier que la session suivante retrouve l’objectif, le dernier état et la prochaine action. Un test de protocole peut vérifier qu’un fichier possède bien un écrivain et qu’un lecteur reçoit un format compatible. Un test de cascade peut injecter un échec de revue et observer si l’escalade est déclenchée sans boucle infinie.

L’architecture Levels, Ticks and Cascaded Intelligence propose finalement une idée simple mais structurante : un agent qui doit durer plus longtemps que son contexte a besoin d’un substrat qui dure plus longtemps que son processus. Ce substrat n’est pas un détail d’intégration. Il porte la mémoire, les horaires, la reprise, les contrôles, les escalades et les limites de coût. C’est à cette condition qu’un agent peut continuer à agir lorsque l’attention humaine et la fenêtre de contexte se sont retirées.

Sources

Erik Nijkamp, Anurag Koul, Egor Pakhomov et Bo Pang, « An Architecture for Long-Horizon Agents: Levels, Ticks and Cascaded Intelligence », ArXiv 2609.19519v1, consulté le 21 septembre 2026 : résumé et preprint, PDF.