Les agents gérés rendent désormais des comptes au Harness

À seize heures, la session Claude Code d'un développeur ouvre une session de travail sur la Billing API pour ajouter le prorata aux changements de plan. Vingt minutes plus tard, alors que cette session travaille encore, une exécution Archyl planifiée sur le profil backend-fixer prend un ticket sur l'arrondi des factures, qui se trouve lui aussi dans la Billing API.

Jusqu'à cette semaine, voici ce que faisait l'exécution planifiée. Elle ouvrait sa propre session de travail, comme les exécutions gérées le faisaient déjà. Le gate de preflight renvoyait warn, avec le motif 1 target element(s) are being worked on by other active sessions — coordinate before changing them. Ce verdict apparaissait dans le fil d'événements de l'exécution. Puis l'exécution démarrait quand même, parce que rien n'agissait sur ce verdict, et que personne ne suivait une exécution planifiée : il n'y avait personne avec qui se coordonner.

Je préfère le dire franchement : pour les exécutions hébergées, cet encadrement était surtout cosmétique. Le gate était affiché, puis ignoré. Les fichiers modifiés par l'agent n'étaient jamais rattachés à sa session, si bien que la mémoire atterrissait sur les éléments que le texte de la tâche mentionnait par hasard. Et la session se fermait sur un résumé d'une ligne, qui laissait très peu de choses à apprendre à l'agent suivant.

Ça a changé cette semaine. Le harness pilote désormais les exécutions gérées, et exécutions hébergées comme agents de code locaux se coordonnent sur le même modèle.

Faire tourner un agent devient la partie facile

Trois des plus grands noms du secteur proposent désormais un endroit hébergé où faire tourner des agents. La documentation d'Anthropic décrit Claude Managed Agents comme "un harness d'agent préconstruit et configurable qui s'exécute sur une infrastructure gérée", avec des sandboxes dans le cloud ou auto-hébergées, des sessions persistantes et des exécutions planifiées via cron. L'Agents API d'OpenAI, annoncée en bêta publique le 10 septembre, fait tourner la boucle de l'agent sur l'infrastructure d'OpenAI et prend en charge "l'orchestration, les sessions de longue durée et la gestion du contexte". Cursor Projects, annoncé le même jour, installe un agent coordinateur sur sa propre machine cloud, qui délègue à des sous-agents et peut tourner selon un planning ou suivre vos pull requests.

Ce sont de bons produits, et ils vont dans le même sens : sandbox, boucle d'outils, sessions et plannings deviennent quelque chose qu'on choisit dans une liste.

Ce qu'un runtime ne peut pas savoir seul, c'est votre système. À quel container appartient le code des factures. Qui en est responsable. Le contrat dont dépendent ses consommateurs. La décision qui a rendu une frontière délibérée. Et ce qui compte quand personne ne regarde : quel autre agent, y compris ceux que ce runtime n'a pas lancés, travaille sur quelle partie en ce moment.

Cette connaissance ne peut pas vivre dans un runtime, parce que vos agents ne tournent pas tous dans le même. Certains tournent sur un laptop, d'autres en CI, d'autres dans un worker hébergé. Notre façon de voir les choses, c'est donc : votre runtime, notre architecture. Quel que soit ce qui fait tourner l'agent, le modèle auquel il rend des comptes est le même.

Les exécutions d'agents gérées d'Archyl, lancées en avril, sont un runtime parmi d'autres. Cette semaine, elles ont commencé à se comporter comme tel. Vous pouvez aussi suivre et piloter une exécution en direct.

Une exécution peut désormais être refusée, motif à l'appui

La coordination est optionnelle. Chaque profil d'agent a un nouveau paramètre dans la rubrique Coordination, Respecter le travail des autres agents, désactivé par défaut. Quand il est activé, l'exécution ouvre sa session de travail en exclusivité, et le verdict du gate décide de la suite.

Si un autre agent détient une réservation sur les mêmes éléments, l'exécution est refusée, que cet agent soit Claude Code sur le laptop de quelqu'un ou une autre exécution gérée. L'exécution s'arrête avant que quoi que ce soit ne soit cloné, l'événement du gate indique Exécution refusée, et le motif dit qui travaille là, et sur quoi. Pour l'après-midi décrit plus haut :

