In this essay
A customer asks an assistant to find a pair of running shoes under a stated budget. The assistant finds an option, checks the available size and prepares a purchase. Then the price changes. Which part of the system should stop the checkout, and which part is allowed to ask the customer for a new decision?
That question makes agentic commerce easier to understand than a diagram full of model names. The useful distinctions are responsibility, access and authority. A component that compares products has a different job from one that can submit a payment. They might use the same model and still need different permissions.
This guide uses a fictional purchase to map those boundaries. The roles are an analytical model, not a required standard architecture. Some implementations combine roles. Others use ordinary APIs and rules for most of the work, with a language model only at the customer interface.
Illustrative scenario; no actual customer or program result is shown.
Map the ecosystem before the purchase flow
The layers below separate the customer interface from the systems that establish the offer, authority and outcome. A named example shows the kind of responsibility involved; it does not mean that every row is a separate agent or that the examples form one supported stack.
Where a customer delegates
Items, preferences and purchase limits
Search, compare and explain options
How commerce state is represented
A checkout integration contract
Commerce capabilities across the purchase lifecycle
How tools and agents exchange work
Tools, resources and external systems
Communication and collaboration between agents
Who may act, and on what?
Establish the participant and its permitted access
An example of verifiable purchase and payment authority
What may use the payment method?
Example: Stripe Shared Payment Token
Scope, allowed use and expiry depend on the integration
Who processes the attempt?
Payment processing and applicable risk checks
Use a method the actual integration supports
Who explains what happened?
Fulfillment and current order evidence
Refund status, disputes and investigation records
These are architectural concerns, not seven mandatory agents or a prescribed event order. The examples do not establish a supported integration between every pair. Name the parties responsible for support and liability under the actual contract, method and region.
The protocol and credential examples are explained with primary references below.
Start with the outcome the customer requested
“Find shoes under my budget” authorizes a search. It does not clearly authorize a purchase. Even “buy these shoes” leaves implementation questions: which size, which seller, what delivered price and what happens if the selected offer disappears?
Before deciding how many agents to build, write the purchase boundary in terms a customer could recognize. For this example: one pair, the selected size and colour, a named merchant, a maximum total including delivery, and an expiry for the permission. This is a proposed design exercise, not a statement that a particular protocol requires those exact fields.
Keep preferences separate from limits. “Prefer next-day delivery” may permit a tradeoff. “Do not spend more than this total” is a constraint. An assistant should not silently turn the second into the first because another offer looks attractive.
The roles in the ecosystem
| Participant | What it contributes | Boundary to make explicit |
|---|---|---|
| Customer or delegated buyer | Purchase intent, constraints and approval | Make the permitted action and the actual outcome clear to the customer |
| Shopping assistant | Questions, search, comparison and an explanation of options | A recommendation must not create new spending authority |
| Merchant service | Current offer, stock, payable total, checkout and order records | Use the current merchant record to establish availability |
| Coordinator | The current task state, next step and unresolved work | A failed handoff must not silently create a second purchase |
| Payment and risk services | Credential handling, permitted payment execution and applicable checks | Keep declines and required customer challenges under the payment policy |
| Post-purchase service | Order status, support actions and refund status | Distinguish a refund request from confirmed customer credit |
These are responsibilities, not six mandatory AI agents. A merchant's inventory API can answer a stock question without an autonomous merchant agent. A deterministic service can enforce a spend limit. A support assistant may be able to read an order but have no right to refund it.
The organization operating each boundary matters as much as the software. If a shopping platform coordinates the experience and a merchant owns fulfillment, the customer still needs a clear route for a missing delivery. “Another agent handled it” is not a usable support explanation.
Follow one purchase across the handoffs
Imagine the customer chooses an offer at an illustrative total of 300 units. The delivery address is then added, and the merchant returns a final total of 325. The coordinator must compare that revised offer with the actual approval. If the customer approved only the earlier total, the workflow needs a new decision before payment. The example does not assume a currency, tax rule or universal approval policy.
The figure maps logical responsibility, not guaranteed event arrival order.
Specify what may be bought, the total limit and any expiry.
Confirm stock, selected items, delivered total and relevant terms.
In this example, 325 exceeds the approved total of 300.
Do not submit payment. If approval changes, recheck the offer against that new approval.
Use the agreed checkout path and retain the original attempt reference.
Do not infer a paid order from a conversation or a browser success screen.
A failed attempt does not authorize fulfillment.
Keep the result unresolved. Do not ask another agent to repeat the purchase. Once resolved, return to classify the original outcome.
Payment success alone does not confirm that the merchant created the order.
Check the merchant order record and payment reference. Do not charge again or promise fulfillment without order evidence.
Expose the order reference and delivery state. Track refund requests and refund results separately.
The side branches are alternatives, not steps on the successful path. The illustrative 300-to-325 change follows STOP. Recovery re-classifies the original attempt; it does not create a new charge. The flow shows responsibilities, not guaranteed event arrival order.
OpenAI's Agentic Checkout Spec is a concrete checkout reference for the Agentic Commerce Protocol (ACP). It describes merchant checkout endpoints returning cart state, order webhooks, and use of the merchant's existing payment provider and settlement processes. Its documentation also distinguishes the open protocol from Instant Checkout in ChatGPT, which is available to approved partners. These details describe that integration; they do not prove that any merchant can activate every channel immediately. OpenAI Agentic Checkout Spec
Protocol names answer different questions
Model Context Protocol (MCP), Agent2Agent (A2A), Agentic Commerce Protocol (ACP) and Agent Payments Protocol (AP2) are often mentioned together. They cover different parts of an architecture; putting their names in one diagram does not establish a working integration.
MCP concerns connections to tools and external systems. Its official introduction describes how AI applications can access data, tools and workflows. A tool connection can make a catalog or an order lookup available to an assistant. The existence of that connection is not evidence of permission to spend. MCP introduction
A2A concerns communication between agents. The project's documentation describes a common protocol for agents in different systems and positions it as complementary to MCP. In a commerce design, that may help components exchange tasks and results. It does not, on its own, establish the business meaning of a paid order. A2A overview
ACP provides a commerce integration contract. In OpenAI’s Agentic Checkout Spec, the merchant exposes checkout state and receives completion requests. That is a more specific concern than a general tool connection or an agent conversation.
UCP covers commerce capabilities across the purchase lifecycle. Its documentation describes discovery, checkout and order management, with support for connections such as MCP and A2A and authority through AP2. These are different concerns within a commerce integration, not interchangeable protocol names. UCP overview
AP2 addresses verifiable authority for agent-performed payments. The current v0.2 specification describes Checkout and Payment Mandates, with open constraints and closed transaction-bound forms. Its authorization model separates delegating authority from a verifier checking authority for an action. This helps explain why a conversation transcript and a purchase authorization are different records. AP2 specification AP2 authorization framework
AP2 also leaves the surrounding commerce protocol's catalog and checkout APIs outside its scope. Its current terminology differs from older explanations using Intent and Cart Mandates. Record the specification version used by an actual implementation before comparing fields or claiming compatibility. A protocol description is not proof that a particular payment provider, merchant or region supports the flow.
A payment credential has its own scope. Stripe describes a Shared Payment Token as a grant for a seller to use a customer payment method, subject to usage and expiration limits. This is a provider-specific example, not a claim that the same credential works with every merchant or in every region. A credential grant is also different from evidence that a payment succeeded. Stripe Shared Payment Tokens
The coordinator needs a durable record
The coordinator is useful because work can stop between systems. A browser closes, a payment response times out, or the merchant accepts a request before the assistant receives its reply. Starting the conversation again should not create another purchase by accident.
For the fictional purchase, a useful operating record links the customer instruction, permission, offer version, checkout reference, payment attempt, order outcome and unresolved question. Keep only the data needed for the workflow, with appropriate access and retention controls. Do not copy raw payment credentials into a general agent transcript.
Treat each state as a claim that needs evidence. “Payment submitted” says an attempt was made. “Order confirmed” needs a merchant order result. “Refund requested” describes another operation, whose outcome must be tracked separately. These labels are an editorial design recommendation; use the precise lifecycle exposed by the integrated provider.
AP2's implementation guidance discusses receipt management, prevention of overlapping mandates and management of active delegations. That is a useful reminder that autonomous work still needs a bounded lifecycle and a visible control surface. It is not a substitute for testing the complete implementation. AP2 implementation considerations
Test the handoffs before adding more autonomy
Use the following as proposed acceptance cases. They are not claims that a deployed system has passed testing.
- The offer changes. Change the price or selected item after the original approval. Check whether the system requires a new decision when the revised purchase exceeds the permission.
- One participant times out. Withhold the checkout response after the merchant receives the request. Check that recovery investigates the original attempt instead of asking a second agent to buy independently.
- The customer withdraws permission. Cancel a pending task before execution. Check that the change reaches every component that could still act; record any action already beyond cancellation.
- A tool returns conflicting information. Let a search result and the merchant checkout disagree about stock. Check that the final purchase uses the current merchant offer and presents unresolved discrepancies.
- An agent requests excessive access. Give the shopping assistant an order-reading tool. Check that it cannot turn that access into a refund or payment action.
- Support needs to investigate. Ask why an order is missing after an attempted payment. Check that support can trace the relevant references without seeing unnecessary credentials or private conversation content.
Assign an owner and retain redacted evidence for each result. Run disruptive cases in an appropriate test environment. A successful demo of the happy path does not show how the workflow behaves when permission, price or state changes.
For implementation and pilot checks, continue with payment product readiness. For internal incident and support use cases, see agentic payments operations. Those guides address different operating decisions from this introductory role map.
Decide where an agent earns its place
An agent can be useful when a task involves interpreting preferences, comparing alternatives or deciding which supported step to take next. That does not make every boundary a good place for autonomous judgment.
For this purchase, start by identifying which decisions need interpretation and which must follow explicit constraints. Then decide which tools each participant can call and what evidence allows the workflow to advance. Add another agent only when its responsibility is clear enough to test and its failure has a named owner.
The customer should be able to answer three practical questions: what was authorized, what actually happened, and where to go when the two differ. A credible agentic-commerce system preserves those answers across every handoff.
Primary references checked on 24 October 2026. Protocol descriptions are version-specific. Examples and proposed controls are editorial analysis, not a claim of universal interoperability, payment-provider availability or measured business results.
Closing thought and further reading
A shopping assistant can recommend a purchase without having permission to make it. Map the responsibilities, tools and evidence across one agent-assisted purchase.
Ideas that continue the thread.
View all essays
Need help applying this to your business?
Explore practical support for payment operations, product decisions, program delivery and AI automation, grounded in the challenges behind this essay.