How production agents handle stale approvals and uncertain writes

A reviewer approves an agent’s deployment change against version A. Before the tool executes it, another engineer updates the deployment to version B. The original proposal may still read perfectly well. The question is whether the approval still describes the action about to happen.

This hypothetical race is a useful place to begin evaluating a production agent. The model proposes work, a tool checks whether it is permitted now, the destination applies it, and an outcome check establishes the result. Each part answers a different question. Improving the proposal does not eliminate the need to check current state or determine what a timed-out write actually did.

For the deployment change, approval needs to identify both the permitted adjustment and version A, the state the reviewer examined. That gives the execution path something concrete to validate when circumstances change. It also makes additional authority a decision about a particular capability, rather than a general vote of confidence in the model.

Version preconditions connect approval to execution

The tool needs the exact target, operation, current state, permitted scope and relevant approval. Where a destination supports version preconditions, the request can name the version considered during review and reject execution if that version is stale. Rejection then returns the workflow to assessment, instead of silently carrying an old decision into a new situation.

In the deployment example, the agent is allowed to adjust one deployment within a specified range. Version B may have changed the basis for the adjustment even if the proposed value remains within that range. A version-aware refusal lets the workflow reread the target and obtain whatever fresh authorization policy requires. The useful behavior is the refusal and reassessment, not an attempt to make the old approval fit.

Kubernetes gives this hypothetical race a concrete implementation. A client updating a Deployment with HTTP PUT includes the metadata.resourceVersion it read. If someone changed the object in between, the API server rejects the stale update with 409 Conflict, as the API update documentation explains. The comparison occurs at the destination, so a change after the client’s last read still causes a conflict. A fresh read alone cannot close the gap before a later write; the destination needs to enforce the version precondition. For the agent, handling the conflict means reassessing the updated object under its authorization policy; simply substituting a new version without reassessment would bypass the state the reviewer approved.

Permission must also come from a source entitled to grant it. Retrieved documents can contain malicious instructions, as OWASP’s prompt-injection guidance explains. A document may be relevant evidence for a proposal without acquiring the power to authorize its own requested action. Independent tool controls preserve that distinction even if the model follows the wrong instruction.

Keep execution authority outside the model

Read diagram description

The model proposes a change. Independent controls bind permission to the exact target and current state; a separate outcome check establishes task success. A failed gate stops the write. Diagram labels: Evidence + request: Source material supplies facts, not permission; Model proposal: Exact target, action and supporting evidence; Independent execution gate: Validate identity, scope, approval and freshness; Bounded tool action: Record the request and reconcile uncertain results; Independent outcome check: Confirm the intended user or service result.

A timeout leaves the write’s outcome unknown

Suppose the refreshed deployment action is valid and the write is sent, but the response is lost. The destination may have applied it. Calling that outcome a failure invites a retry that could create a second change; calling it success claims evidence the workflow does not have. Unknown is a useful state because it directs the next step toward reconciliation.

The available method depends on the API. An idempotency key may identify a repeated request, a durable operation identifier may locate the result, or a readable state transition may establish the effect. Use the actual guarantees provided. When none can establish the result safely, stop the workflow and assign the unresolved action to an owner able to investigate it.

Retries also need bounds. Reading current state again can reduce uncertainty, while repeating a destructive operation can add to it. If a retry changes the operation, the proposal itself has changed and needs fresh assessment. A plan followed by approval does not automatically supply the transaction behavior needed after a lost response.

Service checks can contradict a completion claim

For the deployment change, define the intended service result before execution. The accepted diff and effective destination state can establish what configuration is present; a service observation is still needed to check whether that configuration produced the intended result. A successful tool response alone cannot settle either question. Those checks give the responder a way to reject the agent’s conclusion even after the uncertain write has been reconciled.

The action record should let another person reconstruct that distinction. Keep the initiating request identifier, policy and tool versions, target, approved parameters, execution identifier, result and verification evidence. If an explicit rationale was supplied, it can be retained as such, without claiming to recover hidden model reasoning. Credentials and unnecessary copies of private documents do not belong in that record.

Refusals and unverified outcomes need to remain visible alongside successes. A correct refusal can demonstrate that a control worked. A workflow that refuses nearly all useful tasks may also need a better task definition or different permitted scope. Reporting both facts lets the team improve usefulness without making difficult cases disappear from the completion rate.

Stopping queued and partially completed work

A controlled rehearsal can interrupt the deployment workflow between actions. The operator should be able to reach the stop control, identify partial changes and determine whether queued work can still use cached authority. Recovery needs evidence independent of the stopped agent, since relying on that agent to assess its own unfinished work defeats the purpose of containing it.

Deletion and external notification illustrate actions that cannot simply be rolled back; they may require prevention, narrower authority or explicit acceptance of irreversible consequences. A compensating action can change the situation again without restoring the original one. That difference belongs in the capability decision before the first execution.

The agent skills guide develops the implementation of an individual capability. The contract below brings its authority, evidence, containment and ownership requirements together so the production-access decision can be inspected.

An execution contract for the deployment action

The stale version and lost response are two rehearsal cases for this contract. Expired permission, duplicate requests and partial multi-step completion test related paths. Malicious retrieved instructions, failed postconditions and an unavailable stop control probe the boundaries from different directions. For each case, record the rejection or recovery expected and compare it with observed behavior. The table describes requirements; implementation still has to enforce them.

Production access can then be granted for the deployment action the tools actually enforce: a permitted adjustment against the reviewed version, with an operation record that survives a lost response and a service check after completion. Adding a new capability changes that combination of target, permission and recovery behavior, so it needs the same implementation work rather than inheriting trust from the first action.