1. Capture intent without pretending it is policy
The principal begins with a goal: buy a flight, replenish inventory, acquire an API result, or pay an invoice. The agent can interpret and refine that goal, but the system must translate it into typed constraints before it becomes spend authority.
Keep the original instruction alongside normalized fields. The original preserves context; the normalized form makes policy deterministic. Record the interpreter and policy versions so later reviewers know how natural language became an executable boundary.
2. Discover offers and freeze the order state
The agent queries catalogs, merchant APIs, browser surfaces, or tools. It compares offers, but authorization should target a final, immutable order snapshot: seller, items, quantities, taxes, shipping, fees, currency, cancellation terms, and expiry.
If the order changes after approval, the agent returns to policy. This prevents a harmless-looking cart from becoming a different transaction between approval and payment.
3. Evaluate policy and decide whether to step up
A policy engine evaluates the exact transaction against budgets, merchant rules, purpose, risk signals, and the standing mandate. The output is not just allow or deny. It can require a narrower credential, additional authentication, human review, or a new quote.
| Signal | Normal result | Escalation trigger |
|---|---|---|
| Amount | Within remaining budget | Threshold exceeded or unusual denomination |
| Merchant | Allowlisted or known category | New seller, risky category, identity mismatch |
| Terms | Refundable and expected | Non-refundable, recurring, or materially changed |
| Velocity | Expected cadence | Burst, duplicate, or out-of-hours behavior |
| Rail | Approved custody and asset | Irreversible route or unsupported jurisdiction |
4. Present the narrowest useful credential
The agent should never receive an unrestricted treasury key or reusable primary credential when a seller-scoped, amount-limited, time-limited token will work. Signing belongs in an isolated wallet or credential service that enforces policy independently of the model runtime.
Card payments may use network or processor tokens. x402 clients sign a payload in response to a 402 challenge. Bank flows may create a consented payment instruction. In each case, the payment request carries a durable idempotency key and binds to the frozen order.
5. Reconcile payment, fulfillment, and recourse
Authorization, capture, settlement, and fulfillment are different states. The agent must not report success merely because a wallet signature was created or a processor returned an authorization. Join payment identifiers to the merchant order and track the promised outcome.
Refunds and disputes depend on the rail. Card systems have established reversal and dispute paths. An irreversible onchain push generally requires a compensating transfer or escrow-like design. The user experience should communicate that difference before the transaction, not after a failure.
Commercial finality is not the same thing as technical settlement finality.
6. Preserve a reviewable evidence chain
A complete record connects the principal, agent, intent, normalized mandate, order snapshot, policy result, credential reference, payment result, fulfillment, and remediation events. Store protocol and schema versions, timestamps, request hashes, and cryptographic verification outcomes.
The record should answer operational and user-facing questions without replaying a model conversation as the source of truth. Model traces help explain planning; signed mandates and system records establish authority and outcome.
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.