Agents Can Build Anything. Then They Hit the Paywall.

Prompt-to-code tools made the first version easy. Describe an app in plain language and watch it run. The hard part was never the prototype. It is production.

The moment a vibe-coded app leaves the demo, it has to connect to the real world: SMS and email to reach users, a processor to charge them, a data API to feed it, compute to run it. Every one of those connections is the same chore. Create an account, authenticate, add a card, wire a key. Now hand that chore to an autonomous agent and it stalls. Agents are built to decide and act. They were not built to fill in a signup form and a billing page.

Here is the part that gets skipped: every one of those connections is also a payment. Every action an agent takes that touches the outside world eventually settles as one. Sending a text message is a payment. Spinning up a server is a payment. Calling a paid endpoint is a payment. Buying from a supplier is a payment. Once you see it, the agent's job stops being "reason and act." It becomes "reason, act, and settle."

But a payment is not one thing. In Sao Paulo it is a Pix, and it needs an invoice. On Base it is USDC over x402. To a SaaS vendor it is a card. Same intent, three different rails, three different sets of rules. The hard part was never "let the agent pay." It is this: pay on the right rail, with an identity the counterparty can trust, under a limit the owner set, and leave a receipt someone can audit later.

The four things under every agent payment

A programmable wallet with a slot per rail. One budget, denominated where it needs to be: BRL for Pix, USDC for x402. No silent FX, no pooled float, no custody games.

A signed mandate. Before an agent spends, it holds a mandate with a cap, an allowlist, and an expiry. Inside it, the agent decides what to buy and when, with no human in the loop. Outside it, nothing moves: a two dollar request against a one dollar cap is refused before any money does. The owner approves the budget once, not every purchase.

A facilitator and a real fiat rail. x402 settles the micropayments that pay-per-call APIs want. Pix moves regulated money in Brazil, with the NF-e attached. Buy side and sell side, crypto and regulated fiat, in the same wallet.

A receipt on every payment. Each settlement seals a hash-chained record: who paid, under which mandate, on which rail, for what. Verifiable offline. Not a log line. A receipt a CFO can stand behind.

We run it in production, with real money

This is where machine payments stops being a whitepaper.

On Base mainnet, an agent paid real USDC for a resource it had never seen before, discovered at runtime, gasless for the payer, under a fresh mandate, and closed with a hash-chained receipt. The negative check held: the over-cap attempt was refused before it touched the chain. The same primitive moves USDC directly from one agent to another, the raw leg under payouts and splits.

In Brazil, an agent paid a real Pix under a signed mandate, settled through a licensed rail, with the fiscal document issued. Not a sandbox. Real cash-out to a real account.

And our gateway turns any endpoint into a per-call paywall: point it at your API, set a price, and an agent pays to call it, settlement and receipt included. The catalog and SDK are open source. The managed runtime, wallet, policy engine, and audit trail are where we charge.

Why the rails have to be plural

Most of the agent-payments conversation assumes one rail: a card, or a stablecoin. That covers a slice of the world. It does not cover a supplier in Brazil paid by Pix with an invoice, a data API billed per call in USDC, a payout split to another agent under a known identity, or a refund and reconciliation that has to survive an audit.

The agentic economy is money movement, and money movement is local and regulated where it counts. Rails that only speak crypto, or only speak US cards, will always hand the last mile back to a human. We built for the whole surface: multi-rail, buy and sell, production and regulated, with identity and receipts wired in from the start.

Where this goes

The near future is easy to state. As agents get more capable, they consume more: more APIs, more data, more compute, more of each other's work. Every unit of that consumption is a payment. Thousands of tiny settlements per task, running in the background, add up to a volume of machine payments that dwarfs human checkout. The buyer stops being a person clicking a button and becomes a fleet of agents settling continuously.

And agents will not only spend. They will earn. An agent that sells a skill through a paywall and spends that revenue on the data it needs is a business with a balance sheet, run by software. Agent pays agent. Payouts split between the agents that did the work. A closed economic loop that never waits for a human to approve a line item.

That economy will not run on one rail. A supplier in Brazil settles in Pix with an invoice. A data feed settles in USDC per call. A SaaS tool settles on a card. The internet of agents is global by default, and money is local and regulated by default. The layer underneath has to speak every rail, carry an identity on every transaction, and seal a receipt on every settlement. Anything less hands the last mile back to a human, which is the one thing this future is meant to remove.

The question changed

Machine payments is no longer a question of whether agents will pay. They already do. The question is whether the rails underneath are real, governed where money is regulated, and auditable after the fact.

Ours are, today. If your agents are one payment away from done, that gap is the product.