Agents Have Started Buying Things Link to heading

Not browsing. Buying.

The first wave of software agents read the web. The next wave transacts on it, and the plumbing for that arrived while most of us were still watching the models. It is early, and the volumes are small, and in two years nobody will remember that it was ever a question.

Every conversation about how those agents pay assumes they pay with money. A card, a bank transfer, a stablecoin. Meanwhile the customer the agent is working for is very often holding a balance they already own, in a programme with a real ledger behind it, and nobody has built the connection.

I think that is the most undervalued asset in travel and retail today. I have spent the last few months writing the specification that connects it, and this is the business case rather than the specification.

The Standard Everyone Missed Link to heading

HTTP has had a status code for “payment required” since 1997. Code 402. It has sat unused for its entire existence, because there has never been a payment method cheap enough and fast enough to make charging for a single request sensible.

x402 is the current attempt to fill that gap, and I think it is the one that works.

The thing to understand, and the thing almost every article about it gets wrong, is that x402 is not a crypto product. It does not move money. It defines how a server states its terms, and how a buyer proves it met them. That is the whole protocol. The actual movement of value is a plug-in, and crypto was simply the first plug that fitted, for two unglamorous reasons: it settles fast enough to sit inside a single web request, and it has no minimum charge.

That distinction matters commercially, because it is the difference between a bet on a currency and a bet on a convention. Universal payment networks have been announced and buried roughly every four years since the mid nineties. Conventions for how two computers agree on terms tend to outlive everyone who argued about them.

One Mechanism, Six Orders of Magnitude Link to heading

Here is the part I find hard to argue against, and the part I would put on the first slide.

One mechanism covers all three rows. The same exchange, the same proof, the same receipt. What changes between a tenth of a cent and an airfare is a single declared setting, not a second payment integration.

Nothing else spans that range. Cards have an economic floor, invoicing has a frequency ceiling, and subscriptions need a customer relationship, which is fine for a person and useless for an agent that will deal with you exactly once and never return.

And an agent needs the entire range at once. Booking a trip is a few hundred cheap lookups and one expensive purchase with a hold on it. If the cheap part and the expensive part need two different payment stacks, your agent is doing systems integration instead of booking a trip.

If It Does Not Care What the Money Is Link to heading

Follow that through, because this is the move.

If the protocol does not care what is moving value, then what is moving value does not have to be money. It needs four properties: an authoritative ledger, a way to establish who is allowed to spend, settlement that fits inside a request, and proof afterwards.

That is not a description of a blockchain. It is a description of a loyalty programme.

What You Already Have, and the One Thing You Do Not Link to heading

Every airline, hotel group, retail group, outlet store and supermarket in the country is already running the hard part.

You have members. You have balances. You have issuance rules, tier logic, expiry policy, reversal handling, dispute processes, a settlement function and decades of audited operation. Most importantly you have the thing that is genuinely difficult to bootstrap and impossible to buy: millions of people holding a balance who would like to spend it.

What you do not have is a transaction protocol.

Partner integration in loyalty today runs on proprietary APIs, three concurrent generations of API contract, batch files, SFTP, spreadsheets, rejection reports and monthly reconciliation. The cost of that is not really the engineering. The cost is that you discover what happened at reconciliation rather than at the transaction. Disputes are retrospective. Corrections are batched. The member waits weeks for points that were earned in a second, for no reason a customer would accept if you explained it to them.

Every one of those problems exists right now, in production, with no agents involved anywhere.

What It Is Worth Link to heading

Four outcomes, in rough order of how quickly they land.

Partner onboarding stops being a project. A new partner today is months of bespoke integration against whichever generation of your API they were given. Against a published standard it is a conformance exercise. That is a direct reduction in the cost of growing the network, and it compounds, because every partner you add gets cheaper rather than more expensive.

Reconciliation becomes a by-product instead of a function. When the transaction itself produces verifiable evidence of what happened and who owes for it, your settlement position comes out of the transactions rather than out of a monthly file exchange and a team of people chasing variances.

Points become spendable in places you will never integrate with individually. Not through a partnership deal signed with each merchant, but because any merchant who accepts the standard can accept your points, with your ledger still deciding every answer. The programme keeps authority over balances, eligibility and economics. What it gains is reach it did not have to negotiate.

And then the strategic one. When an agent is choosing how to pay for something on behalf of a customer, it will choose the cheapest acceptable instrument the customer holds. Points are frequently the cheapest money a customer owns and the hardest to spend. Make them the easiest, and your programme becomes the default payment method for agentic commerce in your category. First mover takes that position and the second mover argues about it in a procurement meeting.

Spending Is the Easy Half Link to heading

Both directions matter, and they are nothing like each other in difficulty.

Spending is straightforward, and that was the encouraging result. A member exchanging points for a hotel room is a payment in every meaningful sense: an amount, an approval, a settlement, a receipt, and the usual need for holds, cancellations and refunds, all of which the standard already covers. It is not a new kind of transaction. It is an existing kind pointed at your ledger instead of a bank’s, and it needed no new invention from me at all.

Earning is the half that everybody, including me, underestimates.

