Un agent personnel toujours actif ne devrait pas se comporter comme un fil de notifications mieux rédigé. Son rôle n’est pas de réagir visiblement à chaque nouvel e-mail, ticket, changement de prix, modification de document ou mise à jour d’agenda. Son rôle est de surveiller pendant que vous êtes occupé ailleurs, de reconnaître la petite part des changements qui modifient ce qui doit se passer ensuite, et de remettre le bon travail au premier plan au bon moment et au bon niveau.
« Quand l’agent doit-il se réveiller ? » est donc une question de conception, pas seulement de performance. S’il se réveille trop souvent, l’agent devient une source de bruit de plus. S’il se tait trop systématiquement, il passe à côté de la raison même pour laquelle vous lui avez demandé de surveiller. S’il agit sans limite claire, un système d’arrière-plan utile devient un problème d’autorité.
La bonne réponse est une suite de décisions. Un nouvel événement peut ne mériter aucune réponse, un examen ultérieur, un passage de l’agent principal ou votre propre jugement. Ce sont des issues différentes, et un agent digne de confiance ne devrait pas les confondre.
Toujours actif devrait signifier continuité, pas interruption
« Toujours actif » a de la valeur parce que le monde ne s’organise pas en sessions de chat. Une pull request peut échouer après que vous avez fermé votre portable. Un fournisseur peut changer une date de livraison pendant que vous êtes en réunion. Un contrat peut être signé trois jours après la dernière fois que vous en avez parlé. L’agent a besoin d’une continuité à travers ces creux s’il doit porter une responsabilité qui dure.
La continuité n’exige pas de raisonner en permanence. La plupart des événements sont des doublons, des confirmations de routine, des changements sans rapport ou des informations qui resteront utiles plus tard. Réveiller un grand modèle pour chaque événement gaspille de la puissance de calcul, mais le coût le plus lourd est comportemental : si chaque réveil devient un message, l’agent dépense l’attention de l’utilisateur comme si elle était gratuite.
La recherche sur les notifications au travail constate depuis longtemps la même tension. Les gens apprécient d’être informés passivement, mais les notifications perturbent la tâche sur laquelle ils sont concentrés. Les travaux sur le report borné montrent aussi pourquoi « maintenant ou jamais » est un mauvais choix : une alerte peut être retardée dans une limite connue, ce qui préserve l’information sans traiter chaque arrivée comme une urgence.
Un agent toujours actif devrait donc distinguer trois horloges :
le moment où un événement arrive ;
le moment où l’agent doit y réfléchir ;
le moment où l’utilisateur doit savoir ou décider.
Parfois, les trois sont immédiats. Le plus souvent, non.
Un réveil n’est pas une notification, et une notification n’est pas une autorisation
La limite la plus importante passe facilement inaperçue. Détecter un événement, réveiller l’agent principal, prévenir l’utilisateur et agir à l’extérieur sont quatre étapes distinctes.
Imaginons que Comma suive une pull request. Un nouveau commentaire de revue arrive. Le processus de surveillance peut d’abord déterminer si ce commentaire change quelque chose de pertinent. Si oui, l’agent principal peut se réveiller et examiner la pull request, la discussion qui l’entoure et la Task à laquelle elle se rattache. L’agent pourra peut-être mettre à jour un brouillon ou préparer un correctif sans vous interrompre. Il devra peut-être vous signaler que la fenêtre de fusion est menacée. Ou il arrivera à une décision, comme accepter un compromis de sécurité, qui vous appartient.
Aucune de ces conclusions ne découle de la seule arrivée du commentaire.
C’est selon cette séparation que l’architecture de Comma est censée fonctionner. Une Loop légère surveille et ne réveille l’agent principal qu’en cas de besoin ; l’agent principal fait ensuite le travail qui demande du contexte. Les détails techniques, notamment la façon dont les Loops filtrent les événements, dédupliquent les réveils et fonctionnent sous quotas, sont présentés dans Des boucles d'événements programmables pour notre harnais d'agents distribué. Le principe, côté lecteur, est plus simple : un événement est un indice, pas une instruction, et un réveil est une demande d’enquête, pas une autorisation d’agir.
Les quatre tests pour réveiller l’agent principal
Une politique de réveil utile peut s’exprimer en quatre tests. Ce n’est pas une grille où un total élevé l’emporte automatiquement. Chaque test écarte un type différent de fausse alerte.
1. Quelque chose a-t-il vraiment changé ?
Le premier test porte sur l’état, pas sur l’activité. Un nouveau message est de l’activité. Une échéance qui avance, un blocage qui apparaît, une validation qui arrive ou une condition promise qui se réalise, c’est un changement d’état.
L’agent devrait se taire quand le nouvel événement répète ce qu’il sait déjà, accuse réception d’un message sans changer le plan ou sort de la responsabilité qu’on lui a demandé de surveiller. Des identifiants stables et la déduplication aident au niveau du système, mais la répétition sémantique demande toujours du jugement : deux messages différents peuvent exprimer le même « rien de nouveau ».
Ce test empêche l’agitation de se faire passer pour du progrès.
2. Le changement touche-t-il un objectif ou une contrainte en cours ?
Ce qui compte dépend de la personne. Une baisse du prix d’un vol n’a rien d’important en soi ; elle compte si elle passe sous le budget que l’utilisateur a fixé pour un voyage qu’il compte toujours faire. Une build en échec ne compte pas de la même façon sur une branche abandonnée, une branche exploratoire et une version candidate.
L’agent a besoin de l’objectif, du plan en cours, des contraintes pertinentes et d’assez d’informations de provenance pour savoir d’où viennent ces faits. Sans ce contexte, « important » finit par vouloir dire spectaculaire en général plutôt qu’utile dans ce cas précis.
C’est aussi là que le périmètre protège la confiance. Une Loop qui suit un dépôt ne devrait pas transformer une mention en passant d’un autre projet en nouvelle mission. Le contenu entrant peut éclairer la responsabilité surveillée ; il ne peut pas l’élargir en silence.
3. Existe-t-il une fenêtre d’action ?
Certains changements comptent sans exiger de réfléchir tout de suite. Un rapport qui sera relu vendredi peut attendre dans un récapitulatif. Une livraison retardée ne devient pertinente que si elle menace un événement qui en dépend. À l’inverse, une réunion annulée qui libère un créneau rare, ou une régression en production qui touche de plus en plus d’utilisateurs, peut perdre de la valeur à chaque minute.
La question n’est pas seulement « est-ce urgent ? ». C’est : réfléchir maintenant créerait-il une meilleure option que réfléchir plus tard ?
Si oui, réveillez l’agent principal. Si l’information restera tout aussi exploitable, reportez-la à un point de contrôle naturel ou regroupez-la avec des mises à jour liées. Si aucune action n’est possible et qu’aucun plan ne change, consignez-la et restez silencieux.
4. À qui revient la prochaine décision ?
Une fois le contexte rassemblé, l’agent principal doit déterminer qui a autorité sur l’étape suivante.
Un travail de routine, réversible et conforme aux consignes de l’utilisateur peut souvent continuer sans interruption. L’agent peut mettre à jour ses notes de Task, préparer une comparaison ou rédiger une réponse. Une décision lourde de conséquences, ambiguë ou qui dépend de préférences devrait revenir à l’utilisateur. Dans Comma, un travail qui a besoin d’une décision humaine peut attendre dans À valider au lieu d’être tranché au hasard ou marqué comme terminé.
Une bonne escalade est précise. Elle doit dire ce qui a changé, pourquoi cela modifie le plan, ce que l’agent a déjà vérifié, quelle décision est nécessaire et à partir de quand elle ne servira plus à rien. « Que voulez-vous faire ? » n’est pas un passage de relais ; c’est une analyse inachevée.
Quatre issues légitimes, pas seulement réveil ou sommeil
Une fois les tests appliqués, l’agent dispose de quatre réponses utiles.
Se taire. Rien de pertinent n’a changé, l’événement est un doublon ou il sort du périmètre de la surveillance. Le silence devrait être une conclusion délibérée, avec assez de traces internes pour diagnostiquer les erreurs, et non une absence de traitement.
Reporter ou regrouper. Le changement est pertinent, mais sa valeur survit à un délai. Ajoutez-le au prochain point de contrôle de la Task, à un briefing ou à un récapitulatif concis. Le report a besoin d’une limite : « plus tard » doit désigner un moment ou une condition connus, pas une pile de tâches sans responsable.
Réveiller l’agent principal. L’événement peut changer le plan, demande un contexte plus large ou est trop incertain pour le filtre léger. Le réveil est justifié même si le résultat final est le silence ; l’agent principal peut enquêter et conclure qu’aucun message n’est nécessaire pour l’utilisateur.
Rendre la main à l’utilisateur. L’agent est arrivé à une décision qui engage l’autorité, le risque, les goûts ou un compromis que seul l’utilisateur peut faire. Il devrait conserver le travail déjà fait et présenter la plus petite décision qui débloque la suite.
Ce modèle à quatre issues rend l’incertitude gérable. Un processus de surveillance n’a pas à feindre l’assurance quand les indices sont faibles. Il peut réveiller l’agent principal pour un examen plus poussé. L’agent principal, de son côté, n’a pas à s’inventer une autonomie quand une décision appartient à l’utilisateur.
La confiance devrait changer le chemin, pas cacher l’événement
Un système toujours actif se trompera parfois. La défaillance dangereuse n’est pas seulement une fausse alerte ; c’est un événement écarté avec assurance que l’utilisateur n’a jamais l’occasion de rattraper.
La posture par défaut de Comma reflète cette asymétrie. Quand les Loops utilisent Jev pour filtrer une pull request, un ticket ou un fil qu’elles suivent, « se taire » exige une confiance élevée. Les incertitudes et les erreurs vont à l’agent principal, qui a pour consigne de vérifier la source avant d’écrire à l’utilisateur. Jev peut classer ; il ne peut ni envoyer de messages, ni modifier un état externe, ni s’accorder davantage d’accès. Le comportement et les limites actuels sont décrits dans Découvrez Salix, le harnais d'agents de Comma et dans la documentation des Loops.
Cette conception n’élimine pas les erreurs. Une décision de silence erronée mais prise avec assurance peut encore masquer une mise à jour. Elle place toutefois l’incertitude sur le chemin le plus sûr : un examen plus approfondi plutôt qu’un rejet silencieux. Les utilisateurs devraient aussi pouvoir mettre en pause ou supprimer une surveillance, en restreindre le périmètre et reprendre l’accès opérationnel. Un agent gagne le droit d’être présent en arrière-plan en rendant cette présence vérifiable et réversible.
Une bonne interruption arrive avec le travail déjà fait
La valeur d’un agent personnel toujours actif n’est pas de remarquer les choses avant vous. Les outils de supervision le font déjà. Sa valeur est de relier le changement à une responsabilité en cours et de réduire le travail qui vous reste.
Sur le fond, une interruption utile pourrait ressembler à ceci :
Le relecteur demande une modification du flux d’authentification. Elle bloque le critère de mise en production que vous avez fixé pour jeudi. J’ai vérifié la branche actuelle et reproduit le problème. J’ai préparé un correctif et des tests ; valider le compromis de compatibilité est la seule décision dont j’ai besoin de votre part avant de l’appliquer.
Ce message apporte le contexte, la conséquence, l’enquête déjà menée, une prochaine étape proposée et une limite de décision claire. Il ne demande pas à l’utilisateur de reconstituer pourquoi l’événement compte. Il ne confond pas non plus une prochaine action plausible avec l’autorisation de l’exécuter.
La même exigence s’applique quand l’agent choisit de ne pas interrompre. Une mise à jour reportée doit réapparaître au point de contrôle promis. Une décision de silence doit rester vérifiable. Une Task qui demande un jugement doit attendre de façon visible, et non disparaître dans une conversation sans fin.
L’objectif : une continuité sereine
Un agent toujours actif devrait créer de la continuité sans exiger une attention continue. Le système extérieur surveille à faible coût et dans un périmètre étroit. L’agent principal se réveille quand un changement peut modifier le plan. Il enquête avant d’interrompre. Il poursuit le travail de routine et réversible quand l’utilisateur lui en a déjà donné l’autorité, et il renvoie les choix lourds de conséquences avec le travail utile en pièce jointe.
L’expérience qui en résulte n’est pas celle d’un agent qui parle davantage. C’est celle d’un agent qui peut rester responsable tout en restant silencieux, et qui sait exactement quand le silence n’est plus utile.
Questions fréquentes
Qu’est-ce qui s’exécute avant le réveil de l’agent principal ?
Dans Comma, une Loop légère surveille la boîte de réception, le dépôt, le flux, l’API ou le webhook choisis. Son programme peut appliquer des règles déterministes et demander à Jev une décision typée et rapide. L’agent principal et son contexte plus large ne s’exécutent que lorsque la Loop envoie un réveil pour une enquête ou une action plus poussée.
Chaque réveil de l’agent doit-il devenir une notification pour l’utilisateur ?
Non. Un réveil permet à l’agent principal d’examiner le contexte et de déterminer ce que l’événement change. Il peut poursuivre un travail en arrière-plan, reporter une mise à jour ou conclure qu’il n’est pas nécessaire d’interrompre l’utilisateur. L’attention de l’utilisateur ne devrait être sollicitée que lorsque l’information ou la décision est sensible au temps.
Que doit-il se passer quand l’agent n’est pas sûr ?
L’incertitude devrait faire passer l’événement à un décideur plus compétent. Un filtre léger peut réveiller l’agent principal ; l’agent principal peut vérifier la source, rassembler le contexte et avancer dans les limites de son autorité ou interroger l’utilisateur. L’incertitude ne devrait pas se transformer en décision de silence prise avec assurance, ni en action non autorisée.
Comment un utilisateur peut-il arrêter une surveillance toujours active ?
Comma permet de lui demander de mettre en pause ou de supprimer une Loop. L’accès aux ordinateurs connectés peut aussi repasser en lecture seule en désactivant les opérations. Une responsabilité toujours active devrait toujours avoir un périmètre compréhensible, un état visible et un véritable interrupteur d’arrêt.
Transformer un signal en prochaine étape utile
Commencez par une seule source d’événements et notez ce qui changerait réellement votre plan, combien de temps la fenêtre d’action reste ouverte et quelle décision doit rester la vôtre. Explorez l’Agent de Comma pour voir comment l’attention proactive se relie aux Tasks et à la validation, ou lisez la documentation des Loops pour connaître le modèle de surveillance actuel et ses limites.
