Agents always-on : les cinq primitives d'Anthropic et l'étage AX de Google

Le 13 novembre 2026, Anthropic a publié « Building always-on agents », un guide d'architecture signé William Hu¹. Il décrit comment construire un agent qui surveille des outils, relance un dossier trois jours plus tard ou envoie un point chaque matin. Il fixe un vocabulaire (run, session, inbox, timer, outbox) et cinq briques à poser autour de la boucle d'agent, sans produit ni code à installer. Agent Executor (AX), le runtime open source que Google développe depuis mai, traite le même problème à l'étage de l'infrastructure. Ce texte s'adresse aux architectes et CTO qui passent un agent du prototype à la production. Pour un assistant conversationnel qui ne répond qu'aux messages, il apporte peu.

Qu'est-ce qu'un agent always-on, selon Anthropic ?

Anthropic définit ces agents comme « stateful and proactive » (avec état et proactifs) : ils gèrent du contexte d'une session à l'autre et agissent sans supervision directe. Leur boucle est celle de tout agent ; le guide traite de ce qu'on construit autour¹.

Le guide ouvre sur une mise au point : « An always-on agent is not actually “always on.” » (un agent always-on n'est pas vraiment toujours actif). L'expression décrit ce que voit l'utilisateur. Dans le 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é. Le run se déroule dans une session, le transcript des messages et des appels d'outils. Le diagramme du guide montre de longues plages de sommeil sans aucun token dépensé.

Anthropic donne deux raisons au retour de ces agents. Les derniers modèles comprennent mieux l'intention de l'utilisateur et savent mieux quand le solliciter. Et le coût baisse, surtout sur les tâches longues : sur un benchmark de code long-horizon, Opus 5.5 coûte 78 % de moins par tâche résolue qu'Opus 5, contre 40 % de moins sur des workloads typiques¹. La documentation de la plateforme Claude, vers laquelle pointe le guide, détaille ce benchmark : un sous-ensemble de 478 problèmes de SWE-bench Pro, deux passes par réglage en septembre 2026, aux prix catalogue. La tâche résolue y passe de 1,01 $ avec Opus 5 à 0,22 $ avec Claude Opus 5.5, pour 91,9 % puis 92,8 % de tâches résolues, l'effort par défaut descendant de high à medium². Ce sont des mesures d'Anthropic sur un benchmark qu'il a choisi.

Le guide paraît trois semaines après Claude Duet, le produit grand public qu'Anthropic a ouvert le 21 octobre 2026 en research preview sur liste d'attente, d'abord pour les abonnés Pro, Max et Ultra aux États-Unis. Duet envoie un brief chaque matin, vérifie les comptes connectés à quelques heures d'intervalle, tourne sur une machine virtuelle dotée de son propre navigateur et attend l'accord de l'utilisateur avant d'envoyer un message, de payer, de signer un document ou de supprimer quoi que ce soit³. Le guide ne cite pas Duet. Il dit en revanche que des clients ont demandé à Anthropic comment intégrer ce type d'expérience à leurs propres produits¹.

Les cinq primitives : inbox, timers, mémoire, permissions, outbox

L'event inbox : une file, un seul worker

Un agent always-on peut être déclenché par des webhooks, des tâches planifiées, des jobs de fond ou un message de l'utilisateur. Si chaque source appelle l'agent directement, deux événements simultanés lancent deux runs concurrents, et un crash fait perdre un événement. Le guide place donc une liste durable entre les sources et l'agent, en général une table de base relationnelle. Un handler HTTP y écrit chaque événement puis réveille le worker, qui lit tout ce qui est en attente¹.

Le handler acquitte vite, parce que les fournisseurs de webhooks traitent une réponse lente comme un échec ; les vérifications lourdes, comme la détection d'injection de prompt, se font pendant le run. Les doublons s'éliminent avec l'identifiant fourni par la source. Une inbox n'a qu'un seul worker actif à la fois, ce qui évite deux runs qui se marchent dessus ; ce worker peut regrouper trois messages envoyés à la suite pour ne répondre qu'une fois. Anthropic conseille de commencer avec une inbox par utilisateur, puis de découper si l'on a besoin de parallélisme¹.

Les timers : ce qui rend l'agent proactif

Le guide distingue le follow-up, une échéance que l'agent se fixe lui-même, et le schedule, une tâche récurrente comme une newsletter quotidienne. Les timers vivent dans leur propre table, séparée de l'inbox, qui ne doit contenir que des événements prêts à traiter. Un timer ne lance jamais de run lui-même : un scheduler parcourt la table à intervalle fixe, clôt les follow-ups échus, avance les schedules à leur prochaine occurrence, puis dépose un événement dans l'inbox. Pour ce scheduler, Anthropic laisse le choix entre un service maison et un moteur de durable execution¹.

La mémoire : ce que l'agent ne peut pas retrouver ailleurs

Dans Claude Code (l'auto memory) comme dans l'API Messages (le memory tool), Anthropic implémente la mémoire comme un répertoire de fichiers. Pour un agent always-on, ce répertoire doit reposer sur une base ou un object store, afin de survivre au worker. La règle du guide : « memory should only hold what the agent can’t look up again » (la mémoire ne doit contenir que ce que l'agent ne peut pas retrouver ailleurs). Une information déjà présente dans un outil de tickets se garde sous forme de pointeur¹.

Le guide range quatre contenus : les instructions de l'utilisateur, chargées à chaque run ; ce que l'agent a appris sur lui ; les messages passés ; l'avancement des tâches. Quand les notes grossissent, seul un index est chargé au réveil et l'agent lit le détail à la demande. Ce contexte initial se paie à chaque run, d'où la consigne de le garder court et de passer par le prompt caching. Le guide mentionne enfin le dreaming, une passe facultative qui relit les sessions passées pour corriger et consolider les souvenirs¹. Les mesures qu'Anthropic a publiées le 6 novembre sur ces couches de mémoire sont détaillées dans ce qu'Anthropic a mesuré sur la mémoire d'agent.

Les permissions : là où se concentre le risque

Un run détient les accès de l'utilisateur et tourne sans surveillance. Le guide propose trois mécanismes, repris des autres agents d'Anthropic¹ :

• un proxy placé hors de l'environnement de l'agent, qui ajoute les vrais credentials aux requêtes sortantes : l'agent envoie ses requêtes sans secret ;
• l'auto mode de Claude Code, dont les classifieurs examinent les actions à risque et bloquent celles qu'ils jugent dangereuses ; les décisions les plus importantes restent soumises à l'utilisateur ;
• l'appel d'outil différé : le run s'arrête, la session est sauvegardée au milieu de l'appel, la demande s'affiche chez l'utilisateur (par exemple dans une carte interactive construite avec MCP Apps), et sa réponse revient dans l'inbox comme un nouvel événement qui reprend la session. Pendant l'attente, le worker traite les autres événements.

L'outbox : savoir se taire

Un run finit de trois façons : un message, rien, ou une demande différée. Pour la plupart des agents, un simple outil d'envoi suffit. Une outbox (table de messages sortants vidée par un dispatcher) sert à cadencer les envois ou à reprendre après une erreur. Le guide insiste surtout sur le volume : un agent trop bavard devient du bruit, un agent trop discret laisse passer ce que l'utilisateur devait savoir. Anthropic recommande de régler cet équilibre avec des evals et de commencer discret : « it’s better for the agent to start quiet and then earn more of the user’s attention over time » (mieux vaut que l'agent commence discret et gagne l'attention de l'utilisateur avec le temps)¹.

Des patterns connus, quatre contraintes propres aux LLM

Un architecte qui a construit des systèmes distribués reconnaîtra chaque brique : l'inbox est un consommateur idempotent à écrivain unique, l'outbox rappelle le transactional outbox, les timers ceux des moteurs de durable execution, et la règle d'un worker par inbox le modèle acteur. Vos équipes savent déjà opérer ces briques sur PostgreSQL ou une file de messages.

Le modèle de langage ajoute quatre contraintes :

1. Un réveil se paie en tokens. Le contexte chargé au démarrage, le cache et l'index de mémoire deviennent des postes de coût.
2. La mémoire est rédigée par le modèle. Elle se relit, se corrige et s'évalue, ce qu'on ne fait pas avec un état sérialisé.
3. L'inbox reçoit des entrées non fiables. Un e-mail ou un webhook peut porter une injection de prompt, d'où le contrôle pendant le run plutôt qu'à l'entrée.
4. L'outbox demande du jugement. Décider de ne rien envoyer se teste avec des evals.

Le troisième point a un antécédent : la « Agents Rule of Two » publiée par Meta le 31 octobre 2025. Tant qu'une injection de prompt ne peut pas être détectée de façon fiable, un agent ne devrait réunir dans une même session que deux des trois propriétés suivantes : traiter des entrées non fiables, accéder à des systèmes sensibles ou à des données privées, changer un état ou communiquer vers l'extérieur⁴. Un agent always-on qui lit vos e-mails et agit pour vous réunit les trois par construction. L'appel différé et l'auto mode servent à reprendre la main sur la troisième propriété.

Qu'est-ce qu'Agent Executor (AX) de Google ?

Agent Executor, abrégé AX, est publié sous licence Apache 2.0 sur github.com/google/ax et écrit en Go. Jaana Dogan l'a rendu public sur X le 20 mai 2026⁵. Le billet du blog Google Cloud, signé par Jaana Dogan et Ethan Bao et daté du 21 mai, le présente comme le « runtime standard for agent execution, resumption, and distributed deployment » (standard d'exécution, de reprise et de déploiement distribué des agents) de Google, disponible en preview⁶. Il annonce cinq capacités : exécution durable, avec reprise après une panne ou une confirmation humaine ; isolation dans des sandboxes ; cohérence de session grâce à une architecture à écrivain unique (single-writer) ; reconnexion des clients avec rattrapage depuis la dernière séquence reçue ; branchement de trajectoires à partir de checkpoints. Le billet le dit indépendant du harnais et cite Antigravity, les Managed Agents de l'API Gemini, ADK, LangChain et LangGraph, et les agents qui parlent A2A⁶.

Le dépôt décrit un orchestrateur déclaratif proche de kubectl. Les manifestes ax.io/v1alpha1 déclarent une Task (l'unité d'exécution isolée), un Workspace (dépôts Git, serveurs MCP et skills préparés avant le démarrage), un Model et une Gateway, qui liste les sorties réseau autorisées et peut injecter un credential dans les requêtes hors du sandbox, si bien que la tâche ne le détient jamais. Les commandes ax suspend et ax resume mettent une tâche en pause avec checkpoint, puis la reprennent. Le README résume la thèse : « Agents are a new kind of workload. They are neither stateless microservices nor run-to-completion batch jobs. » (les agents sont un nouveau type de workload, ni microservices sans état ni jobs batch exécutés jusqu'au bout)⁷. Le dépôt comptait 14 710 étoiles sur GitHub le 15 novembre 2026.

AX ne sert pas à écrire un agent. Sur Hacker News, le 21 septembre 2026, Jaana Dogan l'a dit en majuscules : « It's NOT an agentic framework. » (ce n'est pas un framework d'agents)⁸. Chaque tâche tourne au-dessus d'Agent Substrate, une couche Kubernetes qui sépare l'état d'une session d'agent (l'acteur : fichiers, environnement, mémoire du processus, règles réseau) du calcul (des pods préchauffés dans un pool partagé). Le 5 novembre 2026, Google a annoncé le don d'Agent Substrate et de gVisor à la CNCF, au niveau Sandbox, pour KubeCon North America à Salt Lake City (9 au 12 novembre). Le billet annonce une reprise en moins de 500 millisecondes⁹.

AX et le guide d'Anthropic : quel recouvrement ?

Les deux textes ne se citent pas, et nous n'avons trouvé aucune comparaison publique entre eux. Ils ne partent d'ailleurs pas tout à fait du même constat. Anthropic parle de l'agent qui dort entre deux événements. Google écrit qu'un agent peut passer « 90% to 95% of its time waiting for model inference, external APIs, or human reviews » (de 90 % à 95 % de son temps à attendre l'inférence du modèle, des API externes ou des validations humaines)⁹ : il parle du sandbox qui reste réservé pendant que l'agent attend au cours d'une session, et que Substrate libère quand l'agent devient inactif. Les deux économies se cumulent. Le guide d'Anthropic évite de payer des tokens quand rien ne se passe ; Substrate cherche à ne pas immobiliser de calcul pendant l'attente.

On peut donc assembler les deux : un worker conforme au guide d'Anthropic, qui reprend une Task AX à chaque événement de son inbox, avec Claude comme modèle. Le billet de mai promet de déployer ses agents sur sa propre infrastructure sans être lié au modèle d'un fournisseur⁶. Personne, à notre connaissance, n'a publié ce montage. Une limite au 15 novembre : la documentation d'AX montre un manifeste Model avec un fournisseur Anthropic, mais le contrôleur n'implémente que le fournisseur Google, écart consigné dans une issue ouverte le 22 septembre 2026¹¹. Le conteneur de l'agent peut en revanche appeler l'API Claude lui-même.

Pour situer AX dans l'offre Google : ADK sert à écrire des agents, A2A à les faire dialoguer, et les Managed Agents de l'API Gemini à les faire héberger par Google, avec triggers planifiés et plafond de tokens. AX se place en dessous, comme le runtime que l'on opère soi-même sur son cluster. Anthropic a aussi son offre hébergée, Claude Managed Agents, dont les sandbox peuvent tourner sur l'infrastructure du client, en bêta publique depuis le 19 mai 2026¹².

Ce que ça change pour vos équipes

Architecte, CTO. Commencez par l'inbox : une table, un handler qui acquitte vite et un seul worker par utilisateur règlent la concurrence avant qu'elle ne se manifeste en production. Gardez la mémoire de l'agent séparée de l'état d'exécution : un checkpoint de conteneur relève de l'infrastructure, un fichier de notes sur l'utilisateur relève du produit et se teste avec des evals. Les deux étages se choisissent séparément. Pour quelques centaines d'utilisateurs, une base, un scheduler et un service de workers suffisent ; AX et Substrate deviennent un sujet quand une flotte d'agents exécute du code dans des sandboxes.

RSSI. Le proxy de credentials d'Anthropic et la Gateway d'AX convergent : les secrets restent hors de l'environnement de l'agent. C'est le premier contrôle à exiger d'un agent qui agit sans surveillance, avant même l'auto mode. Exigez aussi que toute validation humaine passe par un appel différé : pendant l'attente, le worker continue de traiter les autres événements.

DSI. Le coût d'un tel agent dépend du nombre de réveils et du contexte chargé à chacun. Le chiffre de 78 % ne vaut que pour le benchmark d'Anthropic : mesurez le coût par tâche résolue sur votre propre trafic avant de dimensionner un budget.

Métier. Suivez le nombre de messages envoyés par semaine et la part jugée utile, au même titre que la latence.

Les limites à garder en tête

• AX est en preview : le README annonce des changements incompatibles probables avant une version stable, et la feuille de route liste encore la suspension automatique des tâches inactives, le branchement d'une tâche en cours et les politiques d'approbation⁷.
• Les chiffres de coût (78 %, 1,01 $ puis 0,22 $) sont des mesures d'Anthropic ; la reprise en moins de 500 ms et les 90 à 95 % d'attente sont des chiffres de Google. Aucune mesure indépendante n'a été trouvée au 15 novembre 2026.
• Le guide d'Anthropic décrit une architecture, sans service ni code fourni : l'inbox, le scheduler et le dispatcher restent à construire ou à acheter.

Pour la mémoire, la suite logique est la question de sa propriété : posséder sa mémoire d'agent dans un dépôt Git. Pour l'isolation des agents qui exécutent du code, voir les backends sandbox de Hermes Agent en production.