There is no moment to hang it on. Nothing is being withheld, so there is no point at which a price can be quoted and met. The hotel stay earns on checkout, which may be three weeks after any software conversation took place, asserted by a property system that was never part of it, on behalf of a partner the member has never dealt with, and usually with no agent anywhere in sight.

And the constraint that settles it:

Room               $300
Paid with          an unrelated credit card
Points earned      +900

A qualifying purchase does not have to be paid for with points, so earning cannot be attached to the payment, because most of the time there is no payment to attach it to. That sounds like a technicality. It is the whole design problem, it is why earning needed genuinely new work rather than a configuration change, and working out precisely where the existing standard stops is the part of this I think is worth other people’s attention.

The Endpoint I Had to Delete Link to heading

One decision worth surfacing, because it is the kind that does not show up in a delivery plan.

My first sketch had an obvious API on it: let a partner check that a member exists before issuing points to them. Every integration I have seen does something like it.

It had to go. A partner funding points has no business knowing who the member is. A hotel paying an airline to issue points to a guest needs to know the points landed somewhere valid and that it now owes for them. It does not need the frequent flyer number, and in most jurisdictions it should prefer not to hold it.

So the customer’s side of the arrangement issues a one-use, identity-free token instead, and the programme resolves it to an account, because the programme is the only party that can and the only party that should. The convenient version of that endpoint would have leaked member identity to every partner in the network, by design, permanently, and been politically impossible to remove once anyone depended on it. Deleting it before it existed cost nothing. Deleting it in three years would cost a programme of work and a round of partner renegotiation.

Why This Can Be an Open Standard Link to heading

Here is the piece I would lead with in front of a commercial team, because it is the question that kills this kind of initiative.

Why would you publish anything about how your partners integrate with you, when your competitors can read it?

Because the protocol carries no economics. It says what happened. It does not say what anyone paid for it. No rates, no tiers, no volume commitments, no liability calculations. Those stay where they belong, in your commercial systems, referenced by the transaction as an opaque identifier that means nothing to anybody who reads it.

That one constraint is what makes the whole thing commercially safe. Two competing partners can fund parts of the same transaction, for the same customer, on the same stay, and neither learns a thing about the other’s deal. A programme can implement an open standard without publishing a single commercial term. Had I let rates into the protocol, no two competing partners could ever have implemented it on the same network, and the standard would have been dead on arrival.

Protocol design and commercial strategy are the same conversation here. That is not a technical observation.

It Pays for Itself Without a Single Agent Link to heading

The constraint I would most like to survive contact with a delivery plan is this one: none of it requires an agent.

A point of sale terminal has to be able to use it. A server-to-server integration has to work with no customer present and nothing in flight. There has to be a batch migration path, because a standard that demands a big-bang cutover is a standard nobody adopts and I would rather not write one of those.

Agentic commerce is the catalyst here and by far the most demanding customer, because an autonomous buyer needs everything discoverable and provable with no human to fall back on. It is not the justification. If every agent vanished tomorrow, a protocol that let a partner issue points in one standard interaction, take away proof of it, and work out what it owes from that proof instead of from a monthly file would still be worth building.

Which is also, conveniently, how you get a meeting. “This is for agents” is a research project. “This removes your reconciliation overhead and your partner onboarding cost, and it happens to be ready for agents” is a business case with a hedge built into it.

Where It Is Up To Link to heading

The draft is converged, and the submission package is written to the structure the standards body actually uses, so each piece can be lifted into the slot it belongs in rather than being reshaped by a maintainer who did not ask for it.

What is left is peer review. I have a handful of readings to run down with people who know the loyalty side considerably better than I do, because the fastest way to find out an assumption is wrong is to hand it to someone who has operated the thing it assumes. Once those are back, it goes up. Weeks, not months.

Consider this the note that precedes it.

The Short Version Link to heading

Agents are starting to buy things, and the mechanism for letting them has quietly arrived. It is a convention for agreeing terms, not a currency, which is why I think it lasts.

It is the first payment mechanism that works at a fraction of a cent and at two thousand dollars without changing anything, and an agent needs both of those at once.

Because it does not care what is moving, what is moving does not have to be money. It needs a ledger, permission, settlement and proof, which is a description of your loyalty programme.

You already run the hard part. What is missing is a standard way to transact against it, and the absence of one is already costing you in partner onboarding, reconciliation and the three weeks a member waits for points earned in a second.

Spending points is a payment and the standard nearly covers it. Earning is not a payment at all and that is where the real work was. Keeping commercial terms out of the protocol is what makes it publishable. And the whole thing pays for itself with no agents in the picture, which is how you can tell the problem is real.

The programme that becomes the easiest thing for an agent to spend becomes the default, and there is one of those positions available per category. If you want that to be yours, then you probably need to look at next quarter’s resource allocations.

Follows on from Let the Good Bots In, which argued that HTTP 402 lets you sell the machine-readable answer rather than the page view, and closed with an aside about giving well-behaved agents a loyalty rate that I have evidently taken too literally. Prices and figures above are illustrative. The specification, with the parts I have skipped over here, follows shortly.