Faire évoluer les Managed Agents : séparer le cerveau et les mains

• Le service d’hébergement Managed Agents, conçu pour les agents de longue durée, adopte une architecture fondée sur des interfaces qui reste stable même lorsque le harness évolue avec les progrès du modèle
• Le harness encode des hypothèses sur les tâches que Claude ne peut pas accomplir seul, mais à mesure que le modèle progresse, ces hypothèses deviennent obsolètes (stale) et génèrent une surcharge inutile
• De la même manière qu’un système d’exploitation virtualise le matériel en abstractions comme les processus et les fichiers, Managed Agents virtualise les composants d’un agent (session, harness, sandbox) afin qu’ils puissent être remplacés indépendamment
• En séparant le cerveau (harness) et les mains (sandbox), l’architecture a permis d’obtenir des gains de performance avec un TTFT p50 réduit d’environ 60 % et un p95 réduit de plus de 90 %
• Cette conception joue le rôle de méta-harness capable d’accueillir n’importe quel futur harness ou sandbox

---

Les hypothèses du harness deviennent obsolètes à mesure que le modèle progresse

• Le harness est une structure qui encode des hypothèses sur les tâches que Claude ne peut pas effectuer par lui-même, mais ces hypothèses deviennent inutiles lorsque le modèle progresse
• Avec Claude Sonnet 4.5, un phénomène de "context anxiety" apparaissait, le modèle interrompant le travail prématurément lorsqu’il approchait de la limite de contexte, ce qui a conduit à ajouter une réinitialisation du contexte dans le harness
• Dans Claude Opus 4.5, ce comportement a disparu, faisant de cette logique de réinitialisation un code inutile
• Comme le harness est amené à continuer d’évoluer, Managed Agents a été conçu comme un service reposant sur des interfaces génériques non dépendantes d’une implémentation particulière

Une philosophie de conception inspirée des systèmes d’exploitation

• Les systèmes d’exploitation virtualisent le matériel via des abstractions comme les processus et les fichiers, afin de pouvoir exécuter même des programmes qui n’existent pas encore au moment de leur conception
• De la même façon que la commande read() fonctionne aussi bien avec un pack de disques des années 1970 qu’avec un SSD moderne, les abstractions survivent plus longtemps que le matériel
• Managed Agents suit le même schéma en virtualisant les composants de l’agent
  • Session : journal append-only de tous les événements survenus
  • Harness : boucle qui appelle Claude et route les appels d’outils
  • Sandbox : environnement d’exécution dans lequel Claude lance du code et modifie des fichiers

Conception initiale : les limites du conteneur unique (problème du "pet")

• Au départ, la session, le harness et le sandbox étaient placés dans un seul conteneur
• Cette approche avait l’avantage de permettre l’édition de fichiers directement via des appels système et d’éviter de devoir concevoir des frontières de service
• Mais le conteneur devenait alors un "pet" (une instance individuelle difficile à remplacer)
  • En cas de panne du conteneur, la session était perdue
  • En cas de non-réponse, le conteneur devait être réparé manuellement
• Du point de vue du débogage, le simple flux d’événements WebSocket ne permettait pas de localiser le point de défaillance, et l’accès shell au conteneur compliquait aussi le débogage car il contenait des données utilisateur
• Le harness supposait en outre que toutes les cibles de travail se trouvaient à l’intérieur du conteneur, de sorte qu’en cas de demande client de connexion VPC, il fallait mettre en place du peering réseau ou exécuter le harness dans l’environnement du client

Séparer le cerveau et les mains (architecture centrale)

• Le cerveau (Claude et le harness), les mains (sandbox et outils) et la session (journal d’événements) sont séparés en interfaces indépendantes
• Chaque composant peut échouer ou être remplacé indépendamment

Le harness sort du conteneur

• Le harness est déplacé hors du conteneur et appelle ce dernier comme n’importe quel autre outil via execute(name, input) → string
• Le conteneur devient alors du "cattle" (une instance remplaçable)
• En cas de panne du conteneur, le harness traite l’incident comme une erreur d’appel d’outil et, si Claude décide de réessayer, initialise un nouveau conteneur via provision({resources})

Reprise après panne du harness

• Comme le journal de session existe hors du harness, aucun état interne n’a besoin de survivre à l’intérieur du harness
• En cas de panne, wake(sessionId) → getSession(id) permet de récupérer le journal d’événements et de reprendre à partir du dernier événement
• Pendant la boucle agent, le harness conserve un enregistrement durable des événements via emitEvent(id, event)

Frontières de sécurité

• Dans la conception couplée, le code non fiable généré par Claude s’exécutait dans le même conteneur que les identifiants, ce qui permettait à une injection de prompt d’exfiltrer des variables d’environnement
• Si un attaquant obtenait un jeton, il pouvait alors créer librement de nouvelles sessions et déléguer des tâches sans restriction
• La solution structurelle consiste à séparer le sandbox afin qu’il n’ait jamais accès aux jetons
• Git : lors de l’initialisation du sandbox avec un jeton d’accès au dépôt, le service clone le dépôt et le connecte au git remote local, permettant à l’agent d’exécuter push/pull sans manipuler directement le jeton
• Outils personnalisés MCP : les jetons OAuth sont stockés dans un coffre-fort sécurisé (vault), puis un proxy dédié récupère les identifiants depuis ce coffre avec le jeton associé à la session lorsqu’un outil MCP appelle un service externe

