Production agents: authorize the action, then verify the outcome

A production agent can perform exactly the tool call it intended and still fail the task. It can close an unresolved ticket, change the wrong resource, or repeat a write whose first result was lost. A successful API response answers only one part of the operational question.

Once an agent can change shared state, evaluate authority, observability, reversibility, and accountability as properties of the complete execution path. A more capable model may improve its proposals. It does not create permission, prove the target is current, or make an irreversible action recoverable.

The practical unit of approval is a bounded action against a defined state. “This agent may operate production” is too broad to explain what should happen when the state changes or the tool result is uncertain.

Bind permission to something the tool can enforce

Separate the request to propose a change from the authority to execute it. The execution boundary should validate the target, allowed operation, current state, scope, and relevant approval. Where the system supports a version precondition, a stale version should reject the action and require a new assessment. A free-form instruction to be careful cannot provide the same guarantee.

Consider a hypothetical agent authorized to adjust one deployment within a specified range. The proposal is reviewed against version A. Before execution, a person changes that deployment to version B. Applying the original proposal without reconciliation would use approval for a state that no longer exists. The tool should refuse the stale operation; the workflow should reread state and obtain whatever fresh authorization its policy requires.

Retrieved documents can also contain instructions. OWASP's prompt-injection guidance describes the risks of malicious instructions reaching the model through external material. Treat that material as evidence, not permission, and constrain tools independently of whether the model follows it.

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.

Give an uncertain result its own state

If a write times out, the destination may have applied it. Label the outcome unknown until it is reconciled. Repeating the write immediately can create a second action while leaving the first unexplained.

The reconciliation method depends on the destination. It may support an idempotency key, a durable operation identifier, or a readable state transition. Do not assume that every API offers those guarantees. When the result cannot be established safely, stop the workflow and hand the unresolved state to its owner.

Retries need their own limit and authorization boundary. Retrying observation is different from retrying a destructive action, and a retry that changes the requested operation is a new proposal. A plan-and-approval sequence is not automatically a transaction protocol.

Verification must be able to disagree with the agent

Define the desired service outcome before execution and give an independent check a way to reject the agent's completion claim. For a configuration change, that may include the accepted diff, the effective destination state, and a service check. For ticket resolution, it requires evidence about the original problem rather than the ticket's closed status.

Record enough to reconstruct the action: initiating request identifier, relevant policy and tool versions, target, approved parameters, execution identifier, result, and verification evidence. Record an explicit rationale when supplied; do not claim to reconstruct hidden model reasoning. Avoid copying credentials or whole private documents into the audit record.

Account for refusals and unverified outcomes separately. A correct refusal can show that a control worked, while a workflow that refuses every useful task may provide little operational value. A completion percentage that excludes difficult cases without explaining them obscures that tradeoff.

Prove containment before expanding scope

In a controlled rehearsal, stop the workflow between actions. Check whether queued work can still use cached authority, identify partial changes, and demonstrate recovery without relying on the stopped agent to assess its own work. A stop control is useful only if the responsible operator can reach it and understand what remains in flight.

Some actions cannot be rolled back. Deleting information or sending an external notification may require prevention, narrower scope, or explicit acceptance of irreversible consequences. Calling a compensating action “rollback” does not restore the original world.

Grant additional scope only when the team can explain how it will authorize, observe, contain, and own that scope. The agent skills guide develops the implementation contract for a particular capability; this decision determines whether that capability deserves production authority at all.

Agent execution contract

Rehearsal cases: stale target; permission expiry; tool timeout after a possible write; duplicate request; partial multi-step completion; malicious retrieved instruction; failed postcondition; unavailable stop path. For each, record expected rejection or containment and actual observed behavior. This is a contract template, not executable enforcement.