The Case for Agent-to-Agent Payments

Almost every payment on the internet still assumes a person is at the keyboard. Someone types a card number, clicks a confirm button, reads a receipt, and files it away. That assumption is about to stop holding. As agents start running real operations, they will pay other agents and services directly, and the case for agent-to-agent payments has moved from a thought experiment to a build order.

We spend our days on the money layer that agents plug into, so we watch this shift closely. Here is our view. Agent-to-agent payments will be ordinary within a few years, and the companies that matter will be the ones that give an agent a real account it can operate under permissions a human set, not a borrowed card number lifted from its owner's wallet.

What Agent-to-Agent Payments Actually Mean

Agent-to-agent payments are exactly what they sound like: one software agent paying another agent, or paying a service, without a human pressing the button on each transaction. The buyer is code. The seller often codes too. The money moves because a task required it, not because a person sat down to approve it.

Two shapes are already visible. The first is agent-to-service. Your agent needs a piece of data, an API call, a block of compute, or a search result, and it pays for that resource inline, the moment it needs it. The second is agent-to-agent proper. Your agent hands work to another company's agent, a research task or a fulfillment step, and settles up when the work comes back. In both cases the payment is small, frequent, and tied to a single unit of work rather than a monthly bill.

The pattern that makes this concrete is the revived HTTP 402 status code. A server responds to a request with a demand for payment, the client pays, and the request completes. The x402 standard builds on that idea and lets a client settle a charge and retry in one motion, with no account signup and no stored card. That is the primitive under agent-to-service payments, and it is live enough today to process real volume.

Why Cards and Human Dashboards Break at Machine Speed

Cards were built for a person standing at a register or filling out a checkout form. Sixteen digits, an expiry, a security code, and a chargeback window measured in months. The whole design assumes a human who buys a handful of times a day and disputes the odd bad charge weeks later. An agent does not work that way.

An agent buying computers or data might make thousands of tiny purchases in an hour, some of them worth a fraction of a cent. Card rails were never priced or timed for that. The per-transaction fee alone can dwarf the purchase. The settlement delay does not fit a machine that expects an answer in milliseconds. And the whole apparatus of storing a card number inside an autonomous process is a security problem, not a convenience.

Human dashboards fail for a related reason. A dashboard assumes a person will log in, scan a list, and approve or flag. When the operator is an agent running around the clock, nobody is watching the screen at three in the morning when the agent decides to renew forty subscriptions. The control has to move off the screen and onto the rail, where it holds whether or not a human is looking. Waiting for a person to click approve on every micropayment defeats the point of automating the work in the first place.

The Building Blocks Are Arriving

This is not one company's project. Several serious efforts are converging, and each has been announced publicly. Taken together they are the early scaffolding of a payments layer built for machines.

x402: an open standard, originated at Coinbase and now stewarded through the Linux Foundation, for paying over HTTP with stablecoins. It uses the 402 status code so a payment can happen inside a normal web request. The protocol specification is open source and network agnostic.

Stripe machine payments: Stripe has publicly described payment methods aimed at agents and machine-initiated commerce, including settlement in stablecoins alongside its existing rails. The pitch is a way for software to transact without a human in the checkout loop.

Mastercard Agent Pay: Mastercard has announced a program to bring agentic payments onto its network, with the network handling the trust and identity pieces around an agent-initiated transaction.

Visa Intelligent Commerce: Visa has announced its own framework for letting agents transact on its network under credentials and controls that a cardholder sets.

I am describing these in broad strokes on purpose. The details are moving month to month, and none of them has settled into a single dominant standard yet. What matters for the thesis is the direction. The largest payment networks and the largest developer platforms have all decided that agents will pay for things, and they are shipping the plumbing to let them.

Stablecoins Fit Machine Payments

A lot of this converges on stablecoins, and the reason is practical rather than ideological. A machine payment wants to be small, final, fast, and cheap to move. A dollar-denominated stablecoin like USDC settles on public networks such as Ethereum, Solana, Base, and Arbitrum in minutes, for a network fee of cents, at any hour, without a card network in the middle taking a cut size for human retail.

Programmability is the other half. A stablecoin transfer is a function call, which is exactly what an agent is good at. It can attach the payment to the request that needed it, verify the settlement, and move on, all in code. That is why x402 and several of the machine-payment efforts default to stablecoin settlement even when they keep the option of pulling from a card or a bank account behind the scenes.

The Open Problems Worth Naming

None of this is finished, and I would rather name the hard parts than pretend they are solved. Four questions are still open across the whole field.

Identity: when an agent pays, whose agent is it, and on whose behalf is it acting? A payment needs a verifiable answer to that, and the industry does not yet share one standard for agent identity.

Authorization scope: an agent should be able to do the specific job it was given and nothing else. Expressing that scope, in a form the payment rail can enforce, is still being worked out. A grant that is too broad is a liability, and one that is too narrow makes the agent useless.

Liability: if an agent overspends, buys the wrong thing, or gets manipulated into a bad payment, who carries the cost? The answer decides how much anyone is willing to let agents move, and it is more a legal and commercial question than a technical one.

Spend limits: caps have to live somewhere the agent cannot edit and cannot talk its way past. That means enforcement on the rail, not a number in a prompt the model can be argued out of.

