agent-loop

Problème résolu

Lancer un agent de code à la main fonctionne, jusqu'au jour où l'on veut qu'il tourne à quatre heures du matin. Toutes les questions qu'on n'avait jamais eu à trancher deviennent alors bloquantes : sur quel compte lancer ce travail, que se passe-t-il quand ce compte atteint sa limite de cinq heures en cours de route, comment savoir si l'agent travaille ou s'il attend depuis une heure une réponse que personne ne lui donnera, et qui nettoie le worktree quand il termine à 03h38 plutôt qu'à l'heure pile. Cron sait démarrer des choses. Il ne sait ni décider, ni surveiller, ni ranger, et un agent que personne ne regarde a besoin des trois.

Proposition de valeur

Une seule ligne de cron pour toute la machine. Les jobs sont des dossiers versionnés à côté du service qu'ils pilotent : ajouter un job est une pull request, pas une modification de crontab. Un routeur conscient des quotas choisit le compte qui a le plus de marge, met de côté la réserve déclarée par chaque compte pour que les humains qui le partagent continuent de travailler, et s'arrête à un plafond quotidien de lancements. Chaque worker reçoit son propre worktree git et son propre panneau de terminal. Les labels sur l'issue ou la pull request font office de machine à états : la mémoire de la boucle survit à un redémarrage et reste lisible dans l'interface GitHub. Trois types de jobs sont fournis : un builder qui transforme les issues en pull requests, un reviewer qui les relit depuis un compte différent de celui qui les a écrites, et une routine qui tourne à heure fixe. Quand un worker est réellement bloqué et attend un humain, vous recevez une notification. C'est la seule chose pour laquelle la boucle vous dérangera.

Public cible

Les développeurs et les petites équipes qui utilisent déjà Claude Code ou Codex à la main et veulent que le même travail se fasse pendant la nuit, tout en partageant leurs comptes fournisseurs avec d'autres personnes : « laisse tourner » doit alors vouloir dire « sans vider le compte dont tout le monde a besoin le lendemain matin ».

Stack technique

• TypeScript sur Bun, zéro dépendance à l'exécution, 418 tests sans réseau ni appel à la forge
• herdr pour les panneaux de terminal dans lesquels vivent les agents, et pour le seul signal qui dit si un worker travaille, est bloqué, ou a disparu
• Un worktree git et une branche par worker, donc deux jobs simultanés ne partagent jamais un checkout
• Les labels GitHub comme machine à états, via gh
• Un mode à blanc qui effectue toutes les lectures, refuse toutes les écritures au niveau du garde-fou de commandes, et ne persiste rien
• GitHub Actions pour la CI, release-please pour le versionnage piloté par les conventional commits, publication npm avec provenance

Statut

En ligne, sous licence MIT, publié sous @tonoid/agent-loop. Code généré avec Claude Code, puis testé et relu manuellement, et déjà en production sur nos propres chaînes de contenu et de digest. Il dépend de herdr, et ce n'est pas accessoire : chaque worker est un agent herdr, il n'existe pas d'autre manière d'en lancer un. GitHub uniquement, les labels servant de machine à états. Les workers tournent sans bac à sable et sans demande de permission, ce qui les rend autonomes et justifie de donner à la boucle son propre compte. Ouvert aux issues et aux PR.