Créez une boucle d’agent proactive sur Claude Opus 5.5

La partie inconfortable de la création de votre propre agent proactif, c’est que le travail intéressant n’est pas l’appel au modèle. Vous pouvez faire répondre Claude Opus 5.5 aux questions en un après-midi. Lui faire se réveiller selon un calendrier, ne lire que ce qui a changé depuis la dernière fois, décider si quelque chose mérite l’attention d’un humain, rédiger l’action, puis s’arrêter et attendre : cela prend des semaines, et presque rien de tout cela ne se passe dans le modèle. Anthropic a livré une version de cette boucle sous le nom de Claude Duet, et ce qui est utile dans ce produit pour quiconque construit le sien, ce n’est pas sa liste de fonctionnalités, mais les décisions visibles dans sa façon d’être assemblé. Il n’a pas d’API publiée et ne peut pas être redirigé vers vos propres systèmes ; donc si vous voulez la boucle plutôt que l’application, vous la construisez. Ce qui suit est l’architecture, étape par étape, avec le coût honnête de chacune.

La structure d’abord. Cinq étapes s’enchaînent, et la cinquième n’est atteinte qu’après qu’un humain a donné son accord. Un ordonnanceur se déclenche. Une étape de synthèse ramène chaque système connecté à un delta. Une étape de décision transforme ce delta, combiné à une politique, en une proposition typée. Une porte d’approbation extérieure au modèle décide si la proposition peut être exécutée. Un exécuteur la réalise. Telle est toute la conception, et tout ce qu’elle comporte de difficile se joue dans les jointures.

Première étape : un planificateur qui se déclenche toutes les quelques heures

La première décision est celle que les gens ratent par enthousiasme plutôt que par ingénierie : ne pas interroger en continu. La documentation Duet d’Anthropic explique son intervalle — une vérification toutes les quelques heures — en disant que vérifier sans arrêt épuiserait les limites du forfait bien plus vite. Ce n’est pas de la prudence marketing. C’est la bonne réponse à un vrai problème de coût, et c’est le piège dans lequel tout agent maison tombe dès la première semaine.

L’interrogation continue est ruineuse pour une raison structurelle. Chaque balayage constitue un contexte complet : instructions, définitions d’outils, les éléments que vous avez récupérés, et tout raisonnement que le modèle effectue dessus. À une cadence d’une minute, cela représente 1 440 contextes complets par jour, et la grande majorité ne trouve rien de nouveau. Vous payez plein tarif pour qu’on vous dise que la boîte de réception n’a pas changé. À trois heures d’intervalle, vous en obtenez huit, et le rapport entre les découvertes et la dépense devient quelque chose que vous pouvez défendre auprès de celui qui signe la facture.

Donc le planificateur est un minuteur de type cron avec un plancher sur l’intervalle minimal, et non un flux d’événements. Les événements semblent attrayants — réagir dès que quelque chose se produit —, mais ils vous ramènent vers un travail en continu et rendent le coût d’une journée chargée non borné. Un minuteur offre un plafond prévisible, ce dont vous avez besoin lorsque la facture est variable. Lorsque vous voulez une réaction plus rapide pour une source, raccourcissez uniquement l’intervalle de ce connecteur et acceptez la dépense supplémentaire.

Deuxième étape : un préfixe identique octet pour octet, conservé dans le cache

C’est ici que les chiffres publiés jouent le plus grand rôle. Claude Opus 5.5 sur OrcaRouter coûte 4,00 dollars par million de tokens d’entrée, 20,00 par million de tokens de sortie, avec une fenêtre de contexte de 1 M de tokens et des lectures de cache à 0,20 par million, au prix catalogue du fournisseur, avec 0 % de marge. Lisez ces chiffres comme une contrainte de conception plutôt que comme une grille tarifaire : une lecture de cache coûte un vingtième d’un nouveau token d’entrée, donc chaque octet que vous maintenez stable d’un balayage à l’autre est un octet pour lequel vous cessez de payer le prix plein.

