When software can pay
Thoughts on agents that can spend money
July 9, 2026
ai-agents
payments
economics
When I put GrasShopper aside, one of the things I noticed about the competition was that Perplexity’s shopping assistant already had checkout for selected products. Mine only ever recommended things, theirs could also buy them.
That’s a bigger step than it looks. A program that finds an answer is one thing. A program that pays for something makes a commitment with somebody’s money, and then I want to know who gave it the authority (the same question I had about what an agent is allowed to decide).
In September 2025 Coinbase announced x402 Bazaar, a discovery layer where agents can find services that accept x402 payments. It’s a vendor announcement, so it shows what is being proposed and says nothing yet about adoption. But it’s a concrete attempt to connect finding a service, using it and paying for it.
Automated payments aren’t new. What’s new is a system that picks an unfamiliar service in the middle of an open-ended task and then pays for it. You’re uncertain about the task and about the supplier at once.
Say an assistant is preparing a technical comparison and finds a paid dataset that looks useful. Price is only one thing it should know before buying. The dataset can be outdated, unsuitable for the purpose, or come with conditions that matter later. A payment that went through doesn’t mean something useful was bought.
People like to talk about removing friction, and some friction really is pointless: filling in the same form again, one more password, a person manually copying a response that a machine could read. Other friction is a decision about a commitment. If you remove that one, the decision has to move somewhere where a person can still see it. In Graspable I kept this kind of friction on purpose: the agent edits the project on its own, and anything risky waits for an approval.
So I’d want a purchasing agent to work with a clear purpose, a budget, a list of acceptable counterparties and some evidence that the job was completed. I should be able to understand why money was spent and what I got for it. A list of successful transfers doesn’t tell me that, the same way a provenance record doesn’t tell you whether an image is true.
There’s an upside I’m curious about. Small tools and specialized services could become much easier to combine if each of them doesn’t need its own integration and subscription. Somebody building something unusual could put it together from many providers. It could also end as a maze of small dependencies, where a workflow looks cheap until the repeated calls add up.
Transaction volume will tell us that payments happened. I’d rather know whether people got more of what they wanted done, with enough control to understand what they paid for.