Optimize

Use this page to understand what happens when an intent policy asks the agent to take a better path instead of only stopping it.

From a sentence to an Optimize rule

Write a sentence that asks the agent for a better path, for example: “If the agent runs more than twenty commands in one turn, tell it to stop and summarize where it stands.” OpenLatch drafts it as an intent policy with an Optimize rule, and shows its steer beside the sentence on the Policy step: the better path, in the language of your brief. Test cases that expect Optimize appear beside it, and the fallback card asks what settles the action once it has been steered twice. Nothing takes effect until you ratify the policy, and editing the steer reads the intent policy again.

A sentence with a qualifier the client cannot observe is refused, and its reason is shown, as for any other sentence.

What the agent receives

In Enforce, the client denies the action before it runs, through the agent’s native hook, and returns these lines as its reason, through the same field as a Block:

Line	Contents
The sentence	The sentence your organization ratified, in the language of its brief
The frame	A fixed line in English naming the sentence as an OpenLatch policy
The steer	The better path your organization ratified with the sentence

The decision is recorded as Optimize, and the action becomes an anomaly with an Optimize verdict. In Monitor, the action runs, nothing reaches the agent, and the record carries the Optimize it would have received.

Like the sentence on a Block, the steer becomes part of the agent’s context, so write it knowing that the agent and its model provider read it.

How Optimize ranks

When these rules fire on one action	The verdict
A Block rule and an Optimize rule	Block
A deferred rule that settles by Ask, and an Optimize rule	Ask, with the Optimize rule listed in the record
An Optimize rule, and no Block rule	Optimize

An Optimize rule whose condition the client cannot read stays silent: the other rules, or the decision ladder, settle the action. An Optimize rule never asks the agent to declare a fact.

Two steers, then the fallback

An agent may send a denied call again unchanged. The client steers the same action at most twice in a session. The third time, the intent policy’s fallback settles it: Ask by default, or Block if you chose it on the fallback card. Each steer is recorded with its anomaly.

Per agent

The steer travels in the field each wired agent already uses for a Block’s reason. Whether it then reaches the agent’s model is not yet measured on any agent, and OpenLatch does not claim that the agent follows it.

Agent	Control level	Where the steer travels	Deny reason reaches the model
Claude Code	Enforced on the command plane	The reason of its native deny	Not yet measured
Codex CLI, managed	Enforced on the command plane	The reason of its deny	Not measured
Codex CLI, self-serve	Monitored on the command plane until the developer trusts the OpenLatch hook, then Enforced on that plane	The reason of its deny	Not measured
Cursor	Enforced on the command plane	The message to the agent of its deny	Not measured
Cline	Monitored on the command plane	The reason of the plugin’s skip	Not measured
OpenCode	Monitored on the command plane	The message of the error the plugin raises	Not measured

Steering never changes an agent’s control level. Where an install is Monitored on the command plane, the decision is recorded as Optimize, and the steer reaches the agent only as far as that agent loads the hook. Control levels explains each level.

Model requests: measured only

On model requests, an Optimize intent policy has the capability Measure and one of three levers, effort_clamp, context_edit or prefix_guard, measured in Monitor and in Enforce alike and never applied.

Lever	What the model relay measures
effort_clamp	In Monitor and in Enforce, whether the request asks for more reasoning effort than the sentence allows, compared with the model’s own default when the request sets none
context_edit	In Monitor and in Enforce, whether the request’s context management would change, a request without context management being not measurable
prefix_guard	In Monitor and in Enforce, whether the request’s cached prefix is at risk

For each model request, the relay records one result per rule: it would change the request, it would leave it unchanged, the request is not measurable, the request’s cache settings put its prefix out of the rule’s reach, or an earlier rule already measured the request. It never changes a request. Measurement covers the Anthropic Messages format that Claude Code uses; on any other format, the result is not measurable.

In the AIP drawer, each measured intent policy shows how many model requests it would have changed over the last seven days. With nothing recorded yet it reads “No model requests measured yet”, and when every result is not measurable it reads “Not measurable on this agent’s requests”.

Anomalies and notifications

An Optimize decision creates one anomaly with an Optimize verdict, or a would-have one in Monitor, as an Ask or a Block does. Filter the Anomalies page by verdict to find them. A notification channel receives them through its anomaly alert when the alert’s verdict filter includes Optimize; see Set up notification channels.

Related: Verdicts · What the agent receives on a Block · AIP reference