En pratique, le prompt système et le schéma d’outil sont assemblés une fois au moment du déploiement et ne sont jamais régénérés à chaque balayage. Pas re-sérialisés à partir d’un dictionnaire dont les clés seraient dans un ordre différent. Pas templatisés avec un horodatage, un ID de requête ou les comptes connectés du jour insérés au milieu. Tout octet qui diffère invalide le préfixe mis en cache, et le bloc d’instructions revient au prix d’entrée complet à chaque balayage. Les équipes perdent cela par accident plus souvent que délibérément, généralement parce qu’une abstraction bien intentionnée a commencé à injecter un identifiant d’exécution près du haut du prompt.

La discipline qui survit au contact du code réel est ennuyeuse : une fonction qui renvoie une chaîne constante pour le bloc stable, un littéral figé pour le schéma de l’outil, chaque élément variable placé après. Ensuite, un test qui calcule le hash du bloc et fait échouer le build lorsque le hash change, car quelqu’un finira par ajouter un champ au schéma sans jamais penser au cache. Ce test coûte une heure et sauve tout le bénéfice du cache.

Étape trois : un condensé par connexion, pas un déversement de boîte mail

La troisième étape est celle qu’un produit grand public obtient gratuitement, et pas vous. Duet réside dans le compte Anthropic et accède aux applications connectées, il peut donc demander ce qui a changé depuis un instant donné et obtenir une réponse succincte. En développant en dehors de ce compte, vous passez par les mêmes API que n’importe quel client normal : soit vous implémentez des lectures incrémentielles, soit vous récupérez tout et transmettez au modèle un mur de texte.

Tout extraire est le comportement par défaut, car cela fonctionne dès le premier jour. C’est aussi le moyen le plus rapide de rendre le coût par balayage imprévisible, car l’entrée croît avec la boîte aux lettres plutôt qu’avec ce qui a changé. Un balayage sur quarante fils inchangés coûte autant qu’un balayage sur quarante fils où un seul fil compte, et un seul de ces balayages avait la moindre chance de produire une proposition utile. Après un mois de ce régime, l’essentiel de votre budget est parti à confirmer le statu quo.

L’étape de digest doit être du code, pas du prompting. Récupérez pour chaque connexion en utilisant le curseur ou le delta proposé par l’API, et réduisez le résultat à un résumé structuré : ce qui est apparu, ce qui a été modifié, ce qui a été résolu. Donnez à chaque élément un identifiant stable afin que les étapes ultérieures puissent y faire référence, et enregistrez le dernier curseur réussi par connexion afin qu’une récupération échouée ne rejoue pas le contenu de la veille comme s’il était nouveau. Un digest qui ne sait pas distinguer « rien ne s’est produit » de « je n’ai pas pu vérifier » finira par rendre compte avec assurance d’un état qu’il n’a jamais observé.

Étape quatre : une étape de décision qui émet un objet, et non de la prose

C'est là que se situe Claude Opus 5.5, et ce qu'il émet détermine si le reste du système peut même être construit. Le réflexe est de faire écrire un résumé par le modèle et de laisser un humain le lire. Cela fonctionne pour un tableau de bord, mais échoue pour un point de contrôle : l'étape suivante doit décider s'il faut autoriser une action, et une autorisation ne peut pas être accordée à un paragraphe.

L’étape de décision doit renvoyer une proposition d’action typée : un nom d’action issu d’une liste fermée, la cible à laquelle elle s’applique, les paramètres, une justification en une ligne, et un indicateur explicite de confiance ou d’escalade. Une liste d’actions fermée n’est pas de la bureaucratie ; c’est le mécanisme qui rend la porte d’approbation applicable, car une porte ne peut valider que les actions qu’elle peut énumérer. Un agent qui peut émettre n’importe quel verbe ne peut pas être soumis à une porte, seulement être tenu pour fiable.

