What may a shopping agent decide after the purchase?

An office coordinator asks a shopping agent to request the return of one supply item. The merchant offers store credit or a paid collection service. The agent can access the order, but the coordinator has approved neither choice.

Agent post-purchase delegated authority needs to be evaluated at the action being proposed. Permission to inspect an order or prepare a request does not settle whether the agent may accept new terms, incur a fee or make another purchase.

Separate access from the customer's instruction

In this fictional example, the coordinator has identified one order, one item and a quantity of one. The instruction permits a return request through the merchant's supported channel. It does not authorize accepting store credit, paying a collection fee or ordering a replacement.

Two records are needed: the access available to the agent and the actual customer instruction. An access credential can permit a technical operation without explaining whether that operation is within the customer's intended delegation.

The dated UCP order specification illustrates this distinction. It defines order access and scopes, retrieval, adjustment reporting and a merchant permalink for the post-purchase experience. Those definitions do not establish a universally implemented refund mutation endpoint or turn a scope name into the customer's complete instruction. Check the actual merchant capability and integration version. UCP order specification, 8 April 2026.

Evaluate the proposed action with a permission matrix

The matrix below is an original operating design for the stated example. It is not a claim that a protocol or agent already enforces it.

A limit written in a prompt is insufficient evidence of enforcement. The service needs to check the instruction against the proposed action at the point of commitment, including whether the instruction has changed or been withdrawn.

For a new purchase, use the purchase permission boundary. A return request should not silently become approval to spend again.

Hand back a specific decision

When the merchant offers store credit, the agent should explain the option, affected item, relevant terms and the action it is waiting to take. Asking a vague “shall I continue?” leaves the customer uncertain about what continuation means.

If the customer chooses an option, retain that instruction with its scope. Recheck the current merchant state before acting if the offer or order may have changed. If the channel cannot support the requested operation, offer the merchant's supported route rather than inventing an API action.

Keep a submission result separate from acceptance of the request and from a completed refund. If the submission outcome is unknown, reconcile the original request and its reference before taking further action. Do not send another request or initiate a second refund to resolve uncertainty. The protocol's adjustment reporting is evidence about reported state; an agent still needs to interpret that state within the actual merchant process.

Preserve the boundary when the conversation changes

A later message can alter the task. “Return both items” changes quantity. “Use the credit” may introduce a new choice. “Leave it for now” may withdraw permission. The operating record should make the current instruction identifiable without treating the entire chat history as unrestricted authority.

The wider purchase-to-refund ecosystem explains the organisations and stages involved. Partial-refund arithmetic addresses the amount calculation. This permission check comes before committing to an action within either process.

For the office coordinator, successful delegation means the agent can do the specified work and return the decisions that still belong to the person. Access to the order should make that boundary enforceable, rather than blur it.