I might be comfortable letting an assistant compare prices for me. Letting it spend my money raises a different set of questions: what exactly did I authorize, and how would I know if it went beyond that?
This reading made me think about the moment a recommendation becomes a financial action. For a product manager, that moment deserves its own design: a permission boundary that the user understands and the system can enforce.
What I took from the speech
SOURCE SUMMARY
At Sibos, Christopher J. Waller distinguishes agent-assisted shopping, where the buyer decides and pays, from agent-delegated shopping, where an agent receives authority to act. He highlights authentication, liability, and fraud as trust challenges, and notes that recurring B2B purchases offer useful structure while larger amounts increase exposure. He also discusses cross-border optimization and the choice between interoperable and platform-specific standards. [1]
My interpretation: the most useful product question is how to turn a person’s intent into a limited, checkable permission. The rest of this note is my proposed design approach and an illustrative example, rather than a description of an existing payment service.
Define the permission before the automation
“Take care of this purchase” leaves too much open. I would start with a plain-language mandate: the items, approved suppliers, total cost, timing, acceptable substitutions, and expiry. The user should be able to review and revoke it easily.
Reorder the listed printer cartridges from our approved supplier this month. Spend up to $100 in total, including tax and delivery. Do not change the item or supplier without asking me.
I would separate proposing an action from authorizing it. A model can compare options and prepare the order. A separate policy check should validate the final item, supplier, amount, and active permission before any payment attempt. Access to a payment tool should be limited to the scope of that permission.
The details need to survive checkout. If a delivery fee changes, or the consent expires while the agent is working, the system should evaluate the actual order again. An earlier approval of a different total should not silently become permission for the new one.
Explore the permission boundary
The same proposed purchase can require a different path depending on the user’s permission and the payment’s status. Select a scenario to see how I would design the handoff.
The pause should explain what changed and what decision is needed. For an over-budget order, I would show the full total and ask for approval of that specific change. A vague “continue” button gives the user too little context.
Design for uncertainty and recovery
A payment timeout is especially important: an agent might not know whether the payment succeeded. I would make “outcome unknown” a visible state, pause further attempts, and reconcile with the payment provider. Retry controls should prevent duplicate charges.
Users also need a practical way to stop future actions and report a problem. Revoking an agent’s permission does not reverse a completed payment; the product still needs a route into the appropriate refund or dispute process.
For review, I would retain a concise record of the mandate, its version, the order total, the policy checks, and the payment result. The useful evidence is what was authorized and executed. Sensitive data should be minimized, protected, and kept only for a defined purpose.
What I would measure before expanding autonomy
I would begin with a narrow, recurring task and evaluate both successful purchases and prevented mistakes. These are proposed evaluation questions, not results from a pilot.
| Question | Evidence I would look for |
|---|---|
| Does it respect the mandate? | Attempts outside the item, supplier, amount, or expiry limits are stopped before payment. |
| Does it ask at the right time? | Material changes prompt a clear request; valid orders avoid unnecessary interruptions. |
| Does failure stay contained? | Timeouts, retries, and revoked permissions do not create unintended charges. |
| Can people understand the outcome? | Users can find the order, explain why it proceeded or paused, and reach help. |
Before launch, I would also agree who owns exceptions across product, engineering, risk, operations, and customer support. A well-defined pause is useful only if someone can resolve it.
My product takeaway
For me, the interesting challenge in agentic payments is making delegated authority understandable in everyday use. The design needs to connect a clear mandate, enforceable limits, safe recovery, and evidence a person can inspect.
I would earn broader autonomy by showing that a small, bounded workflow behaves reliably—including when it cannot complete the task.
Before asking how much an agent can do, define what the user has allowed it to do—and what happens at the boundary.
Source & reading context
- Christopher J. Waller, “Payments in the Age of AI Agents” — Federal Reserve Board, Sibos 2026, September 29, 2026.
Read on October 2, 2026. The speech expresses Waller’s own views. The mandate, workflow, and evaluation framework above are my interpretation; they are not Federal Reserve requirements or a live payment implementation.