Use an autonomy ladder with explicit promotion gates
Agentic payments can begin with recommendations, move to pre-filled checkout, then exact-order approval, standing mandates for narrow merchants, and finally bounded unattended execution. Each step changes the authority and incident surface. Define which transaction classes belong at each level instead of assigning one autonomy mode to the entire product.
Promotion criteria should combine policy accuracy, successful reconciliation, duplicate prevention, refund completion, evidence completeness, user comprehension, and incident rate. Volume alone does not prove safety, and a low decline rate can mean the policy is too permissive.
| Stage | Agent role | Human role | Promotion evidence |
|---|---|---|---|
| Observe | Generate shadow proposals | Completes existing flow | Proposal quality and policy coverage |
| Assist | Build exact transaction | Approves every effect | Clear consent and complete receipts |
| Delegate | Executes narrow mandate | Approves mandate and exceptions | Stable deny path and reconciliation |
| Expand | Handles broader repeat classes | Reviews risk-triggered events | Operational and security thresholds hold |
Choose reversible, observable first transactions
Start with merchants and products that have predictable terms, low values, straightforward refunds, reliable identifiers, and clear fulfillment. Avoid irreversible transfers, variable final prices, scarce inventory, regulated goods, and purchases with complicated cancellation rules until the control model has been proven.
Use allowlists, daily and per-transaction caps, short mandate expiry, one asset, and one rail during the first phase. Narrow scope makes anomalies interpretable and reduces the number of explanations for a reconciliation break.
- Define a kill switch and test it before the first delegated payment.
- Keep exact-order step-up approval for changed terms or uncertain identity.
- Store enough evidence to reconstruct every authorization and rail transition.
- Give support and finance teams a transaction view before increasing volume.
Measure the control system as well as conversion
Business metrics such as task completion and checkout conversion matter, but they must sit beside authorization denials, manual escalations, duplicate attempts, settlement lag, unreconciled items, refund age, user cancellations, and support contacts. Segment every metric by autonomy level, merchant, rail, policy version, and transaction class.
Review samples of successful transactions, not only failures. A permissive policy can create a clean operational dashboard while authorizing purchases users did not expect. User research should test whether people understand the scope, duration, and revocation behavior of a mandate.
Promote by transaction class and retain rollback
A rollout decision should name the exact class being expanded: for example, one merchant category below a value threshold with refundable products and a short mandate. Keep configuration versioned so the organization can return to the prior policy without changing application code.
After promotion, maintain shadow checks against the stricter policy and watch for distribution shifts. New merchants, model versions, prompt templates, provider adapters, and regulatory requirements can invalidate the evidence that supported the earlier decision.
Bounded autonomy is a continuously governed operating mode, not a launch milestone.
Source discipline
Primary sources
Product status and protocol behavior are checked against maintainer documentation. Company sources establish what their organizations publish; they do not independently prove adoption or performance.