The agent can pay. It just can't fund the payment.

Picture a small research agent. Its job is to pull market data from a paid API a few hundred times a day. The API doesn't want an account or a monthly invoice. It wants a few cents in USDC on Base for each call.

The agent has a budget its owner signed off on. The API sends back a clean, machine-readable price. Both sides are doing everything right, and the call still fails, because the owner's money is USDT on another chain, or cash sitting in an exchange account. The agent is allowed to pay and it knows exactly what to pay. It just has nothing in the form the seller accepts.

I keep coming back to that example because it shows where agentic commerce actually gets stuck. The hard part isn't teaching an agent to buy something. It's getting money to the right place first.

The pieces that already work

A lot of the stack is real now, and it's worth being specific about what each piece does.

Permission is the first layer. Google's Agent Payments Protocol uses signed mandates. An intent mandate records what the owner asked for and the limits around it, and a cart mandate locks in the exact items and price before anything is paid. The card networks are building the same idea into their own rails. Visa Intelligent Commerce swaps card details for tokenized credentials that confirm a consumer's chosen agent is allowed to act for them, and Mastercard Agent Pay does it with Agentic Tokens built on its existing tokenization.

Commerce is the second. Stripe and OpenAI's Agentic Commerce Protocol gives merchants a shared language for selling through an agent, and Stripe's shared payment tokens let the agent start a payment without exposing the buyer's card, scoped to one merchant and one cart total.

Settlement is the third. Coinbase's x402 brings back HTTP's old 402 Payment Required code. The server answers an unpaid request with a price, an asset, a network and a payee. The client signs a payment, retries, and gets the resource back. For an API that bills per call, that's about as simple as payments get.

Each of these is good work. But if you read them side by side, they all assume one thing: by the time the agent pays, it already holds the right asset.

Where agents fail today

The way I think about it, agent payments split into four layers: permission, commerce, funding and settlement. The protocols define three of them and assume the fourth. x402 tells a buyer how to pay a seller who has named an asset and network. It doesn't say how the buyer got that asset. AP2 records what was authorized, not where the money comes from.

That gap matches what I've seen building trading products. People almost never hold money in the exact form a product wants. It's in the wrong account, on the wrong chain, in the wrong token. Every deposit flow I've worked on was really a flow for fixing that mismatch, and most of the drop-off happened there.

A person can deal with the mismatch. They open an exchange, swap, bridge, wait, and try again. An agent can't do that halfway through an HTTP request unless someone built the path for it ahead of time. So the failure isn't intelligence. The agent hits a 402, sees "USDC on Base," checks its wallet, and stops.

Cards hide this problem, which is why it's easy to miss. The card network converts between whatever the cardholder's account holds and whatever the merchant accepts. I suspect that's a big reason the first consumer agent shopping is running on card rails. It's also why the funding gap shows up first in machine-to-machine payments, where the seller names one token on one chain.

Where stablecoins fit

Stablecoins are a good fit for agents for plain reasons. They settle in seconds, they work for very small amounts, and they don't need a human to log in. Circle now has Gateway nanopayments that batch tiny USDC payments for agents and settle them onchain later, with support for x402.

The catch is that "stablecoins" isn't one thing. USDC on Base and USDT on Tron are both dollars to a person. To a server checking a payment signature, they're different assets on different networks, and one of them is simply wrong. The more chains and stablecoins there are, the more often an agent will be holding a perfectly good dollar that the seller can't take.

Some of the tooling narrows the gap. x402 can now accept any ERC-20 through Permit2 and lets a seller list more than one payment option. Circle's CCTP moves USDC between chains, and Gateway gives an agent one USDC balance across them. Those help when the owner already holds USDC somewhere. They don't help much when the money is USDT, or a cash balance on an exchange.

A workflow I'd actually ship

If I were designing the payment flow for an agent today, I'd make funding its own step, with its own checks, instead of hoping it's already done.

The mandate comes first. The owner sets a budget, the assets the agent may spend or convert, the sellers it can pay, and when the permission expires. The conversion rules belong in the mandate too. Permission to spend $20 on data isn't the same as permission to sell ETH to raise it.

Then the request. The seller's 402 says what it wants: amount, token, network, payee.

Then the funding check, which is the step I care most about. Does the agent already hold that exact asset? If not, where does the owner hold value, what's the cheapest path from there, and can it finish before the request times out? A few payments and crypto connectivity companies already work on this for human checkouts, looking at what a customer holds across connected wallets and exchanges and routing it into the stablecoin the merchant wants. Circle's tools sit here too, for USDC. Whoever does it, the step also has to confirm the payee is who it claims to be, because a stablecoin transfer can't be pulled back.

Then settlement, which x402 already handles well. Last, the receipt. The seller's settlement response gets logged against the mandate, so the owner can see what was bought, what was converted and what it cost.

One rule ties it together. If funding fails, the agent stops and asks. It doesn't go looking for a looser way to pay.

The biggest constraint

I don't think the biggest constraint is the protocols. They're arriving quickly and they're mostly compatible. AP2 launched with an x402 extension, for example.

The constraint is that funding is an infrastructure problem, not a message format. To fund a payment you need live, authorized connections to wherever the owner's money sits, whether that's an exchange, a self-custody wallet or a bank. You need routing that can convert and bridge on a deadline, and verification you can trust before something irreversible happens. None of that comes from two parties agreeing on a JSON schema.

Funding is also where the risk piles up. A mandate that lets an agent convert assets is a much bigger grant than one that lets it spend a balance. Spend controls help, and anyone wiring an agent to x402 should cap what the client will sign. But a cap on payments doesn't cover a swap two steps earlier.

So when I look at an agentic payments product now, I skip the demo of the agent buying something. I ask what happens when the agent holds the wrong dollar. If the answer is a clear funding step, with limits the owner set and a receipt at the end, the product is real. If the answer is "the user tops up the wallet first," the human is still doing the hardest part.

More in the writing hub.