Keep purchase meaning stable while bounded payment attempts change routes.
An agent wants to buy a translated dataset for no more than $0.15. That is a purchase decision. Paying USDC on one network, falling back to USDT on another, signing a wallet instruction, and presenting proof to the merchant are execution decisions. Combining all of them into one opaque command makes every retry look like a new purchase.
An AI agent payment intent should describe the economic outcome the principal approved. Payment attempts should describe how infrastructure tries to achieve that outcome. The separation gives an agent freedom to recover from route failures without silently changing the merchant, product, terms, or spending ceiling.
A Rail Instruction Cannot Represent the Entire Purchase
Consider the instruction “send 0.15 USDC to address X.” It names an asset, amount, and destination. It does not establish which dataset the payment buys, which service terms apply, how long the quote remains valid, whether another network is acceptable, or what the merchant should do after settlement.
Now consider “buy the best translation dataset.” It expresses purpose but no budget, merchant, deliverable, deadline, accepted terms, or payment constraints. A language model can interpret it differently on every run.
A production system needs a structured object between those extremes. The intent captures the approved purchase semantics. A policy decision binds a principal to that intent under explicit constraints. Execution infrastructure then resolves quotes and routes inside those constraints.
Without this layer, a retry can drift. A failed transfer may be repeated after the quote expires. A fallback provider may receive payment even though the principal approved only the original merchant. An agent may increase the amount to cover fees without checking the budget. The payment can be technically valid and economically unauthorized.
Define Two Objects With Different Mutation Rules
The intent should contain fields that define purchase meaning. Its identity fields are the intent ID, version, principal, and acting agent reference. Its commercial fields are merchant, resource, deliverable, terms digest, total amount ceiling, and fee treatment. Its policy fields are allowed assets and networks, validity window, completion and refund rules, and the policy-decision reference.
The payment attempt contains route-specific operation. It records an attempt ID and parent intent, quote and requirement version, selected asset and network, recipient, amount, wallet account, and anti-replay field. Lifecycle fields cover submission, verification, settlement, failure, retry relationship, payment proof, and transaction reference.
One intent can have several attempts. At most one set of attempts may satisfy the purchase unless the intent explicitly allows split payment. The order system should record which attempt fulfilled the entitlement and treat later successes as duplicates requiring reconciliation.
The intent itself also needs state: proposed, authorized, active, satisfied, expired, cancelled, or disputed. Authorization should bind to an immutable content digest. If a protected field changes, the system creates a new version and requests a new policy decision.
A $0.15 Route-Fallback Scenario
An agent selects merchant lingua-data, resource dataset-es-v5, and terms version 12. The principal’s policy approves a ceiling of $0.15 including network fees, permits USDC or USDT on two supported networks, and requires delivery within 30 seconds. The system creates intent i-730.
The merchant returns an x402 payment requirement for $0.14 USDC on network A. Attempt a-1 is created under i-730. The wallet signs and submits it, but the facilitator reports a route timeout. Payment state remains unknown for three seconds, so the orchestrator marks a-1 as reconciling. It must not immediately spend the full ceiling again.
Reconciliation later proves that a-1 did not settle. A fresh requirement offers $0.14 equivalent in USDT on network B. The policy allows that asset and network, the merchant and terms are unchanged, and total exposure remains within $0.15. Attempt a-2 can proceed under the existing intent.
The merchant verifies a-2, delivers the dataset, and records intent i-730 as satisfied by that attempt. If a-1 later appears as settled despite the earlier failure result, the merchant has a duplicate-payment incident. It should not deliver a second entitlement. The evidence envelope routes the extra payment to reconciliation and the disclosed refund process.
This example preserves purchasing meaning through operational change. The agent did not “decide again” merely because a network route failed. It also did not gain authority to change what it was buying.
Which Mutations Preserve Authorization?
Not every field change has the same consequence.
Proposed change | Preserve intent? | Required action |
|---|---|---|
Retry the same requirement after a transport error | Usually | Reuse attempt or create a linked attempt after reconciliation |
Switch to another allowed network or asset | Sometimes | Reprice, recheck exposure, and create a new attempt |
Reduce amount for the same entitlement | Usually | Verify merchant accepts it and retain quote evidence |
Increase total amount above the ceiling | No | Obtain new authorization |
Change merchant or payment recipient | No | Create or reauthorize intent |
Change product, quantity, or service terms | No | Create a new intent version and authorize it |
Extend expiry without changing exposure | Policy dependent | Validate the existing mandate and risk window |
Add an undisclosed fee | No | Reprice and obtain approval if it changes exposure |
The deciding question is not whether the wallet can sign the new instruction. Ask whether the new instruction still implements the approved economic object. Wallet capability is not purchasing authority.
Policy should evaluate cumulative exposure, not only the amount in the next attempt. Pending and ambiguous attempts count until they reach a terminal state. Otherwise, route fallback can exceed the ceiling even when every individual attempt is below it.
Quote Expiry and Terms Evidence
Quotes have clocks. Store issue time, expiry, amount, asset, network, recipient, fees, and the resource or order they satisfy. When a quote expires, the agent can request another one. It must compare protected fields before execution.
An x402 payment requirement is a merchant-side statement of what the requested resource costs under supported schemes. The agent can attach it to the intent and ask policy whether it fits. The requirement does not replace the agent’s broader purchase object, especially when the task includes provider selection, delivery terms, privacy conditions, or a workflow-wide budget.
Terms need version binding too. A route change should not silently accept a new refund policy or weaker delivery SLA. Store a digest of the accepted terms in the intent and compare merchant updates. A semantically material change needs a new decision even when price falls.
Fee treatment must be unambiguous. “$0.15 maximum” can mean merchant price only or total wallet debit. Agents need the latter when protecting a task budget. Define whether gas, facilitator fees, bridge costs, and refunds count toward the ceiling.
Make Every Attempt Recoverable and Idempotent
Create the intent before requesting payment. Reuse its ID through policy, x402 negotiation, wallet action, merchant order, proof, delivery, and remedy records. Give each execution attempt a unique child ID and idempotency key.
After a timeout, query the attempt before creating another. States such as prepared, submitted, verifying, settled, failed, expired, and reconciling prevent a transport error from being mistaken for a payment failure. Only terminal failure releases the exposure reserved for that attempt.
Merchant fulfillment should be idempotent on intent or order. If two proofs arrive, the first valid one satisfies the entitlement and the second enters duplicate-payment handling. A second callback must not create a second download, license, API credit, or service job unless the purchase explicitly requested quantity two.
Cancellation also needs boundaries. Cancelling an intent stops new attempts. It cannot reverse a payment that already settled. The system must reconcile in-flight attempts and apply the merchant’s refund or delivery terms.
FAQ
Is an AI agent payment intent the same as a transaction?
No. The intent describes the approved purchase outcome and constraints. A transaction or payment attempt is one execution path used to satisfy it.
Can an agent switch networks without new approval?
Only when the intent and policy already permit the new network, the merchant and terms remain valid, and cumulative exposure stays within the ceiling. Otherwise, reauthorization is required.
Should a retry create a new payment intent?
Usually no. A transport or route retry should reuse the original intent and either resume the existing attempt or create a linked child attempt after reconciling the first.
Does x402 define the agent’s full purchase intent?
It communicates payment requirements for a resource and supports payment proof flows. An application may need a broader intent object for provider choice, task budget, delivery conditions, identity, privacy, and remedy policy.
What invalidates an authorized intent?
Expiry, cancellation, satisfaction, or a protected change such as merchant, resource, terms, recipient, or amount above the approved ceiling can invalidate it or require a new version and authorization.
Where Intent and Execution Roles Belong
The planner proposes the desired resource and expected value. A discovery layer supplies merchant terms and prices. The intent service creates the structured purchase object. The policy engine binds principal authority and limits. The wallet signs approved execution. x402 communicates resource payment requirements and proof. The merchant system maps successful payment to entitlement. The settlement network records value movement.
AP2 and trusted-agent protocol work provide useful language around intents and mandates. They should not be treated as identical to x402. Each occupies a different part of the commerce problem, and implementations may combine or omit components depending on scope.
GOAT Flow guidance to persist payment intent IDs across retries aligns with this model. AgentKit runtime policies can validate network, action, write permission, and risk constraints around execution. Applications still need to define the purchase-intent schema, protected fields, amount policy, and reauthorization rules.
That division keeps the model from self-authorizing. The agent can optimize among permitted routes. It cannot enlarge its own mandate merely by generating a new payment instruction.
Five Route-Failure Tests for Intent Fidelity
Start one intent, fail the first network route, leave a payment ambiguous, offer a second asset, expire the quote, change the recipient, increase the amount, modify terms, and deliver two proofs. Verify that allowed route recovery stays under one intent and protected-field changes stop for reauthorization.
Record why each mutation was accepted or rejected. Measure ambiguous-attempt age, duplicate settlements, policy rejections, quote expiries, intents satisfied by multiple attempts, and executions missing an intent reference.
The release invariant is precise: every settled attempt must be traceable to one authorized intent version, and the sum of unresolved exposure must never exceed that intent’s ceiling. If the system cannot prove both, payment orchestration has more freedom than the principal granted.
The Control Boundary
Let execution infrastructure change operational details only inside an already approved set. Stop and request a new decision when the proposed route changes who receives value, what the agent receives, which terms govern delivery, or how much total exposure the principal accepts. This boundary preserves useful automation without turning rail selection into purchasing authority.
