The new payment rails weren't built for old commerce

When I first started looking seriously at agent payments, I kept picturing a familiar transaction with a new payment method. Instead of me typing in a card number, my AI assistant would pay. Same buyer. Same seller. Same thing being bought. New rail.

That world is real. Companies are building agent checkout for exactly it, and it's genuinely useful.

But I think it misses the more interesting thing that's happening. And once I saw the difference, the whole space got easier to understand.

Two things are being called agent commerce

The first is an agent shopping in commerce that already exists. "Buy me running shoes." "Book the cheapest direct flight." "Reorder the groceries." The stores are familiar, the products are familiar, and mostly the payment methods are familiar too. Stripe and others are building the plumbing so an agent can get through a normal checkout safely. What's new is the shopper: an agent instead of a person with a browser tab.

That market is easy to picture, because it's the commerce we already know.

The second is the one that confused me, and it's the one this essay is really about: software buying things from other software, in the middle of doing a job.

A research agent pays a fraction of a cent for a web search. A coding agent pays a few cents to borrow a browser for a minute to test something. A data service charges per record it cleans up. An agent pays another service to run one specialized model, once, and never talks to it again.

Here's what makes those transactions strange: almost none of them would exist if a human had to approve each one. Nobody stops what they're doing to fill out a checkout page for a two-cent purchase. These transactions only happen because software can buy the thing by itself, mid-task, at a price too small to be worth a human's attention.

The first kind of agent commerce is a new interface to old transactions. The second kind is new transactions. Keeping those separate is the key that makes the rest of the ecosystem legible.

What x402 and MPP actually do

A quick grounding, because I needed one myself.

x402 makes payment part of an ordinary web request. When one piece of software asks another for something, the seller can answer: "sure, that costs two cents," in a format software can read. The buyer's software pays and asks again, and this time gets the answer. No account, no signup, no checkout page. Today the money is usually a stablecoin, a digital dollar designed to hold a steady value. The name is a nice bit of history: the web's original designers reserved error code 402, "Payment Required," decades ago, for a future that never arrived. It's being put to work now.

MPP, the Machine Payment Protocol Stripe helped introduce, tackles the same problem from a different angle. The seller tells the buyer what payment is required, the buyer satisfies it programmatically, and MPP is designed to work across different ways of moving money rather than tying the interaction to one payment rail.

The shared idea matters more than either protocol: software can find something, see a price, pay, and keep working, with no human at a checkout screen.

Why would a machine pay two cents for anything?

This was my other mental block. A two-cent purchase sounds absurd, because human purchases carry human overhead. You have to notice, decide, and check out. Nobody spends attention approving a two-cent decision, so two-cent products basically don't exist for humans.

Electricity is what unstuck me. You don't decide whether to buy each little burst of power your refrigerator uses. The system quietly consumes small units as part of doing something bigger, and you get metered for it.

Machine purchases can work the same way. An agent has a goal and a budget. On the way to the goal it buys a two-cent search, a five-cent data pull, a ten-cent model run. By the time the job is done it has spent, say, forty cents across six services. None of those were shopping decisions. They were inputs, the way electricity is an input.

Once you see the purchases as metered inputs to a job instead of tiny shopping trips, the prices stop being weird and start being the point.

One caution: don't stretch the analogy. Electricity is one commodity from one supplier. Agents buy many different things from many suppliers. The analogy only explains why the transaction size can collapse.

New buyers create new sellers

Here's the second-order effect I find most interesting, and it took me a while to spot.

Say you've built something small but genuinely useful: a tool that parses one obscure file format perfectly. Today you probably can't sell that. To charge for it you'd need accounts, billing, subscriptions, API keys, support. All that overhead means small capabilities get bundled into big products, given away, or never built at all.

Now imagine software can pay you per use, with no account. Your whole business can be one sentence: "Parses this format. Five cents a file."

If the cost of becoming a seller falls that far, the supply side changes too. You'd expect narrower services, one-purpose tools, specialized agents, sellers discovered at runtime and used exactly once. The catalogs already growing around x402 and MPP have that shape: search, scraping, data cleanup, model access, browser time. Small, narrow, machine-priced.

New buyers don't just buy old things a new way. They make new things worth selling.

This is the part I was missing: the new payment systems matter less because software can pay differently, and more because software can now buy things that were never worth selling to humans.

From resources to work

Most of what machines buy today is what I'd call a resource: a search, a model run, some compute, a minute of browser time. With a resource, delivery answers the question. The response came back. Done.

The next step up is a checkable output: clean up these records, extract these fields, structure this research. The thing arrives, but now you care whether it's complete and correct.

Farther out, and much less proven, is delegated work: "find 100 companies that meet these five conditions." "Build this campaign package." Now delivery tells you almost nothing. A file showed up. Was the work any good?

I want to label that progression honestly: it's an illustration of how the market could deepen, not a forecast. The resource layer is observable today. The work layer is a hypothesis.

But the work layer is where a genuinely new question shows up. Suppose an agent pays for those 100 companies and 97 actually qualify. Is that success or failure? A human would haggle. Software doesn't have to pick a side: it can record the partial result exactly. 97 accepted, 97 paid for. Traditional checkout can handle partial refunds after the fact. What it usually isn't built around is defining 100 units up front, accepting 97 of them, and making the economic result 97 earned from the start.

How this might feel, soon and later

Soon, plausibly: an agent researching a market quietly spends 42 cents across seven services while doing the job. You never see a checkout screen. You see a finished report and a line item. Or a coding agent pays three cents for a specialist tool it found at runtime, uses it once, and never creates an account.

Farther out, and this part is speculative: an agent hires another agent to produce 100 qualified records. That provider buys data from three services of its own along the way. A verification step checks the result against the agreement. 97 records pass, payment covers 97, and the output feeds the next paid step. A small supply chain, assembled and settled by software.

I'm not presenting that second picture as evidence. It's where the pieces seem to point.

New transactions need infrastructure we didn't need before

Human checkout evolved a whole support system around it: accounts, fraud tools, disputes, receipts, reviews. Machine-native transactions are starting to create their own set of needs, and they sort naturally by when they show up.

Before the purchase: who is this agent, what is it allowed to spend, and how does it find sellers in the first place?

During the transaction: prices software can read, and the payment protocol itself.

After delivery: what actually arrived, did it meet the agreement, what was earned, and can the result be shown to someone else?

A two-cent search needs almost none of that. But the richer the purchase, the more of those questions show up, and a checkout stack designed for humans buying products was never built to answer them.

Where Spoolis fits

This is the question that led me to Spoolis. Payment infrastructure is getting very good at answering: can this money move? We're working on the question next to it: did the work satisfy the agreement, and what was earned?

Spoolis turns the agreement and the evidence into an explicit Outcome: what passed, what failed, what was earned, and a signed receipt another system can check and act on.

I don't think every machine payment needs that layer. A two-cent search doesn't. The bet is that it matters more as software moves from buying resources toward buying work.

The part I keep coming back to

The biggest change may not be that agents pay differently.

It may be that software starts creating transactions humans would never have bothered to make. Tiny purchases inside workflows. Sellers discovered at runtime. Agents hiring agents. Payment per accepted unit of work.

Cards versus stablecoins is part of the story. The deeper change is that software is starting to buy, sell, and hire while it works.

Once that happens, we'll need infrastructure for transactions that barely existed before.