The order changed after you approved it. What will the agent send?

Imagine a packaging manufacturer preparing a shipment. The cartons have been printed and packed; dispatch is waiting for release.

The customer approved the artwork yesterday. Quality checked it. The order is ready for release. An AI assistant prepares the instruction, and the operations manager clicks approve.

Then the salesperson receives a replacement artwork file from the customer, asking for it to be used on this order. The cartons on the pallets still carry the previously approved version.

The assistant attaches the new file to the order. The release approval is still green. Nobody has yet established whether the packed cartons can leave as they are or must be reworked.

Which version is about to leave the warehouse?

This is a useful question to ask during an agent demonstration. A person approved something. You still need to establish whether the system is about to do that same thing.

Open the approval and look at what it covers

“Release order 4821” looks clear until the order changes.

The manager approved dispatch against the artwork available at that point. That does not settle whether the customer will accept the cartons already printed, whether production can rework them, or who pays for that work. Quality can compare the two artwork files; the commercial owner still needs to resolve the customer’s request and any charge. One green status cannot answer all of those questions.

For this example, the approval screen should identify the release being requested and show the facts that matter to it. The order number alone is insufficient. Include the relevant artwork version, destination and other release conditions agreed by the people responsible for the process. Make the supporting documents accessible from that screen.

The exact fields depend on the action. Releasing a shipment and drafting an internal update do not warrant the same approval procedure.

OWASP's Transaction Authorization Cheat Sheet describes a principle it calls “What You See Is What You Sign”: users should be able to identify and acknowledge significant transaction data. Its guidance concerns digital transactions, including financial ones. The same design question is useful here: can the approver see what the system will actually execute?

A summary written by the agent may help someone read the case. Keep the underlying facts available. The reviewer needs a way to notice that the summary refers to the new artwork while the packed cartons carry the old version.

A new attachment can make yesterday's yes unusable

Return to the shipment. Artwork version 3 was approved. Version 4 arrived afterwards.

Keeping the old approval valid would require an explicit reason grounded in the company's policy. Perhaps a particular administrative change genuinely falls within an existing delegation. Perhaps it changes something that quality or the customer must approve again. The system should follow that distinction, rather than letting the assistant decide that the change looks small.

Agree which changes invalidate each approval before connecting the agent to the release action. Where a material field changes, stop the pending action, show the difference and send the new version through the relevant approval path.

This need not send the entire order back to the managing director. If quality owns artwork approval, route that decision to quality. Preserve the authority staff already have. The implementation should make that authority easier to exercise, without quietly expanding or removing it.

Time matters too. An approval may have been based on stock, credit or a delivery slot that is no longer available. Decide which conditions require a fresh check and how long the authorisation remains usable. There is no sensible universal expiry period for every business action.

OWASP recommends invalidating authorisation when transaction data changes and placing a final check immediately before execution. That second check matters: the order can change while the instruction waits in a queue.

Ask where the system refuses the action

“The agent has been instructed to ask first” is an incomplete answer.

Ask the implementation team what prevents the release if the approval is missing, expired or tied to a different version. The application performing the action needs to enforce the rule. A sentence in a prompt cannot provide that enforcement by itself.

In the shipment example, the release mechanism would check the approved version against the version it is being asked to release. A mismatch should leave the action stopped, with a reason someone can resolve. The agent can prepare the explanation and route the case. It should not bypass the check by finding another tool that can perform the same write.

OWASP's guidance on excessive agency identifies excessive permissions and autonomy as sources of risk in LLM systems. Give the assistant only the functions and access required for the agreed task. Examine the alternative paths as well as the button shown in the demonstration.

This is also where software meets the warehouse. Recording “shipment stopped” in one application does not prove that the wrapped pallets have been held. The person responsible for dispatch needs a reliable instruction and a way to confirm what happened. Include that step if the workflow reaches physical operations.

Change one thing during the demonstration

Use a test environment or a simulation that cannot release a real order. Ask the supplier to prepare the shipment, obtain approval, then change a significant field before execution.

Start with the artwork version. The old approval should no longer authorise release of the revised artwork. Inspect the actual action record, rather than accepting a reassuring chat reply.

Then try a different failure: revoke the approval while the action is waiting. Does execution stop? Can the operator see why?

Finally, let an attempt time out after it may have reached the destination system. Ask how the team finds out whether the release occurred before trying again. Repeating a consequential action merely because the assistant did not receive a reply can create another problem. The recovery process needs a way to reconcile the destination's state.

These exercises do not certify the whole system. They reveal whether the proposed controls exist and whether the people operating them understand the failure states. Add representative cases from your own process before accepting the implementation.

Keep the evidence from the test: what was approved, what changed, what the executing system refused, and how the operator resolved it. That gives you a case to rerun when the rules or software change.

Bring one changed order

You can begin this work without cataloguing every possible exception in the company. Choose one recurring action where a late change matters. Bring the original request, its revision and the approval path, with sensitive details removed.

Work through who can approve each decision and what would make that approval obsolete. Then ask the team building the agent to demonstrate those boundaries.

If that is the workflow you are considering, request a Strategy Session. Bring the changed order as well as the clean one used in the demo.

Related reading

Your company runs on rules nobody ever wrote down covers the broader work of making authority and operating rules explicit. This article concentrates on keeping an approval attached to the action it actually authorises.