En juillet, un moniteur est resté muet pendant six jours, un ticket n'a jamais retenté son exécution et un autre a lancé 70 agents en trois heures et demie. Le tableau Kanban paraissait pourtant cohérent dans les trois cas.

Ce digest adapte pour Ekioo le retour d'expérience publié initialement sur DEV. Il ne cherche pas à refaire l'inventaire général des pannes d'agents IA en production. Il se concentre sur une question plus précise : comment distinguer un état plausible d'un travail réellement accompli ?

Le silence doit devenir un signal

Le premier incident partait d'une promesse simple : surveiller les canaux qui cessent de publier, pas seulement les scripts qui renvoient une erreur. La réalisation a pris seize jours avant même de devenir un ticket. Pendant ce délai, un ancien contrôle de santé Brevo a cessé d'écrire son journal du 22 au 28 juillet.

Le script échouait avant d'enregistrer son résultat, car Cloudflare rejetait le user-agent par défaut de urllib. L'automatisation tolérait cet échec. Le moniteur avait donc disparu dans le silence qu'il devait détecter.

Le correctif a ajouté deux sorties distinctes :

  • le résultat du contrôle métier ;
  • une preuve horodatée que le contrôle fonctionne encore.

Le nouveau watchdog vérifie sept canaux avec des seuils explicites et surveille aussi l'âge du journal Brevo. Son test de bout en bout a utilisé un canal fictif volontairement périmé pour confirmer le chemin d'alerte.

La leçon est plus large que ce script : un timestamp de dernière réussite qui peut vieillir sans alerte décrit un tableau de bord, pas un watchdog.

Zéro retry et 69 retries sont le même défaut

Le 27 juillet, un ticket est entré dans SecurityCheck. L'agent a démarré, rencontré une limite de dépense, puis quitté. Le déclencheur statusChange avait déjà considéré la transition comme consommée. Pendant seize heures, le ticket est resté dans la bonne colonne sans nouvelle tentative.

Le correctif de KittyClaw retarde désormais la validation de l'événement : un dispatch échoué ou arrêté reste retentable, un run réussi avance l'instantané. La suite principale de 689 tests a validé ce comportement.

Le lendemain, l'incident inverse s'est produit. Un ticket rétrospectif a démarré 70 agents en environ trois heures et demie, dont 69 ont échoué. Le déclencheur ticketInColumn, fondé sur un état persistant, retrouvait le même travail à chaque passage. Aucun plafond, délai progressif ou signal terminal n'interrompait la boucle.

Ces deux défauts viennent de la même omission : la politique de retry n'était pas définie comme un état observable. Il faut préciser l'unité retentée, le moment où une tentative est consommée, l'événement qui remet le compteur à zéro, la progression du délai et la sortie visible lorsque le budget est épuisé.

Un prompt n'est pas une preuve d'événement

La boucle de 70 départs contenait un symptôme encore plus révélateur. Environ quarante exécutions ont reçu un prompt annonçant un retour du propriétaire alors que le ticket ne contenait aucun commentaire.

Le garde-fou côté agent a limité les dégâts : relire le ticket via l'interface de programmation applicative (API), compter les commentaires correspondants, puis ne rien faire lorsque le fait annoncé n'existe pas. Cela évite une action erronée, mais pas le coût du processus lancé pour découvrir que sa prémisse était fausse.

Dans KittyClaw, le texte d'un déclencheur doit donc rester une invitation à vérifier. L'autorité appartient au ticket et à son historique. À terme, chaque dispatch doit porter un identifiant d'événement stable, lié à la bonne session et à un état de consommation persistant.

Ce que KittyClaw rend explicite

Ces incidents ont fait évoluer KittyClaw moins par de meilleurs prompts que par des contrats plus nets entre le moteur et les agents :

  • une transition n'est consommée qu'après un dispatch réussi ;
  • l'agent revalide le fait sous-jacent avant d'agir ;
  • les boucles doivent exposer leur nombre de tentatives et leur condition de sortie ;
  • la surveillance produit aussi une preuve de sa propre fraîcheur.

Le projet est open source sur GitHub. Ce type de retour terrain guide directement notre manière de concevoir les automatisations chez Ekioo : l'état affiché ne suffit jamais, il faut pouvoir reconstruire pourquoi le système croit que le travail est terminé, retentable ou bloqué.

Un autre incident de juillet l'a montré sur un terrain plus éditorial. Le publisher de Bloomii appliquait un délai glissant de 24 heures à une exigence formulée en jours calendaires. Quelques minutes de dérive à chaque passage risquaient de supprimer une journée de publication. Le correctif a comparé des dates de Paris, parce qu'une règle de calendrier doit stocker un état de calendrier.

Le principe à retenir

Les systèmes d'agents héritent des problèmes classiques des systèmes distribués : livraison au plus une fois, retries non bornés, événements dupliqués, horloges et états concurrents. Ils ajoutent un risque particulier : un agent peut raconter avec assurance un état périmé ou faux.

La réponse de juillet n'a pas été d'écrire un prompt plus convaincant. Elle a consisté à désigner une source de vérité, vérifier cette source à la frontière de chaque exécution et rendre l'échec visible avant que l'état final ne l'efface.

Version adaptée de l'article original publié sur DEV.