Agent always-on

Un agent qui dort entre deux runs

Anthropic définit les agents always-on, dans son guide « Building always-on agents » publié le 13 novembre 2026 et signé William Hu, comme des agents « stateful and proactive » (avec état et proactifs) : ils gèrent du contexte d'une session à l'autre et agissent sans supervision directe. Le nom décrit ce que voit l'utilisateur. Côté système, l'agent dort la plupart du temps et se réveille pour travailler.

Chaque période de travail est un run : l'agent reçoit un événement, accomplit sa tâche, puis enregistre ce qui s'est passé. Un run se déroule dans une session, le transcript des messages et des appels d'outils. La boucle d'agent reste la même ; c'est l'architecture autour qui change.

Les cinq primitives du guide d'Anthropic

• Event inbox : liste durable d'événements, en général une table de base relationnelle, alimentée par un handler qui acquitte vite et réveille le worker ; un seul worker actif par inbox, doublons écartés par l'identifiant de la source.
• Timers : échéances que l'agent se fixe (follow-up) et tâches récurrentes (schedule), dans un store séparé ; un scheduler dépose un événement dans l'inbox quand une échéance tombe.
• Mémoire : répertoire de fichiers adossé à une base ou à un object store, dont seul un index est chargé au réveil (voir mémoire d'agent et dreaming).
• Permissions : proxy qui ajoute les credentials hors de l'environnement de l'agent, auto mode à classifieurs, appels d'outils différés dont la réponse revient comme un événement.
• Outbox : table des messages sortants vidée par un dispatcher, utile pour cadencer les envois ou reprendre après une erreur ; un outil d'envoi simple suffit à la plupart des agents.

Ce qui le distingue d'un service événementiel classique

Chaque brique rappelle un pattern connu des architectures distribuées : consommateur idempotent, timers durables, transactional outbox. Le modèle de langage ajoute ses contraintes : un réveil se paie en tokens, la mémoire est rédigée par le modèle, les événements entrants peuvent porter une injection de prompt, et l'agent doit juger s'il vaut la peine d'écrire à l'utilisateur. Anthropic conseille de mesurer ce dernier point avec des evals et de commencer discret.

L'infrastructure qui suspend et reprend ces agents relève d'une autre couche, comme Agent Executor et Agent Substrate chez Google.

Questions fréquentes

• Un agent always-on consomme-t-il des tokens en permanence ?

  Non. Dans l'architecture décrite par Anthropic, l'agent ne travaille que pendant ses runs, déclenchés par un événement ou une échéance. Entre deux runs, il n'existe que sous forme de lignes en base et de fichiers de mémoire.

• Pourquoi une seule inbox par utilisateur ?

  Anthropic recommande de commencer ainsi, avec un seul worker actif par inbox : deux événements simultanés ne lancent pas deux runs concurrents, et le worker peut regrouper plusieurs messages pour ne répondre qu'une fois. On peut découper davantage si l'on a besoin de parallélisme.

• Comment un agent always-on demande-t-il une validation humaine ?

  Par un appel d'outil différé : le run s'arrête, la session est sauvegardée au milieu de l'appel, la demande est présentée à l'utilisateur, et sa réponse revient dans l'inbox comme un nouvel événement qui reprend la session.