Une session n’est pas la fenêtre de contexte de Claude

• Les tâches longues dépassent souvent la taille de la fenêtre de contexte de Claude, ce qui impose de prendre des décisions irréversibles sur ce qu’il faut conserver
• Compaction : Claude enregistre un résumé de la fenêtre de contexte
• Outil de mémoire : Claude écrit le contexte dans des fichiers afin de pouvoir apprendre d’une session à l’autre
• Élagage du contexte : suppression sélective de jetons, comme d’anciens résultats d’outils ou des blocs de raisonnement
• La suppression irréversible de contexte peut conduire à des échecs car il est difficile de prédire quels jetons seront nécessaires dans les tours futurs
• Des travaux antérieurs ont exploré une approche où le contexte est stocké comme un objet externe à la fenêtre de contexte, auquel le LLM accède de manière programmatique en écrivant du code

Utilisation du journal de session dans Managed Agents

• La session joue le rôle d’un objet de contexte situé hors de la fenêtre de contexte
• Elle est stockée de manière durable dans le journal de session, et non dans le sandbox ou un REPL
• L’interface getEvents() permet de sélectionner des tranches positionnelles dans le flux d’événements
  • Continuer la lecture à partir du dernier point lu
  • Remonter de quelques événements avant un moment précis
  • Relire le contexte avant une action donnée
• Les événements récupérés peuvent ensuite être transformés dans le harness puis transmis à la fenêtre de contexte de Claude
• Ces transformations incluent le nettoyage du contexte et du context engineering pour obtenir un taux de hit élevé du cache de prompt
• La session garantit uniquement le stockage durable et la consultation, tandis que la gestion concrète du contexte est déléguée au harness afin de s’adapter aux besoins des futurs modèles

Plusieurs cerveaux, plusieurs mains

Plusieurs cerveaux (Many Brains)

• La séparation entre cerveau et mains a résolu une première plainte client : lorsqu’il faut agir sur des ressources dans un VPC, le peering réseau n’est plus nécessaire
• Dans la conception initiale, chaque cerveau nécessitait son propre conteneur, ce qui empêchait de démarrer l’inférence avant la fin du provisioning du conteneur
• Même les sessions ne nécessitant pas de sandbox supportaient le coût complet d’initialisation du conteneur, incluant clonage du dépôt, démarrage des processus et récupération des événements en attente
• Après séparation, le conteneur n’est provisionné en appel d’outil que lorsqu’il est nécessaire, supprimant ainsi la latence inutile
• L’inférence peut démarrer dès que la couche d’orchestration récupère les événements en attente dans le journal de session
• Résultat : TTFT p50 réduit d’environ 60 %, TTFT p95 réduit de plus de 90 %
• L’extension à plusieurs cerveaux consiste simplement à lancer plusieurs harnesses sans état (stateless) et à ne les connecter aux mains qu’en cas de besoin

Plusieurs mains (Many Hands)

• Il faut aussi pouvoir connecter chaque cerveau à plusieurs environnements d’exécution
• Comme Claude doit raisonner sur plusieurs environnements d’exécution et décider de la répartition du travail, il s’agit d’une tâche cognitivement plus difficile qu’un simple shell unique
• Au départ, les limites du modèle avaient conduit à placer le cerveau dans un conteneur unique, mais à mesure que l’intelligence du modèle a progressé, ce conteneur unique est devenu une contrainte
• Dans la conception séparée, chaque main est traitée comme un outil execute(name, input) → string
  • Prise en charge des outils personnalisés, des serveurs MCP et des outils internes
  • Le harness n’a pas besoin de savoir si le sandbox est un conteneur, un téléphone ou un émulateur Pokémon
• Comme cerveau et mains ne sont pas couplés, il devient même possible de transférer des mains d’un cerveau à un autre

Conclusion : Managed Agents comme méta-harness

• L’approche est la même que celle des systèmes d’exploitation, qui virtualisent le matériel pour accueillir des programmes n’existant pas encore
• Managed Agents est un méta-harness non dépendant d’un harness spécifique, fournissant une interface générique capable d’en accueillir de nombreux types
• Claude Code peut aussi être utilisé comme un harness, tout comme des harnesses d’agents spécialisés par tâche
• Les interfaces reposent sur une conviction claire : Claude a besoin de capacités de manipulation d’état (session) et d’exécution de calcul (sandbox)
• Cette conception d’interfaces vise l’extension à plusieurs cerveaux et plusieurs mains, ainsi qu’une exploitation stable et sûre sur le long terme
• Elle ne fait aucune hypothèse sur le nombre ni sur l’emplacement des cerveaux et des mains