The agent can pay. The mandate is the hard part.
Stripe’s machine-payment infrastructure makes delegated spending tangible. The next design problem is deciding what an agent may buy, disclose, and commit the business to.
Editorial image for The agent can pay. The mandate is the hard part.VIBECIO Editorial Desk ·
A research agent finds the dataset it needs, purchases access, and continues working. No person visits a checkout page. That is a plausible product experience; it is also a compact transfer of authority. Someone has allowed software to choose a supplier, spend money, accept terms, and perhaps send information outside the organization. The payment is only the visible transaction.
In the public notes accompanying his September 17 conversation with Stripe’s Emily Glassberg Sands, Nate B. Jones separates several questions often compressed into “trust.” Can a service admit legitimate users without subsidizing abuse? What does a spending limit authorize? What information may an agent disclose? His introduction describes free-credit abuse that can consume compute before a payment ever occurs. These are product economics and permission problems, with consequences well before checkout.
Two protocols, different jobs
Stripe and Tempo’s Machine Payments Protocol announcement describes a programmatic exchange: a service requests payment for a resource, an agent authorizes it, and the resource is supplied. Stripe names per-session browser infrastructure and per-call web access among its examples. Those examples make machine purchasing concrete. They do not establish that agents now conduct most business payments.
MCP, the Model Context Protocol, addresses another part of the stack. Stripe’s MCP server exposes API operations and documentation to agents. Its current documentation requires human confirmation for certain write actions, including refunds and outbound payments, when agents use a person’s credentials. MPP and MCP can participate in the same workflow, but connecting a tool and coordinating a payment are different capabilities.
The architectural consequence is easy to miss. A service can be technically accessible and financially affordable while remaining outside an agent’s mandate. A procurement system therefore needs a representation of purpose alongside credentials and balance. A useful mandate might permit a named project to buy approved data from specified suppliers for a limited period. It would also define what information the agent can send and who handles exceptions.
A budget is not a purchase order
Consider a hypothetical agent comparing shipping services. It has permission to spend $100 on a shipment. A carrier offers a cheaper rate if the agent uploads the customer’s full purchase history. The price fits the budget; the information transfer may not fit the task. Increasing the wallet’s intelligence does not resolve that mismatch. The surrounding application has to express both constraints and enforce them at the point of action.
Purpose matters after the purchase, too. Buying an irrelevant report within budget is an authorized expense in one narrow sense and a failed assignment in another. A useful operating record connects the initiating request, the applicable policy, the chosen offer, the payment reference, and the delivered result. That relationship lets an operator investigate whether the problem was selection, permission, payment, or fulfillment.
The retry is part of the transaction
An agent asks a payment service to charge an account. The network times out. Repeating the instruction may be sensible; treating it as a new purchase may not be. Stripe’s idempotency documentation explains how a caller can repeat the same request with the same key and receive the stored result. It also documents retention and validation behavior. This is a specific API mechanism, not a promise that every step of an agent’s workflow happens exactly once.
The application still needs durable state. It should remember that a purchase was initiated before deciding whether to initiate another one. A payment reference must survive an agent restart. A delayed result must be reconciled with the outstanding operation. Changing an instruction from “try again” to “buy another” should be an explicit change in business intent, not a side effect of losing conversational context.
Sell an outcome the buyer can verify
For a software provider, serving agents creates a product-design opportunity. Describe the resource precisely enough for a machine to compare it: price, permitted use, expected result, completion signal, and a usable failure response. Provide a receipt that can be linked to the originating task. Record payment state and fulfillment state separately; a successful charge does not establish that the requested service arrived.
For an enterprise buyer, the useful launch metric is completed, authorized work per unit of spend, with disputed transactions and recovery effort visible beside it. That keeps cheap but ineffective activity from appearing productive. The companies that make delegated commerce usable will connect a purchase to a purpose, preserve its history through failure, and give people a clear way to change the mandate. The wallet is an enabling component. The product is accountable execution.
Sources