The approval was for version A. The agent is looking at B.

The reviewer has said yes. An agent is about to adjust a deployment's capacity, using the version the reviewer examined: version A. Before it sends the change, another engineer saves version B. Nothing on the approval page has changed. The deployment has.

In this hypothetical race, a good proposal is no longer enough. Permission needs to stay attached to the action and state that were approved. The model can propose the work; a separate execution control must decide whether it is allowed now. Then the destination shows what it applied, and the service shows whether that helped. Each has a different question to answer.

The approval saw version A. Check what the write will see.

For our capacity adjustment, record the exact target, allowed action, parameter range and version A. A request can still ask for a number inside the permitted range while acting on a deployment whose circumstances have changed. The old approval cannot quietly become approval for version B.

Reading the deployment again might reveal B. But imagine another engineer saving C just after that read. To close this particular gap, the destination must check a version condition as it accepts the write, not leave the agent to hope its last look is still current.

Kubernetes provides that check for a Deployment update sent with HTTP PUT, a request to replace the stored object. The client includes the metadata.resourceVersion it read. If the stored resource has changed, the API server rejects the stale request with 409 Conflict, as the update documentation explains. The rejected request is a chance to notice that the reviewer and the tool were looking at different states.

Now reassess the updated object under the authorization policy. Simply copying its new version number into the request and resending would defeat the point: the destination's version check would pass, but the reviewer still would not have approved that changed state.

Also ask where the permission came from. A document retrieved to help explain the deployment might contain malicious instructions, a risk described in OWASP's prompt-injection guidance. Those are instructions hidden in material the model reads, not a new source of authority. The document can supply facts. Independent tool controls must keep it from approving its own proposed action, even if the model follows its wording.

The proposal, permission and result have different jobs

Follow the proposal through the diagram

Source material contributes facts, not permission. The model proposes an exact target and action with supporting observations. An independent execution gate checks identity, scope, approval and freshness. The bounded tool action records its request and reconciles uncertain results. A separate outcome check asks whether the intended user or service result occurred. A failed gate stops the write.

The lost reply leaves two possible histories

Suppose the revised action now passes its checks and goes to the destination. Then its reply disappears. Perhaps the deployment changed and the answer was lost. Perhaps the request never took effect. The caller has the same silence in both cases, but sending the change again may have very different consequences.

Give that result a name: unknown. Where the destination supports it, an idempotency key identifies the operation so a repeated request can be recognized under that service's documented rules. A durable operation ID may locate the earlier result; a readable state transition may also establish what happened. Amazon's explanation of idempotent APIs describes the approach and limits, including reuse of an identifier for a different intended operation.

An ID written only in the agent's log cannot make the destination recognize a duplicate. Use the guarantee the actual interface provides. If no supported check can safely establish the result, stop further writes and hand the original request and its records to a named owner who can investigate.

Limit retries too. A further read may settle the uncertainty; another destructive write may create more of it. Changing what the request asks for is a new proposal to assess, not a convenient way to reuse yesterday's permission.

A changed deployment is not yet a healthier service

At last, suppose the destination confirms the capacity change. That answers one question, not all of them. Did overload improve? Define the intended service result before making the change, then observe the affected operation afterward. The requested change can be applied exactly while the service still fails the test that made it worth doing.

Keep the initiating request, policy and tool versions, target, approved parameters, execution ID, result and verification records together. If the agent supplied an explicit rationale, label it as that explanation, not as recovered hidden model reasoning. Leave credentials and unnecessary private documents out.

A refusal belongs in this account as well. It can show that a limit held while the useful work remains undone. Report refused actions, unknown results and accepted outcomes together. Otherwise the team may improve the apparent success rate merely by losing sight of the awkward cases.

Find out what keeps running after the stop

In a controlled rehearsal, interrupt the workflow between actions. Can the operator reach the stop control? Can they identify partial changes and see whether queued work still has usable permission? They need observations outside the stopped agent to answer those questions. Ending its conversation is not proof that the work stopped.

Nor does every effect have an undo button. Deleted information or a notification already sent may require prevention, a narrower scope, or explicit acceptance of that consequence before acting. A compensating action changes the situation again; it does not necessarily return it to the original state. That limitation belongs in the decision, not in a surprise discovered during recovery.

The agent skills guide develops a reusable capability. For this wider workflow, the agreement between its owners and its execution controls needs four parts:

Rehearse stale versions, expired permission, duplicate requests, lost replies and partly completed sequences. Include malicious instructions in retrieved material, a service that still fails after the change, and an unreachable stop control. Compare the expected refusal or recovery with what actually happens. The table tells the team what to build; only the implementation can make those limits hold.

When the version-A approval meets version B, someone can now explain why the write stopped. When a reply goes missing, someone still owns the unresolved operation. And when the change finally lands, the service gets a separate check. The team is no longer asking one confident answer to stand in for all three.