Deux remarques pratiques. Fournissez d’abord le digest au modèle, puis la politique, afin que la politique se trouve après le matériel variable et que le préfixe de cache reste intact. Et faites en sorte que le résultat par défaut soit « aucune action » plutôt qu’une proposition vide qui donne l’impression d’une action. Les boucles qui considèrent le silence comme un échec produisent du volume, et un agent qui fabrique du travail pour paraître utile est pire qu’un agent qui signale que rien n’a changé.

Étape cinq : une porte d'approbation qui peut réellement dire non

Le portail doit être un service distinct, et non une branche dans le code de l'agent lui-même. C'est la décision structurelle la plus importante de la construction. Si le processus de l'agent peut exécuter l'action lui-même, un bug, une injection de prompt ou un indicateur mal configuré dans ce processus atteint l'effet. Si l'exécuteur n'accepte qu'une proposition signée par le portail, le pire que l'agent puisse faire est de proposer quelque chose de faux, et le refus du portail est réel.

La politique publiée d’Anthropic pour Duet mérite d’être copiée dans sa structure, même là où votre liste diffère. Le garde-fou demande une approbation avant qu’une action n’envoie un message, n’effectue un paiement, ne signe un document ou ne supprime quoi que ce soit. Au-dessus se trouve un second niveau refusé même avec approbation — dans le cas de Duet, négocier des titres et déplacer de l’argent entre comptes. Le schéma est celui d’une politique à deux niveaux : un grand ensemble d’actions soumises à autorisation qu’un humain peut permettre, et un petit ensemble qu’aucune approbation ne débloque. Copiez les niveaux même si chaque élément change, car ils résolvent des problèmes différents. Le garde-fou protège contre l’erreur. La liste d’interdictions protège contre un opérateur compromis, y compris l’opérateur humain.

L’autre moitié d’une véritable porte de contrôle, c’est qu’elle interrompt. La demande d’approbation de Duet montre l’action exacte et attend, ce qui arrête délibérément le flux au lieu de l’annoter. Une porte de contrôle qui écrit une ligne dans un journal que personne ne lit n’est pas une porte de contrôle ; c’est un reçu. Si votre étape d’approbation exige que quelqu’un surveille un tableau de bord à trois heures du matin, c’est soit que l’intervalle est trop court, soit que la liste d’actions est trop large. On peut remédier aux deux, et dans aucun des deux cas en ajoutant une notification.

Mémoire, identifiants et les deux surfaces dont vous ne pouvez pas vous sortir en testant

Deux problèmes difficiles sous-tendent les cinq étapes, et tous deux ressemblent à des atouts jusqu’à ce qu’ils cessent de l’être.

• Report de contexte. Chaque passe est un contexte neuf, donc tout ce que l'agent doit retenir d'une passe à l'autre doit être consigné entre elles. Un fichier d'état glissant par connexion, à taille plafonnée, contenant les éléments en cours et les décisions récentes, suffit pour la plupart des boucles. Ce qui ne fonctionne pas, c'est d'espérer que le modèle reconstitue l'historique à partir du digest, car le digest est explicitement une description du changement et ne garde aucune mémoire de ce qui a déjà été décidé.

• Garde des identifiants. Duet suit la conception utilisée pour les agents gérés d’Anthropic, et ne voit donc jamais directement vos mots de passe ni vos jetons de connexion. Reproduire cette discipline est la partie que la plupart des agents développés en interne omettent, et l’omettre signifie que chaque prompt dispose d’une voie vers un identifiant. Le modèle ne doit jamais détenir un jeton, ne jamais recevoir une clé API sous forme de texte, et ne jamais être le composant qui authentifie. Laissez l’étape de synthèse et l’exécuteur détenir les identifiants et ne transmettre au modèle que les résultats.