session denied by preflight gate: "Billing API" is being worked on by
claude-code/vincent (add proration to plan changes)

Le format est le vrai ; la tâche est un exemple. La personne qui lit l'exécution le lendemain matin sait exactement à qui parler.

Si le gate ne fait qu'avertir, par exemple parce qu'un garde-fou de niveau erreur s'applique à la tâche, l'exécution ne démarre pas et n'échoue pas non plus. Elle attend au statut En attente d'approbation, sans occuper l'une des places d'exécution simultanée de votre organisation. La page de l'exécution liste les motifs, avec Approuver et démarrer et Annuler l'exécution.

Approuver ne valide pas l'ancien verdict les yeux fermés. Le gate est évalué à nouveau : si un agent local a pris une réservation sur ces éléments pendant que l'exécution attendait, l'exécution approuvée est quand même refusée. Une exécution que personne n'approuve sous 24 heures est annulée.

Pourquoi une exécution en attente ne détient rien

Pendant qu'une exécution attend, sa session est abandonnée. La session qui a levé l'avertissement est annulée, ses réservations partent avec elle, et l'approbation en ouvre une nouvelle. Garder les réservations paraîtrait plus prudent, et serait pire : une exécution que personne n'approuve jamais tiendrait tous les autres agents à l'écart de ces éléments pendant une journée, en leur disant à chacun que quelque chose y travaillait alors que rien n'y travaillait.

C'est dans la lignée d'un principe qu'on a posé en août. Les réservations sont consultatives, ce ne sont pas des verrous. L'exclusivité est quelque chose qu'un profil demande, pas quelque chose que la plateforme impose, et une exécution qui attend un humain ne revendique rien.

Le Guard est passé dans le worker

La session couvre l'intention. Le Guard couvre ce qui est écrit. Les agents locaux l'ont sous forme de hook Claude Code depuis août, et les exécutions gérées ont désormais la même vérification à l'intérieur du worker.

Quand le projet a un dépôt lié, chaque write_file et edit_file de l'agent est vérifié par rapport aux règles de conformité du projet avant que la modification ne soit appliquée. Une violation critique refuse l'écriture, et l'agent lit quelle règle est en cause, et pourquoi :

blocked by Archyl Guard: 1 critical architecture violation(s) in
backend/internal/adapter/http/handlers/invoice.go. Change the content so it
conforms, then write again:
- [critical] No direct database access from HTTP handlers — move the query behind a service

L'agent déplace la requête et écrit à nouveau. Une violation de sévérité haute laisse passer l'écriture, avec un avertissement. Si la vérification elle-même échoue ou expire, l'écriture passe : le Guard ne bloque jamais un agent à cause de ses propres erreurs, parce qu'une vérification de gouvernance qui casse le travail qu'elle encadre finit par être désactivée.

Chaque vérification porte aussi l'ID de session, ce qui rattache le fichier à la session de l'exécution pendant que l'agent travaille. Ça compte deux sections plus bas.

L'agent connaît sa session, mais elle ne lui appartient pas

Le prompt de l'exécution nomme désormais sa session et indique à l'agent que la plateforme l'a ouverte et la fermera, "il n'y a donc aucun outil de session à appeler". L'agent ne peut ni ouvrir une deuxième session, ni terminer celle-ci plus tôt. Le cycle de vie appartient à la plateforme, la seule partie qui sait quand une exécution est terminée.

Ce qui appartient à l'agent, en revanche, c'est son compte rendu du travail. Juste avant de terminer, il appelle report_outcome une fois, avec un résumé honnête, les décisions qui méritent un ADR, les suites à donner pour le travail non terminé, et les mémoires du briefing sur lesquelles il s'est appuyé. La description de l'outil lui demande de garder les constats circonstanciels hors des décisions, parce que les décisions sont rejouées aux sessions futures et qu'une note de débogage ne devrait engager personne.

Le bilan atterrit là où le travail a atterri

À la fin de l'exécution, Archyl rattache d'abord à la session les fichiers que l'exécution a modifiés. Cela corrige la plus discrète des trois lacunes. Les éléments qu'une session réserve sont déduits du texte de la tâche, et le texte de la tâche est une supposition. Les fichiers modifiés, eux, sont ce qui s'est passé. La mémoire va désormais aux éléments que le vrai travail a touchés, et non à tout ce que le ticket mentionnait.

