Key takeaway
Turn a purchase instruction into checkable product scope, budget, expiry, and exception rules, then design revocation, status checks, and human handover so consent remains valid at execution.
Keep authorization valid across the purchase lifecycle
Authorization is an execution policy, not a conversational “yes”
When a customer says “buy me shoes for commuting,” they communicate a goal, but they have not fully specified which account the agent may use, what price is acceptable, which size is required, or when the order may be submitted. Treating the sentence as unrestricted purchasing authority mixes recommendations, payment permissions, and transaction decisions. This article proposes a product and operating method for turning natural-language intent into checkable execution conditions. It is intended for teams moving from recommendations toward purchasing.
The method does not claim that a protocol automatically resolves liability. Primary material such as AP2 provides background on intent and authorization evidence; the field design, interfaces, and verification steps below are our recommendations. Every example is hypothetical and does not establish that an agent, bank, or merchant supports the capability. Before implementation, confirm which conditions your identity, order, and payment systems can actually enforce.
Separate recommendation, preparation, and submission
Divide permissions into three independent actions. Recommendation authority permits searching and comparison. Preparation authority permits a cart or quote to be assembled. Submission authority permits an order to be created and the applicable payment steps to begin. Permission to recommend a product should not automatically become permission to submit. Conversely, a specifically authorized purchase does not require interrupting the customer whenever stock is checked. Match permissions to actual actions instead of offering a single vague “automatic shopping” switch.
Describe the next action in the interface. “Prepare three alternatives” and “submit one order for the confirmed model” call for different wording. A service agent that may view an order is not necessarily allowed to change its recipient or initiate a new payment. A product manager can first list every tool action, then ask the responsible business owner to define the required permission, permitted account, validity period, and evidence for each action.
Give a budget a currency and a scope
“No more than five hundred” leaves the currency unspecified and does not say whether shipping, tax, insurance, or platform fees are included. We recommend stating at least the settlement currency, the total permitted for one purchase including fees, the cumulative budget, and the applicable time window. The agent should not silently convert “approximately” into a higher payment limit. If the business supports tolerance, show a readable range and retain the boundary that actually took effect.
Suppose a customer allows office supplies to be replenished over seven days within an agreed total. A single order being below that limit does not establish that the next order remains permissible. The system also needs consumed amounts, unresolved payment attempts, and reservations that may later be released. When several agents operate concurrently, a service capable of preventing simultaneous overspending should manage the budget. Each model should not calculate the remaining allowance independently in its own conversation.
Define the product scope beyond a search term
An agent cannot determine permissible substitutions using only category words such as “shoes” or “coffee.” In one task the brand may be flexible while the size is fixed; in another, the brand matters little but compatibility is a hard requirement. Store mandatory conditions, negotiable preferences, and excluded choices separately. If the original candidate becomes unavailable, the system can then decide whether to continue searching, request confirmation, or stop.
Confirm quantity and packaging units as well. A carton and an individual item, a bottle and a multipack, or a sample and a standard package may all appear to match a textual description while differing economically and practically. Gifts, subscriptions, recurring billing, and substitutions should not gain customer authorization merely because a merchant promotes them. Accept automatically only when existing conditions permit it; otherwise present the change and its price, duration, or usage implications for confirmation.
Bind permission to a person, account, and transaction party
The same person may have very different authority in a household account, a personal account, and a company purchasing account. Being able to sign into an application does not establish authority to commit the company to a purchase. An authorization record should explain the relationship between the authorizing person and the execution account. Agents serving multiple customers must also prevent addresses, budgets, and payment methods from crossing between users. One successful login is not a passport for every later tool call.
Where permission names a merchant, verify that the final payee corresponds to the customer’s understanding. A display name, marketplace storefront, actual seller, and payment statement description may differ and need an explicit business mapping. Do not compare only a brand string found on a webpage. Account changes, payee changes, or an expired source of authority should trigger deterministic checks rather than a model’s own interpretation that the change seems reasonable.
Recheck changing conditions at execution time
Stock, price, delivery dates, and discount eligibility can change after a quote is accepted. Authorization should therefore not be checked only when a task starts. Place an explicit checkpoint before order submission and compare the authorization version, quote version, and current business state. A gap can also exist between a successful check and submission; identify which fields the transaction service must verify within the same protected operation.
If a change remains inside the accepted scope, the agent can continue under the business rules without an unnecessary confirmation dialog. If it crosses a hard boundary, such as exceeding the fee-inclusive budget, changing the size, or introducing a subscription, stop. Record the precise condition that prevented execution so the customer can amend only the relevant permission instead of repeating the entire request. A vague “something went wrong, try again” does little for trust or diagnosis.
Revocation stops future execution; it is not deletion of a chat
When a customer revokes permission, distinguish tasks that have not begun, transactions submitted with an unknown outcome, and successfully created orders. Revoking authority should generally stop new execution, but the interface should not describe it as undoing an already successful transaction. The latter may require order cancellation, release of a payment authorization, or a refund, depending on the actual state. Calling all these actions “cancel” can make people believe that money and goods have stopped moving.
Give revocation a traceable result: when the request was received, which authorization version is invalid, and which in-flight transactions still need checking. Invalidate locally cached permissions as well. Updating an account-page switch while the execution service continues using an old cached permission does not complete revocation. For transactions that cannot be confirmed immediately, show an explicit pending state and offer subsequent status checks and a human support path.
Concurrency, timeouts, and retries need shared facts
A shopping agent may compare several stores concurrently, and a payment service may return a delayed outcome after a network timeout. Authorization must connect with order and payment state; otherwise, an attempt that is not yet confirmed successful can be treated as if it never happened. Give the purchase intent, order attempt, and payment attempt separate stable identifiers while retaining their relationships. A retry should recover the same business action rather than create new permission to bypass the original constraint.
In a rehearsal, deliberately delay a submission result and then revoke the task. Observe how the system resolves the sequence. If the transaction completed before revocation, report the true state and enter the applicable post-purchase process. If execution has not occurred, prevent submission. The goal is not a promise that every step can be reversed instantly. It is a queryable factual basis for every transition and consistent explanations from customer support.
Human handover should include context
When an agent cannot finish, the handover view should contain the original goal, accepted conditions, completed actions, unresolved transactions, and the reason it stopped. The customer or support specialist should not need to guess whether an order was placed, money moved, or cancellation occurred. State what is now allowed: checking status only, selecting a new candidate, or seeking a higher budget. This is more useful than a lengthy record of the model’s reasoning.
Decide whether the original agent retains execution authority after handover. If support staff and the agent can both change the same order, duplicate actions or overwrites become possible. A task-owner transfer, temporary lock, or explicit human completion signal may be appropriate depending on the system. Whatever the mechanism, show the current controller and recheck the remaining task scope before resuming automation.
Retain useful evidence without collecting everything
A useful evidence record answers who accepted which conditions and when, which version was used at execution, and why the transaction met those conditions. It does not require retaining the customer’s entire conversation history. Select fields by purpose: an authorization summary, version, time, transaction party, final amount, validation outcome, and linked order identifiers. Avoid routinely retaining unnecessary personal preferences, full payment details, or unrelated conversations.
Evidence also needs access boundaries. Operations may only need to know whether permission was valid; support may need to explain an exception; engineers may need to diagnose a state error. Give these roles different views and record evidence access and exports. Determine retention and deletion rules using the actual service and applicable requirements; this article does not prescribe a universal period. Explainability should not become a justification for unlimited collection.
Test boundaries, not only the happy path
Acceptance testing should include expired permissions, amount boundaries, duplicate submissions, account changes, substitutions, and revocation racing with payment. Define the expected action, required record, and who can inspect the result for each case. Do not stop at checking that a screen says “declined”; verify that downstream systems did not create an order or initiate another charge attempt. The displayed state and execution facts should agree.
For the hypothetical office-replenishment task, begin with one account, one product class, and a defined period, using a small set of controlled orders to observe exceptions. Track unauthorized execution, legitimate tasks incorrectly blocked, handover time, and customer understanding separately. An absence of incidents does not establish completeness if the tests never reached the boundaries. Nor should required checks be disabled merely to improve a superficial success rate.
Delegation may preserve or narrow authority, not expand it
A shopping agent may delegate search, quotation, or service work to other systems. Every additional layer must retain the original task boundaries. Access to a tool should not be mistaken for fresh permission to purchase. We recommend checking final actions through a common execution boundary while giving each subordinate service only the information and authority needed for its role. A product-discovery service generally does not need full payment information, and a shipment-tracking service does not need the ability to create orders.
If an outside service requests permissions beyond the current scope, the model should not approve them on its own. Record what is requested, why it is needed, and whether a narrower scope can complete the task. Approved delegation should also specify whether onward delegation is permitted, when it expires, and how revocation of the original authority propagates. A delegation map helps engineering and operations locate responsibility, but does not replace execution-time permission checks.
Explain authorization to the customer, not to the protocol
The authorization interface should make consequences understandable to someone who has never read the technical documentation. Instead of showing only protocol acronyms, token states, or abstract permission names, present a concise confirmation containing the product scope, maximum payment, validity period, and stopping method. For preapproved automatic execution, explain which changes remain inside the scope and which will prompt a question. People should understand the outcome before deciding, rather than infer risk from technical vocabulary.
A bilingual product must check whether translation changes the scope. “At most” in one language and “approximately” in another set different expectations; “once within seven days” also differs from “every seven days.” Generate both explanations from the same structured authorization object rather than maintaining two independent policies in prose. During acceptance testing, ask participants to explain the agent’s authority in their own words and treat inconsistent interpretations as design defects.
Make governance part of everyday operations
Authorization design is not a one-time copy review before launch. A new payment method, product category, agent platform, or promotion rule can make existing conditions insufficient. Assign responsibility for field definitions, rule changes, exception approvals, and emergency stopping. Retain previous versions and effective dates so later rules are not used to reinterpret earlier transactions, leaving support and audit with different accounts of what happened.
Periodically sample real authorization paths and check that the customer-facing description, enforced rules, and support explanation still agree. Prioritize gaps that permit out-of-scope execution, then reduce unnecessary interruptions. A good agent experience lets the system complete work smoothly within clear limits while enabling the customer to understand, narrow, or stop the delegation. These capabilities should be designed together.
FAQ
- Does one confirmation authorize purchasing forever?
- One confirmation should not be treated as indefinite delegation. State the scope, validity period, budget, and revocation method; recurring tasks need matching schedules and exception rules.
- Does revocation mean a refund succeeded?
- No. Revocation constrains future execution. Cancellation, release of funds, or refunding a completed transaction must be handled according to actual order and payment state.
- Must every purchase show a confirmation dialog?
- Not necessarily. Execution that is clearly authorized and still meets the agreed conditions can proceed under those conditions. Crossing a hard boundary or introducing a new commitment requires renewed confirmation.
Sources & further reading
- AP2 – Agent Payments Protocol documentation · AP2
- Powering AI commerce with the new Agent Payments Protocol · Google Cloud
- Key concepts – Agentic Commerce · OpenAI
AI-assisted original research. Scenarios are hypothetical; rely on the primary sources listed for facts. Not investment or legal advice.