AGENTWALLETS · INDEPENDENT PERSPECTIVES
ACT Protocol: Carrying User Intent Through an Agent Purchase
Understand ACT’s intent, delegation, commerce and payment domains, with particular attention to signed boundaries and payment-versus-fulfillment state.
Quick answer
ACT, the Agentic Commerce Trust Protocol, is an application-layer framework connecting user intent, delegated authority, commerce interactions, payment services and evidence. It coordinates these responsibilities above existing systems; it does not replace payment networks or define their underlying clearing and settlement rules.
A user asks an assistant to buy a replacement printer cartridge before Friday. “The cheapest compatible one” leaves several questions open: which printer, whether delivery is included in the price and whether a substitute is acceptable. If the user will not be present at checkout, those ambiguities become authorization problems.
ACT approaches the purchase as a connected chain of intent, authority, commercial agreement and execution evidence. Its usefulness depends on preserving those links across participating systems.
Research boundary: ACT’s official framework and domain documents reviewed November 1, 2026. The cartridge purchase is a conceptual example. We did not integrate with a merchant or payment provider, and no availability or interoperability claim is implied.
Clarify the task before turning it into authority
The delegation-domain document separates a structured intent result, ISR, from an intent authorization credential, IAC. The first captures the clarified task; the second carries the agreed authorization boundaries in a verifiable form. The signed scope must be identified explicitly rather than assumed to contain every part of the conversation.
For our example, a product team should decide which details are hard constraints and which are preferences. “Compatible with this exact printer” is different from “prefer recycled packaging.” If the former is necessary for approval, confirm how it survives into the data that later checks rely on.
Do not present a machine-generated summary as user approval until the required confirmation has happened. A neat JSON object can still represent the wrong intention.
Conceptual delegated-purchase chain based on ACT, not a tested checkout. Immediate user-confirmed payment follows a different authorization path.
A framework above the payment rail
The ACT overview organizes responsibilities into delegation, commerce interaction, payment services and trust services. It explicitly leaves underlying clearing and settlement outside its scope. A merchant, payment service and trust service can therefore have separate responsibilities even where one company operates several of them.
That means an ACT integration review still needs named implementations. Which service issues or verifies the credential? Which merchant confirms the cart? Which payment provider moves the funds? Where are records stored and who can retrieve them? A framework diagram alone cannot answer whether those systems are available to your business.
Keep the cart attached to the approval
A useful application-level invariant is that the product, merchant, total amount and delivery constraints checked at payment correspond to the user’s approved task. If the cartridge price or delivery date changes during checkout, the assistant should not quietly reuse an approval for different terms.
We would make this visible in a cross-system trace: task reference, credential reference, cart or order reference, payment attempt and fulfillment evidence. These are suggested operational records, not a claim that all ACT deployments expose one universal API schema.
The same discipline helps minimize data exposure. A merchant may need compatibility and delivery requirements without needing the user’s entire conversation. Define which party receives each field, and keep authorization evidence accessible to the parties that must verify it.
Payment success is only one business event
The payment-domain specification distinguishes user-present payment from delegated scenarios and describes payment and fulfillment-related states. Its HTTP 402-based A402 flow includes payment requirements and payment proof, but sharing an HTTP status code should not be read as automatic compatibility with another 402 protocol.
For the cartridge buyer, the workflow is unfinished when the payment provider confirms a charge. The merchant still has to fulfill the order, and the application needs to explain a cancellation or refund without rewriting the history of what happened.
| Event in our example | Product behavior to define |
|---|---|
| A different cartridge is substituted | Recheck compatibility and approval scope |
| Authorization expires before payment | Pause and obtain a new decision where required |
| Payment result is uncertain | Query the existing attempt before paying again |
| Payment succeeds but stock is unavailable | Enter the merchant’s fulfillment/refund process |
| User stops future delegation | Separate future authority from existing orders |
These are proposed acceptance scenarios, not demonstrated outcomes from ACT participants.
What to evaluate first
Start with one merchant, one payment method and one clearly bounded delegated task. Require evidence that the implementation preserves the agreed constraints and can explain a failed or interrupted purchase end to end. Adding more protocol domains before that trace works may increase complexity without improving control.
ACT is a protocol framework, not a synonym for every agent-commerce product from a related corporate ecosystem. Keep its directory record separate from AMP or an identity implementation such as APASS. The ACT reference links the official material; payment idempotency covers a practical concern that remains important across implementations.
FOLLOW THE SOURCES