A Wallet Is Not Permission

When a business hears that software can now buy things, the first instinct is to add a payment button. That is the wrong first move. A wallet moves money. Permission decides whether money should move.

The last decade trained operators to treat checkout as the control plane. Card networks, invoices, refunds, and fraud scores all sit at the moment of charge. Agent commerce breaks that map. An agent can find a product you never marketed to machines, burn expensive tokens researching it, retry a negotiation until the price yields, and only later attempt a purchase. If your only control is the payment rail, you have already paid for the damage that happened before checkout.

This is a different job from the ones most teams have already named. A rented personal assistant that can text, book, and hover near a credit card needs a halt owner. That is about stopping a helper that lives in your messages. An agent loop that keeps thinking until the token meter screams needs a labor budget. That is about the cost of inference. Agent commerce is what happens when software becomes the customer. It shops. It compares. It tries to pay. It does not care about the relationship you thought you were building with a human buyer.

Demand is already showing up that way. Teams that sell usage, billing, and trust infrastructure are seeing agents find products that were never redesigned for them. The product did not change first. The buyer class did. That is historically how new channels arrive: mail order, the web, mobile wallets. The winners were not the firms that bolted a new button onto an old policy. They were the firms that rewrote who may buy, under what envelope, and what “done” meant after the money moved.

A usable grammar is simpler than a marketplace. Some purchases can be pre-authorized inside a named envelope: coffee, postage, a replacement part under a hard dollar cap. Some purchases need a human look before money moves: a couch, a tool, a vendor change, anything that alters the shape of the business. Some purchases should never be silent: a subscription, a recurring vendor, a contract that keeps charging after the original itch is gone. If you cannot name which of those three a job is, you do not have an agent-commerce policy. You have a hope wearing a checkout form.

Fraud has to move earlier too. Classic card fraud assumes the bad event is a stolen number or a charge that should not have posted. Agent-era abuse often happens before money. Someone steals inference. Someone burns your usage meter. Someone uses your agent as a free researcher and walks away before the cart. A charge-time fraud score cannot see that. Reliability starts at the first expensive action, not at the receipt. If you only watch the wallet, you will call the system safe while the expensive work is already gone.

Sellers have a matching problem. An agent does not talk to your sales team. It does not remember the favor you did last quarter. It retries until the market yields. Relentless negotiation with no relationship layer can erode the surplus you thought lived in human conversation. If your only buyer score is “is this a real human card,” you will either block legitimate agent purchases or get eaten by software that never gets tired. You need a policy for agent-as-buyer: what they may purchase, under what envelope, with what evidence of authorization, and what happens when they retry the same cart at 2 a.m.

None of that is an outcome contract. A spend cap says do not exceed forty dollars. An outcome contract says the job is done when a named result is true, a named inspection happened, and a human accepted it. Buyers will hide how much they value the outcome. Vendors will try to bill for usage and call it success. A wallet can settle a charge and still leave the work unfinished. If you skip the Done Contract, you will get a very efficient way to buy the wrong thing.

Redesign the work before you shop for a wallet. Write an Agent Commerce Permission Card for every job that might spend:

1. A named spend envelope, with a hard stop when the envelope is empty.
2. A human approve-before-spend threshold, written in plain language, not buried in a plugin screen.
3. Abuse coverage for expensive work before checkout — tokens, research, retries — not only for the card charge.
4. A seller policy if an agent is the buyer: what is allowed, what evidence of authorization you require, and how retries are treated.
5. An outcome / Done Contract that a receipt cannot fake.

That card belongs in the same place as the rest of the job: the SOP, the skill, the definition of done on the board. It does not belong in a vendor settings panel. Payment rails, usage billing, and model routers can be useful later. They are not permission. They are not a halt. They are not proof the purchase finished the work.

Small businesses do not need an agent-to-agent marketplace. They need one honest answer to a blunt afternoon question: if software tried to buy on our behalf today, who would have to say yes, how would we know the purchase was inside the envelope, and how would we know the job was actually done?

Until that answer is written down, a wallet is just a faster way to be wrong.