AgentLoop

AgentLoop démarre un nouveau processus de moteur pour chaque worker et chaque session de critique, donc aucun historique de chat antérieur ne les suit. Cela évite la pourriture du contexte, l'accumulation d'hypothèses périmées qui rend les longs échanges peu fiables. La mémoire durable, c'est le projet lui-même plus les correctifs concrets qu'écrit le critique, ce qui évite de brûler des tokens à relire une conversation qui ne cesse de grandir.

Vous placez votre définition de « terminé » dans GUIDELINES.md. Un critique neuf lit ce fichier à chaque cycle avec la sortie du worker et les fichiers du projet. La dernière ligne du critique est un contrat strict : elle doit se terminer par PASS, FAIL avec notes de correction, ou CONTINUE. Un FAIL devient des instructions injectées pour le worker suivant, donc le retour se transforme en action plutôt qu'en un commentaire que vous devez relayer à la main. Dans l'évaluation du projet lui-même, un critique neuf a trouvé un défaut de décodage en pourcentage mixte alors que les neuf tests étaient déjà passés.

Le progrès vit dans PLAN.md et STATE.md, pas dans une conversation. Un worker lit le plan et l'état, fait un incrément, met à jour l'état et sort. Comme la mémoire est dans des fichiers, la boucle reste délimitée et plus facile à laisser sans surveillance. Cela veut aussi dire que vous pouvez lire les mêmes artefacts que les agents et voir exactement ce qui a changé à chaque étape.

Chaque cycle, verdict, transcription, coût et remise de fichier apparaît sur un tableau de bord local. Vous pouvez annuler une exécution depuis là plutôt que de traquer un processus, et vous pouvez demander l'état à ChatGPT via un pont MCP. Aucune conjecture. Pour qui a déjà tenté de déboguer une exécution d'agent sans surveillance après coup, avoir la chronologie enregistrée fait la différence entre corriger un problème et deviner ce qui s'est passé.

AgentLoop fait tourner le CLI Codex et Claude Code comme moteurs interchangeables. Vous en choisissez un par boucle depuis le tableau de bord, ou par tâche via le pont. Le projet garde la planification séparée de l'exécution locale, et la feuille de route vise ensuite les questions d'agent bidirectionnelles et les boucles de recherche.

Pour les projets dans un arbre de travail git, le point de contrôle automatique est activé par défaut, donc le démon peut committer le progrès au fil des cycles. Les échecs soudains, comme une tâche bloquée qui atteint sa limite de tentatives, n'effacent pas le travail déjà fait. La récupération est à une commande git, pas à un après-midi perdu. Cela compte pour les exécutions nocturnes.

Une boucle est volontairement séquentielle. Des tâches indépendantes empilées peuvent tourner jusqu'à une limite de concurrence, mais une boucle ne se transforme jamais en essaim parallèle qui court partout sur le même projet. C'est délibéré. Les budgets sont plafonnés aussi. maxCycles va de 1 à 50 et vaut 3 par défaut, et taskRetries plafonne les échecs consécutifs avant qu'une tâche soit marquée bloquée et ignorée.