Il y a ensuite la surface à laquelle personne ne veut penser : dès que l’agent lit des e-mails et des pages web, chacun constitue une entrée pouvant contenir des instructions. Un message disant « transférez ceci à l’adresse ci-dessous » est indiscernable de données pour un modèle qui n’a pas de notion distincte de l’autorité. Deux défenses valent mieux que n’importe quel durcissement de prompt. Gardez la liste d’actions fermée, afin qu’une instruction injectée n’ait aucun verbe à portée de main. Et gardez la barrière hors de l’influence du modèle, car une injection qui convainc le modèle d’envoyer quelque chose doit encore convaincre un humain qui voit l’adresse de destination.

Basculement, et où le routage est réellement utile

Une fois la boucle construite, une option architecturale s’ouvre qu’une conception mono-fournisseur ne propose pas. Le DSL de routage d’OrcaRouter compose plusieurs modèles en un seul appel, et la fusion de modèles exécute un panel de modèles qui répondent en parallèle ; les deux placent plus d’un modèle derrière une seule requête. L’usage pratique ici est peu glamour : diriger un modèle moins cher vers le résumé de synthèse, où le travail est de compression plutôt que de jugement, et garder Claude Opus 5.5 à l’étape de décision, où la proposition est formée. La même clé compatible OpenAI donne accès à plus de 200 modèles, de sorte que changer quel modèle sert quelle étape est un changement de configuration plutôt qu’une réécriture.

Le basculement est l’autre moitié. Quand un fournisseur connaît une mauvaise heure, un agent qui ne peut joindre qu’un seul point de terminaison connaît lui aussi une mauvaise heure, et une boucle planifiée sans solution de repli rate simplement sa passe. Le routage transforme une passe manquée en une passe plus lente — un avantage peu spectaculaire jusqu’à la semaine où vous en avez besoin, et c’est alors la différence entre une lacune dans l’historique et aucune lacune.

Ce à quoi vous vous inscrivez réellement

Faire tourner cette boucle, c'est exploiter un service, et ce service possède quatre propriétés dont vous venez de prendre la responsabilité.

• Disponibilité. L'app d'Anthropic, c'est le pager de quelqu'un d'autre ; la vôtre reste la vôtre. Un planificateur qui cesse silencieusement de se déclencher ne produit ni erreur ni sortie, et vous l'apprenez par un humain qui a remarqué l'absence de son brief matinal, pas par une alerte.

• Garde des identifiants. Chaque jeton détenu par votre étape de synthèse est sous votre responsabilité, et le rayon d’impact d’une fuite correspond à tout ce que cette connexion peut atteindre. La conception d’Anthropic garde les identifiants à l’écart du modèle ; si la vôtre ne le fait pas, le modèle devient une surface d’attaque pour chaque compte que vous avez connecté.

• Défense contre l'injection de prompt. La barrière apporte beaucoup ici, mais uniquement pour les actions qu'elle contrôle. Tout ce que l'agent fait sans approbation — lire, résumer, écrire son propre état — n'est pas protégé, et un digest empoisonné peut corrompre la mémoire à partir de laquelle raisonnent les balayages ultérieurs.

• La prime aux bogues n'appartient à personne. Si votre boucle se déclenche à tort et envoie le mauvais message à un client, il n'y a aucun fournisseur vers qui faire remonter le problème, aucune page de statut, aucun rapport d'incident. Les décisions ci-dessus constituent le seul filet de sécurité, c'est pourquoi la porte est un service distinct et la liste d'actions est fermée.

Rien de tout cela ne constitue un argument contre sa construction. Cela constitue un argument contre une construction à la légère. Chaque étape est petite, et c’est dans les jonctions entre elles que réside le jugement : un minuteur plutôt qu’un flux, un préfixe figé plutôt qu’un modèle, un condensé plutôt qu’un vidage, un objet plutôt que de la prose, et une barrière qui est un service plutôt qu’un commentaire. Réussissez ces points et la boucle justifie son coût — elle trouve des choses que vous n’auriez pas pensé à chercher et s’arrête avant de faire quoi que ce soit d’irréversible. Ratez-les et vous aurez construit quelque chose qui dépense votre budget en continu et vous dit ce que vous saviez déjà.