Ensuite, il ferme la session, enregistre le résumé comme mémoire sur ces éléments, et crédite les mémoires que l'agent dit avoir utilisées, ce qui est le signal dont apprend le classement de la mémoire.

Les décisions ne sont enregistrées que si l'exécution a réussi. Elles deviennent de la mémoire du projet et ouvrent un Architecture Change Request en brouillon, pour qu'une personne relise la façon dont le modèle doit se mettre à jour. Une exécution échouée garde son résumé et ses suites à donner, qui sont ce dont la prochaine tentative a besoin, mais n'enregistre aucune décision. Un travail qui n'a pas abouti n'a rien à défendre.

La page de l'exécution montre tout cela dans une carte Bilan de la session de travail : résumé, décisions, suites à donner, éléments touchés, mémoires citées, et un lien vers le Change Request. Un élément détenu par une autre session est signalé Détenu par une autre session de travail, pour qu'une exécution qui a modifié du code dans la réservation de quelqu'un d'autre ne passe pas inaperçue.

Deux types d'agents, un seul modèle

C'est la pièce que plusieurs agents, une seule architecture cherchait à atteindre : une coordination entre des agents qui ne partagent jamais de processus, dans les deux sens.

Une exécution gérée ouvre sa session sous le nom managed-agent/<profile name>. Inversez la scène du début de ce billet : l'exécution planifiée est dans la Billing API quand un développeur y lance Claude Code. Son briefing porte désormais l'exécution comme un conflit :

- **Conflicts** (someone else is already working here):
  - Billing API — held by managed-agent/backend-fixer: fix rounding on prorated invoices

L'agent local est invité à se coordonner avant de modifier cet élément, la console Fleet affiche les deux sessions, et celle qui termine laisse une mémoire que l'autre lira la prochaine fois.

Aussi livré cette semaine

Brièvement, parce que le reste repose dessus. Les profils embarquent désormais des skills intégrés et des listes d'outils autorisés, si bien qu'un relecteur en lecture seule peut être limité à read_file, list_* et get_*. Les heartbeats du worker détectent les exécutions mortes et les nettoient, la clé d'API de chaque exécution est révoquée à la fin de l'exécution, et une exécution échouée publie quand même son travail sous forme de pull request en brouillon. Les exécutions tournent toujours dans le worker d'Archyl, sur le fournisseur d'IA de votre organisation quand le bring-your-own est activé.

Ce que ça ne fait pas

La coordination ne voit que les agents qui utilisent le harness. Une réservation existe parce qu'un agent a ouvert une session. Un agent qui modifie le dépôt sans session est invisible pour le gate, et une exécution qui respecte le travail des autres agents démarrera juste à côté de lui.

Le worker ne lance pas vos tests. Il dispose d'outils de fichiers sur l'espace de travail (lire, écrire, éditer, lister, grep) et d'aucun shell. Il ne peut ni builder le projet ni lancer la suite de tests, donc une carte de bilan propre signifie que les écritures ont passé le Guard, pas que le code compile. C'est toujours la CI qui fait ce travail.

Les décisions d'un agent ne sont pas relues. Une décision dans la carte de bilan reste une affirmation de l'agent tant que personne n'a relu le Change Request. Cette relecture est tout l'enjeu, pas une formalité.

Le Guard a besoin d'une référence. Sans dépôt lié, il n'y a pas de vérification des écritures, et un ensemble de règles de conformité vide laisse passer toutes les écritures.

Par où commencer

Choisissez un seul profil, celui qui tourne selon un planning sur du code que des gens modifient aussi à la main, et activez Respecter le travail des autres agents dans Coordination. Laissez les autres tels quels.

S'il refuse une exécution, le motif nomme l'agent et la tâche qui chevauchaient la sienne. Jusqu'ici, ce chevauchement serait passé sans que personne n'en entende parler.

Les exécutions d'agents gérées, les sessions de travail, le Guard et la mémoire font partie d'archyl. Chaque paramètre cité plus haut se trouve dans la documentation des exécutions d'agents gérées, et le côté local est décrit dans le guide du Harness. À lire aussi : plusieurs agents, une seule architecture, les sessions de travail pour les agents de code, la mémoire des agents de code, et le lancement des exécutions d'agents gérées.