Optimize

Usa esta página para entender qué ocurre cuando una política de intención pide al agente que tome un camino mejor en lugar de solo pararlo.

De una frase a una regla Optimize

Escribe una frase que pida al agente un camino mejor, por ejemplo: «Si el agente ejecuta más de veinte comandos en un turno, dile que se detenga y resuma en qué punto está». OpenLatch la redacta como una política de intención con una regla Optimize, y muestra su steer junto a la frase en el paso Policy: el camino mejor, en el idioma de tu brief. Junto a ella aparecen casos de prueba que esperan Optimize, y la tarjeta de recurso pregunta qué resuelve la acción una vez que se ha orientado dos veces. Nada surte efecto hasta que ratificas la política, y editar el steer vuelve a leer la política de intención.

Una frase con un calificativo que el cliente no puede observar se rechaza, y se muestra su motivo, como con cualquier otra frase.

Lo que recibe el agente

En Enforce, el cliente deniega la acción antes de que se ejecute, a través del hook nativo del agente, y devuelve estas líneas como motivo, por el mismo campo que un Block:

Línea	Contenido
La frase	La frase que tu organización ratificó, en el idioma de su brief
El marco	Una línea fija en inglés que presenta la frase como una política de OpenLatch
El steer	El camino mejor que tu organización ratificó con la frase

La decisión se registra como Optimize, y la acción se convierte en una anomalía con veredicto Optimize. En Monitor, la acción se ejecuta, nada llega al agente, y el registro lleva el Optimize que habría recibido.

Como la frase en un Block, el steer pasa a formar parte del contexto del agente, así que escríbelo sabiendo que el agente y su proveedor de modelos lo leen.

Cómo se clasifica Optimize

Cuando estas reglas se activan en una acción	El veredicto
Una regla Block y una regla Optimize	Block
Una regla aplazada que resuelve con Ask, y una regla Optimize	Ask, con la regla Optimize listada en el registro
Una regla Optimize, sin regla Block	Optimize

Una regla Optimize cuya condición el cliente no puede leer permanece en silencio: las demás reglas, o la escalera de decisión, resuelven la acción. Una regla Optimize nunca pide al agente que declare un hecho.

Dos orientaciones, y después el recurso

Un agente puede volver a enviar sin cambios una llamada denegada. El cliente orienta la misma acción como máximo dos veces en una sesión. La tercera vez, el recurso de la política de intención la resuelve: Ask por defecto, o Block si lo elegiste en la tarjeta de recurso. Cada orientación queda registrada con su anomalía.

Por agente

El steer viaja en el campo que cada agente conectado ya usa para el motivo de un Block. Todavía no se ha medido en ningún agente si después llega al modelo del agente, y OpenLatch no afirma que el agente lo siga.

Agente	Nivel de control	Por dónde viaja el steer	El motivo de la denegación llega al modelo
Claude Code	Enforced en el plano de comandos	El motivo de su denegación nativa	Todavía no medido
Codex CLI, gestionado	Enforced en el plano de comandos	El motivo de su denegación	No medido
Codex CLI, autoservicio	Monitored en el plano de comandos hasta que el desarrollador confía en el hook de OpenLatch, y después Enforced en ese plano	El motivo de su denegación	No medido
Cursor	Enforced en el plano de comandos	El mensaje al agente de su denegación	No medido
Cline	Monitored en el plano de comandos	El motivo del skip del plugin	No medido
OpenCode	Monitored en el plano de comandos	El mensaje del error que lanza el plugin	No medido

Orientar nunca cambia el nivel de control de un agente. Donde una instalación es Monitored en el plano de comandos, la decisión se registra como Optimize, y el steer llega al agente solo en la medida en que ese agente carga el hook. Niveles de control explica cada nivel.

Solicitudes al modelo: solo se miden

En las solicitudes al modelo, una política de intención Optimize tiene la capacidad Medir y una de tres palancas, effort_clamp, context_edit o prefix_guard, medida en Monitor y en Enforce por igual y nunca aplicada.

Palanca	Lo que mide el relay de modelos
effort_clamp	En Monitor y en Enforce, si la solicitud pide más esfuerzo de razonamiento del que la frase permite, comparado con el valor predeterminado del modelo cuando la solicitud no fija ninguno
context_edit	En Monitor y en Enforce, si la gestión del contexto de la solicitud cambiaría, y una solicitud sin gestión del contexto no es medible
prefix_guard	En Monitor y en Enforce, si el prefijo en caché de la solicitud está en riesgo

Por cada solicitud al modelo, el relay registra un resultado por regla: cambiaría la solicitud, la dejaría sin cambios, la solicitud no es medible, la configuración de caché de la solicitud deja su prefijo fuera del alcance de la regla, o una regla anterior ya midió la solicitud. Nunca cambia una solicitud. La medición cubre el formato Anthropic Messages que usa Claude Code; en cualquier otro formato, el resultado no es medible.

En el panel de la AIP, cada política de intención medida indica cuántas solicitudes al modelo habría cambiado en los últimos siete días. Sin nada registrado muestra «Todavía no se ha medido ninguna solicitud al modelo», y cuando ningún resultado es medible, «No medible en las solicitudes de este agente».

Anomalías y notificaciones

Una decisión Optimize crea una anomalía con veredicto Optimize, o una anomalía de lo que habría ocurrido en Monitor, como hacen un Ask o un Block. Filtra la página Anomalies por veredicto para encontrarlas. Un canal de notificación las recibe a través de su alerta de anomalía cuando el filtro de veredictos de la alerta incluye Optimize; consulta Configurar canales de notificación.

Consulta también: Veredictos · Lo que recibe el agente en un Block · Referencia de AIP