Le 13 novembre, Anthropic a publié sur le blog officiel de Claude un article qui décortique l'architecture des agents permanents (always-on agents). Un agent permanent ne fonctionne pas vraiment 24 heures sur 24 : il dort la plupart du temps, se réveille quand un événement arrive, fait son travail, puis se rendort. L'amélioration du jugement des modèles et la baisse des coûts d'inférence font passer ce type d'agent de la démonstration à l'usage réel — sur les tâches de longue haleine, Opus 5.5 coûte 78 % de moins par tâche résolue qu'Opus 5. Selon Anthropic, des clients demandent déjà comment intégrer cette expérience dans leurs propres produits.
Ce que fait chacune des cinq primitives
Les agents permanents partagent la même boucle centrale que les agents ordinaires ; la différence tient à l'architecture qui les entoure, construite à partir de cinq primitives. La boîte de réception des événements s'occupe de recevoir : webhooks, tâches planifiées et tâches de fond écrivent d'abord chaque événement dans une table de base de données, où il est dédupliqué avant qu'un worker ne le récupère — ainsi, deux événements arrivant en même temps ne peuvent pas lancer des exécutions concurrentes, et un plantage ne peut pas perdre un événement. Les minuteurs assurent la proactivité et se déclinent en deux types : les suivis, des échéances que l'agent se fixe à lui-même, et les planifications, des travaux récurrents à cadence fixe comme une newsletter quotidienne, déclenchés par un ordonnanceur qui interroge à intervalle régulier.
La mémoire assure la continuité entre de nombreuses exécutions séparées : elle ne stocke que ce que l'agent ne peut pas retrouver ailleurs, en quatre catégories — instructions de l'utilisateur, notes sur l'utilisateur, messages déjà envoyés et progression des tâches — et, dans les propres produits d'Anthropic, elle est mise en œuvre sous forme d'un répertoire de fichiers. Les autorisations sont la partie la plus risquée : une exécution sans supervision détient les identifiants de l'utilisateur, aussi Anthropic recommande-t-il d'injecter les identifiants via un proxy avant l'envoi des requêtes, de bloquer les actions à haut risque en mode automatique et de différer les appels d'outils jusqu'à confirmation de l'utilisateur. La boîte d'envoi règle le rythme auquel les résultats parviennent à l'utilisateur : trop bavarde, elle dérange ; trop silencieuse, elle laisse passer des choses. Anthropic recommande de commencer discrètement, puis de gagner progressivement l'attention de l'utilisateur.
À qui cela sert, et où sont les limites
Cette architecture convient aux équipes qui veulent rendre un agent existant proactif ou construire une expérience permanente à partir de zéro ; les cas typiques sont les suivis clients, les briefings planifiés et les tâches de fond sans supervision. Mais elle répond à la question de savoir quand l'agent se réveille, de quoi il se souvient alors et comment il rend compte — pas au plafond de capacité du modèle lui-même. Les sessions devenues trop longues doivent toujours être compactées ou redémarrées, et tout ce qui doit persister doit être écrit en mémoire à temps. Chaque exécution comporte aussi un surcoût de contexte, aussi Anthropic recommande-t-il de garder le contexte initial léger et d'utiliser la mise en cache des invites pour contenir les coûts.
Anthropic présente cet article comme un guide de construction, et non comme un lancement de produit : aucun nouveau produit ni aucune date de lancement n'a été annoncé. Les développeurs peuvent utiliser les cinq primitives pour passer leur propre architecture au crible, et le fonctionnement concret des protocoles d'agents vaut la peine d'être lu en complément.
