Il y a 3 semaines, dans mon premier Show GN, j’avais partagé que je construisais un firewall à 5 niveaux. Entre-temps, j’ai corrigé la conception + partagé ce qui a réellement été mis en prod. C’était passé inaperçu avec 1 point / 1 commentaire, mais il y a eu des avancées, donc je retente.
▶ Correction 5 niveaux → 4 niveaux (PUSH / QUEUE / SILENT / AUTO)
Le niveau "Call" a été retiré et mis en attente. Décision prise à partir des données collectées pendant la PoC.
▶ Boucle agent end-to-end terminée
Un e-mail de demande de réunion arrive → classification par niveau → Klorn vérifie les conflits de calendrier → réponse + brouillon d’événement calendrier → attente dans PendingAction → approbation utilisateur en 1 clic → envoi. Toutes les actions sont signées avec un hash de payload avant l’envoi, et sans correspondance ActionReceipt, exécution impossible.
▶ La partie la plus longue : le test d’invariant (moins de 100 lignes de code)
Un test qui casse le build si une action comme send_email est exécutée sans approbation utilisateur. Si quelqu’un supprime la vérification d’approbation → échec du test → échec du build → échec du déploiement. Le contournement lui-même n’est pas une option. C’est pour ça que « l’agent n’envoie rien tout seul » n’est pas un slogan marketing, mais un fait.
▶ J’ai aussi corrigé un vrai bug en prod
OpenRouter a retiré le SKU de modèle :free, donc tous les cycles autonomes mouraient avec 404 No endpoints found. Le failover existant ne gérait que 402 / 403 / 429. Il ne savait pas gérer le cas « le modèle a disparu ». J’ai mis en place une chaîne de fallback multi-modèles, donc même si un SKU upstream tombe, l’agent ne tombe pas.
▶ Mesure en cours de la rétention Day 14+7
L’activation de 5 ICP est le critère de passage de la PoC. Un retour honnête, même en une ligne, est le bienvenu.
▶ Vidéo de 60 secondes : https://klorn.ai
▶ Code : https://github.com/k08200/klorn
Bêta gratuite + PRO appliqué automatiquement. Merci sincèrement à ceux qui avaient donné leur avis sur le premier post.
3 commentaires
Une question — pour ceux qui exploitent des agents / du SaaS, quel est le mode d’échec que vous avez le plus souvent observé quand l’agent agit sans intention de l’utilisateur ?
De mon côté, par ordre de fréquence observé en exploitation :
Je suis curieux de connaître les schémas que vous avez vus de votre côté.
Le cas n°2 arrivait souvent, et quand on basculait sur cette alternative, le cas n°1 se produisait selon le prompt, ce qui entraînait ensuite le cas n°3 mdr
Bien sûr, ça n’arriverait pas si on utilisait toujours un modèle haut de gamme, mais pour un service destiné aux clients, du niveau Sonnet ou au-dessus, ça reste difficile à assumer ..
Haha, je compatis totalement avec cet enchaînement. Moi aussi, c’est à cause du point n°2 que je me suis le plus fait avoir, et quand on bascule sur du gratuit, le prompt ne colle plus et on se retrouve avec le problème n°1 : j’ai vécu exactement la même chose.
Du coup, à un moment, j’ai arrêté d’essayer de faire confiance au modèle et, à la place, peu importe qu’il soit bon marché, cher ou retiré, je l’empêche de décider tout seul pour tout ce qui consiste à envoyer un mail, supprimer quelque chose ou transférer vers l’extérieur. Pour ça, validation humaine obligatoire avant sortie. Ce qui tourne en automatique, ce sont uniquement des choses réversibles comme la classification, le marquage comme lu ou les briefings.
En procédant comme ça, même si le modèle dérive, le pire cas devient « une proposition bizarre que je vois et que je refuse », pas « une réponse déjà partie ». Le point n°1 ne se propage pas jusqu’au point n°3.
Pour le point n°2, je détecte les SKU free qui renvoient des 404 avec une vérification quotidienne du catalogue et je contourne ça avec une chaîne de fallback, mais j’ai gardé uniquement le classifieur sur une offre flash payante. Utiliser du niveau Sonnet à grande échelle, pour du B2C, c’est aussi trop lourd pour moi… Donc je ne paie que pour la classification, je laisse la génération de propositions en gratuit, et c’est la gate d’approbation qui absorbe le risque.
Au final, je pense que l’essentiel, c’était de ne pas placer le coût et la sécurité sur le même axe. Le modèle peut être bon marché, mais la gate, elle, ne doit pas l’être.