An Agent Can Find the Product. May It Buy It?

A customer asks an assistant to compare compact monitors for a home office. The assistant finds a suitable model at a good price and prepares a checkout. The customer has authorized research. Whether the assistant may buy the monitor is a separate decision.

“Find the best option” leaves important choices unresolved: the seller, exact model, total cost, currency, delivery conditions and the point at which the customer wants to approve the purchase. A capable agent should be able to stop at that boundary.

This article uses a fictional monitor purchase to examine delegated authority. Protocol examples come from the AP2 documentation checked on 25 October 2026. The proposed operating controls are design recommendations; they are not claims that every agent platform implements a common approval or revocation service.

Separate research permission from purchase authority

The assistant can compare products, summarize terms and prepare an option for review within the task it has been given. A request to investigate does not, by itself, authorize a financial commitment.

Before execution, the application needs a clear answer to who is acting, for whom, on which permitted action and under which current conditions. A budget is one condition. It does not necessarily express the intended product, acceptable seller or return terms.

For example, a monitor priced below the budget could be the wrong size, sold by an unacceptable marketplace seller or bundled with a recurring service. A product review should identify which conditions are hard constraints, which are preferences and which require another customer decision when they cannot be satisfied.

The agent roles article maps the broader participants. This article focuses on the moment an assistant moves from proposing a purchase to acting on it.

Make approval describe the actual commitment

A proposed approval screen for the monitor should show enough information for the customer to understand the transaction. The exact fields depend on the use case, but the following record is a useful starting point.

These are proposed product fields, not a copy of a mandatory protocol schema. Some systems may represent the information through several records. The important property is that the executing system can evaluate the relevant conditions without treating a merchant's page or the agent's own summary as new customer permission.

Understand what AP2 contributes

The AP2 v0.2 documentation separates authorization, checkout mandates and payment mandates. Its authorization guidance describes approval through a trusted surface and verification of the resulting authority. This helps frame the distinction between a user's instruction and an agent's assertion that it has permission. AP2 specification Agent authorization

The checkout and payment documentation describes constraints associated with the commercial checkout and the financial action, including relevant parties, amounts and execution conditions. A payment receipt is separate evidence of an outcome. These concepts do not mean that every merchant accepts the same implementation or that one protocol automatically resolves every operational exception. Checkout mandates Payment mandates

Pin the version and supported profile when implementing. The current payment-mandate page contains inconsistencies between some type descriptions, schema rows and amount examples. This article deliberately does not reproduce those examples as executable instructions. Resolve the applicable normative definition and implementation behaviour before using it to authorize real transactions.

Protocol compatibility is covered separately in the MCP, A2A, ACP, AP2 and UCP comparison. Supporting an interface is not itself evidence that a particular purchase is authorized.

Recheck when the checkout changes

Suppose the customer approves one monitor from a specified seller for a total of 300 illustrative currency units. Before execution, delivery changes and the total becomes 318. The application must apply the customer's recorded change rule. It should not decide that a modest difference is acceptable merely because the agent still considers the deal attractive.

The same question arises if the model changes, the seller changes or a required return condition disappears. A broader delegated instruction may explicitly allow bounded choices. If so, evaluate the actual scope rather than asking for confirmation on every harmless detail. If the scope is missing or ambiguous, stop the purchase and obtain a clear instruction.

The proposed design binds the approval to a version of the relevant purchase terms. When those terms change materially, preserve both versions and the decision about whether the authority still applies. This makes a later complaint more explainable than a conversation transcript with no clear execution boundary.

Prepare the option within the research task

The agent identifies the product, seller, total and material terms. Research alone grants no purchase authority.

Obtain or locate the relevant delegated approval

Does current authority cover this exact action?

Validate the actor, scope, terms, total, currency and timing at the execution boundary.

Missing, expired, revoked or materially changed

Stop submission. Ask for the necessary customer decision or use a permitted non-purchase path, then recheck.

Recheck only after an appropriate new customer decision

Only a covered, current request may continue

Check for an existing submitted operation

Use the purchase identity and durable operation history before committing another request.

Already submitted or result unknown

Investigate the original operation and preserve any unresolved outcome with its owner. Do not create another purchase.

Record and report the original outcome without resubmission

Only a purchase with no prior submission continues

Submit the authorized new purchase once

Persist the operation identity and use the integration’s documented duplicate and recovery controls.

Retain the resulting state, including an unknown outcome

Record and report the original result

Join authority, merchant order, payment and fulfilment evidence. State only confirmed stages; keep any unknown result assigned for recovery.

Research authority does not permit purchase. A recovered prior submission goes directly to evidence and reporting, never through the new-submission step.

Handle expiry and revocation as operational events

An approval valid when the agent prepared a cart may be expired when a worker is ready to submit it. A customer may also withdraw an instruction while work is queued. The application needs to check current authority at the relevant execution point and define how changes reach that point.

These are proposed responsibilities, not a promise that AP2 supplies instantaneous global revocation. A distributed system has timing boundaries. Record when the change was accepted, which operation was queued or submitted and what can still be stopped through the supported interface.

If a purchase has already been submitted, recover its actual outcome. A later revocation cannot be presented as proof that the earlier request never happened. Any cancellation or refund is a subsequent operation governed by its own conditions and evidence.

Keep untrusted content outside the permission decision

A product page may contain useful descriptions and terms. It may also contain instructions aimed at the agent. Such content should be treated as reference data, not authority to alter the customer's budget, payment destination or approval rules.

AP2's security and privacy considerations discuss the trust and verification boundaries around delegated actions. The application still needs to implement its own checks and protect the information it exposes. A signed object is meaningful only when the relevant signature, issuer, scope and context have been validated under the chosen implementation. AP2 security considerations

Test a page that asks the agent to ignore its previous limits, a changed payee, an expired approval and a reused approval attached to a different cart. Verify the denied path as carefully as the successful path. The customer should receive an understandable explanation without exposing sensitive credentials or internal fraud rules.

Preserve the purchase evidence after execution

Join the approved instruction to the submitted request, merchant order and payment result. Keep these stages separate: authority to act, merchant acceptance, payment outcome and fulfilment. An issuer approval does not prove that the selected monitor matched the customer's instruction, and an order receipt does not prove delivery.

A useful completion message states what the application actually confirmed and what remains pending. If the payment result is unknown, investigate the original attempt before another purchase. If the merchant rejected the order, do not report a successful purchase because a payment step previously succeeded.

The assistant's value includes knowing when to return a decision to the customer. In this monitor example, comparing options can be complete while buying remains unauthorized. Preserving that boundary makes the eventual purchase easier to trust and easier to explain.