I read these as a roadmap, not a verdict. Every one of them is a thing being designed right now, by networks, by protocol authors, and by the platforms that will carry the traffic. The direction is set. The standards are catching up to it.

How We Approach Agent Accounts at Meow

Our position follows from all of the above. An agent should not carry a human's card. It should hold and operate its own account, under permissions a human authorized, with the safety enforced below the model.

Concretely, that comes down to a few decisions we made deliberately.

Money movement is off by default: a Meow agent starts with zero ability to move money. It can read balances and prepare an action, but it cannot send a wire, run an ACH, or issue a card until the account holder turns that capability on. Nothing is live until a human makes it live.

A human-authorized permissions stack: the account holder toggles each capability explicitly, with caps attached. Wires on or off. ACH on or off. Card issuance with a daily and a per-transaction limit that a person set. Anything that needs a human route back to one, through Claude, SMS, Telegram, or the dashboard.

One API for money movement: the same interface covers ACH, wire, book transfer, international wire, card payments, and USDC or USDT settlement on several chains. An agent learns one surface, and the account holder controls all of it from one place. We expose this through an MCP endpoint, live today for Claude, ChatGPT, Cursor, and Gemini.

Credentials stay out of the model: account and routing numbers never enter the context window. The agent works through a scoped interface, so a leaked prompt or a poisoned session has nothing to steal. Every transaction still runs through the partner bank's BSA/AML and OFAC screening, the same as any other payment on the platform.

The parts of agent payments that are not yet standardized, shared identity and cross-network authorization among them, are on our roadmap rather than absent from our product. We would rather ship the account and the controls now, on rails that already work, and adopt each open standard as it stabilizes.

Where This Goes Next

Picture the near term honestly. An agent runs your cloud infrastructure and pays the computer bill per hour on a capped card. A research agent buys a dataset it needs for a single report and settles it in stablecoins the instant the file arrives. Your procurement agent negotiates with a vendor's agent and pays on delivery, with anything over a threshold pausing for your yes. None of that requires a leap of faith. Each piece exists in some form today.

The through line is that money movement becomes a capability a program calls, bound by rules a person sets, rather than a form a person fills out. We think that is the more useful shape for the next decade of software, and we are building for it now instead of waiting for the last standard to land.

Frequently Asked Questions

What are agent-to-agent payments? They are payments made by one software agent to another agent or to a service, without a human approving each transaction. The buyer, and often the seller, is code. Payments tend to be small, frequent, and tied to a single unit of work, such as an API call, a dataset, or a block of computer, rather than a monthly invoice.

Why not just give an agent a credit card? Cards were designed for a human who buys a few times a day and disputes bad charges weeks later. An agent can make thousands of tiny purchases an hour, sometimes worth fractions of a cent, which card fees and settlement times do not fit. Storing a card number inside an autonomous process is also a security risk. An agent is better served by its own account with permissions and caps enforced on the rail.

What is x402? x402 is an open standard, originated at Coinbase and now stewarded through the Linux Foundation, for paying over HTTP using the 402 Payment Required status code. A server asks for payment, the client pays with a stablecoin, and the request completes, with no signup or stored card. It is one of the core building blocks for agent-to-service payments.

Are stablecoins required for agent payments? No, but they fit the job well. A stablecoin transfer settles in minutes for a network fee of cents, at any hour, and it is programmable, which suits a machine. Several efforts, including x402 and parts of the network programs from Mastercard and Visa, use or support stablecoin settlement while keeping card and bank options available.

What are the biggest unsolved problems? Identity, meaning a verifiable answer to whose agent is paying and on whose behalf. Authorization scope, meaning a grant the rail can enforce. Liability, meaning who pays when an agent gets it wrong. And spend limits that live where the model cannot edit them. These are being worked on across the industry rather than settled.

How does Meow let an agent hold an account safely? A Meow agent starts with no ability to move money. The account holder turns on each capability explicitly, with daily and per-transaction caps, and anything that needs a person routes back to one through Claude, SMS, Telegram, or the dashboard. Account and routing numbers stay out of the model, and every transaction runs through the partner bank's screening.

Can an agent send a wire on its own with Meow? Only if the account holder turned wires on for that agent, and only within the caps set. By default wires and ACH are off. Anything above a threshold, or outside what was allowed, pauses for a human to approve or decline.

A Note on Meow

Some people see money movement off by default and read it as a missing feature. We see it as the point. An agent that earns each capability through an explicit human toggle, with caps enforced on the rail and credentials kept out of the model, is an agent you can actually trust with an account. Meow gives an agent one API for ACH, wire, book transfer, international wire, card payments, and stablecoin settlement, all under permissions a person sets. As the shared standards for agent identity and authorization mature, we adopt them on top of an account and a control model that already works.

The Money Layer Is Being Rebuilt for Machines

Agents are going to pay for the things they use and the work they hand off, and the rails for that are arriving faster than most people expect. The teams that give an agent a real account, with human-set permissions and money movement off until someone turns it on, will be the ones ready when it becomes normal. Open an account at meow.com.

Meow Technologies is a financial technology company, not a bank or FDIC-insured depository institution. Banking services are provided by Grasshopper Bank, N.A.; Member FDIC. The FDIC's deposit insurance coverage only protects against the failure of an FDIC-insured bank.