Optimize

Cette page explique ce qui se passe quand une politique d’intention demande à l’agent de prendre un meilleur chemin au lieu de seulement l’arrêter.

D’une phrase à une règle Optimize

Écrivez une phrase qui demande à l’agent un meilleur chemin, par exemple : « Si l’agent exécute plus de vingt commandes en un tour, dis-lui de s’arrêter et de résumer où il en est. » OpenLatch la rédige comme une politique d’intention avec une règle Optimize, et affiche son steer à côté de la phrase à l’étape Policy : le meilleur chemin, dans la langue de votre brief. Des cas de test qui attendent Optimize apparaissent à côté, et la carte de repli demande ce qui tranche l’action une fois qu’elle a été orientée deux fois. Rien ne prend effet tant que vous n’avez pas ratifié la politique, et modifier le steer relit la politique d’intention.

Une phrase dont un qualificatif n’est pas observable par le client est refusée, et sa raison est affichée, comme pour toute autre phrase.

Ce que reçoit l’agent

En Enforce, le client refuse l’action avant son exécution, par le hook natif de l’agent, et renvoie ces lignes comme raison, par le même champ qu’un Block :

Ligne	Contenu
La phrase	La phrase que votre organisation a ratifiée, dans la langue de son brief
Le cadre	Une ligne fixe en anglais qui présente la phrase comme une politique OpenLatch
Le steer	Le meilleur chemin que votre organisation a ratifié avec la phrase

La décision est enregistrée comme Optimize, et l’action devient une anomalie au verdict Optimize. En Monitor, l’action s’exécute, rien n’atteint l’agent, et l’enregistrement porte l’Optimize qu’elle aurait reçu.

Comme la phrase sur un Block, le steer entre dans le contexte de l’agent : écrivez-le en sachant que l’agent et son fournisseur de modèle le lisent.

Comment Optimize se classe

Quand ces règles se déclenchent sur une action	Le verdict
Une règle Block et une règle Optimize	Block
Une règle différée qui tranche par Ask, et une règle Optimize	Ask, avec la règle Optimize listée dans l’enregistrement
Une règle Optimize, sans règle Block	Optimize

Une règle Optimize dont le client ne peut pas lire la condition reste muette : les autres règles, ou l’échelle de décision, tranchent l’action. Une règle Optimize ne demande jamais à l’agent de déclarer un fait.

Deux orientations, puis le repli

Un agent peut renvoyer à l’identique un appel refusé. Le client oriente la même action au plus deux fois dans une session. La troisième fois, le repli de la politique d’intention la tranche : Ask par défaut, ou Block si vous l’avez choisi sur la carte de repli. Chaque orientation est enregistrée avec son anomalie.

Par agent

Le steer passe par le champ que chaque agent raccordé utilise déjà pour la raison d’un Block. On n’a encore mesuré sur aucun agent s’il atteint ensuite le modèle de l’agent, et OpenLatch n’affirme pas que l’agent le suit.

Agent	Niveau de contrôle	Par où passe le steer	La raison du refus atteint le modèle
Claude Code	Enforced sur le plan de commande	La raison de son refus natif	Pas encore mesuré
Codex CLI, géré	Enforced sur le plan de commande	La raison de son refus	Non mesuré
Codex CLI, en libre-service	Monitored sur le plan de commande jusqu’à ce que le développeur fasse confiance au hook OpenLatch, puis Enforced sur ce plan	La raison de son refus	Non mesuré
Cursor	Enforced sur le plan de commande	Le message à l’agent de son refus	Non mesuré
Cline	Monitored sur le plan de commande	La raison du skip du plugin	Non mesuré
OpenCode	Monitored sur le plan de commande	Le message de l’erreur que lève le plugin	Non mesuré

L’orientation ne change jamais le niveau de contrôle d’un agent. Là où une installation est Monitored sur le plan de commande, la décision est enregistrée comme Optimize, et le steer n’atteint l’agent que dans la mesure où cet agent charge le hook. Niveaux de contrôle explique chaque niveau.

Requêtes de modèle : seulement mesurées

Sur les requêtes de modèle, une politique d’intention Optimize a la capacité Mesurer et l’un de trois leviers, effort_clamp, context_edit ou prefix_guard, mesuré en Monitor comme en Enforce et jamais appliqué.

Levier	Ce que mesure le relais de modèle
effort_clamp	En Monitor comme en Enforce, si la requête demande plus d’effort de raisonnement que la phrase ne le permet, comparé à la valeur par défaut du modèle quand la requête n’en fixe aucune
context_edit	En Monitor comme en Enforce, si la gestion du contexte de la requête changerait, une requête sans gestion du contexte n’étant pas mesurable
prefix_guard	En Monitor comme en Enforce, si le préfixe en cache de la requête est menacé

Pour chaque requête de modèle, le relais enregistre un résultat par règle : elle changerait la requête, elle la laisserait inchangée, la requête n’est pas mesurable, les réglages de cache de la requête placent son préfixe hors de portée de la règle, ou une règle précédente a déjà mesuré la requête. Il ne change jamais une requête. La mesure couvre le format Anthropic Messages qu’utilise Claude Code ; sur tout autre format, le résultat n’est pas mesurable.

Dans le panneau de l’AIP, chaque politique d’intention mesurée indique combien de requêtes de modèle elle aurait changées au cours des sept derniers jours. Sans rien d’enregistré, il affiche « Aucune requête de modèle mesurée pour l’instant », et quand aucun résultat n’est mesurable, « Non mesurable sur les requêtes de cet agent ».

Anomalies et notifications

Une décision Optimize crée une anomalie au verdict Optimize, ou une anomalie de ce qui aurait eu lieu en Monitor, comme le font un Ask ou un Block. Filtrez la page Anomalies par verdict pour les trouver. Un canal de notification les reçoit par son alerte d’anomalie quand le filtre de verdicts de l’alerte comprend Optimize ; voir Configurer les canaux de notification.

Voir aussi : Verdicts · Ce que reçoit l’agent sur un Block · Référence des AIP