Agent Spending Without Controls — Rodrigo Coelho & Pranav Maheshwari, Edge & Node

An agent that needs blockchain data faces a practical question: how does it pay for the query? Rodrigo Coelho, CEO of Edge & Node, begins with this problem rather than a shopping checkout. Edge & Node built The Graph, a decentralized blockchain-data indexing protocol that he says has served 1.8 trillion queries. Its experience charging for data provides the starting point for Ampersend, the agentic-commerce project incubated within the company.

The Graph's query micropayment system dates to 2021, and Coelho recalls referencing HTTP 402 in a blog post at the time. Later research asked how agents could obtain data and make those small payments themselves. That work led into collaboration on Coinbase's x402 specification, including contributions drawn from the earlier micropayment and batching system. 1:42

Batching addresses the economics of very small purchases: the network fee for moving money can become an obstacle when the purchased unit is a tiny amount of data. Coelho describes using the prior batching work to reduce gas fees for nanopayments and mentions Circle's Nanopayments as work in a similar direction. The talk establishes the reason to batch, without developing the settlement algorithm or its timing tradeoffs.

Payment protocols are only one piece of the emerging stack. Traditional financial workflows assume a person somewhere in the process deciding whether a payment may proceed. Agents can keep transacting around the clock. Rules that depend on a person stopping to inspect each decision become difficult to apply at that pace—the systems need controls that operate during the transaction flow.

Coelho describes an early market: retail-payment experiments are appearing, while the enterprise teams he speaks with are still preparing infrastructure. In his account, compliance is a condition for adoption. A functioning payment rail answers whether money can move; an institution also needs to decide whether this particular transaction is permitted.

Several different questions sit behind that decision:

• Counterparty screening: Is the recipient or payer a sanctioned entity, or associated with prohibited activity?
• Identity: Who is behind the wallet address presented to the system?
• Spending and policy: Can the agent overspend or take an action that violates the organization's rules?

A bare wallet address supplies little context for those questions. Existing financial systems have identity and compliance processes, and agent transactions need corresponding infrastructure before an enterprise officer can sign off. The responsible person might be a chief legal officer or chief policy officer. Coelho emphasizes the potential scale of fines, including billions of dollars, as the reason governance cannot be an afterthought. Ampersend's proposed role is a financial harness around agentic checkout. The later demonstration will show one part of that harness: wallet screening.

Pranav Maheshwari turns the infrastructure question into an agent workflow. MCP servers give agents access to tools, but access to a tool's interface does not necessarily include permission to use its paid service. He presents two ways to obtain that permission: register and provide payment details separately with providers such as Exa and Firecrawl, or use a marketplace that aggregates tools and handles their payments.

Ampersend's entry point is a skill file installed in the agent. The intended experience is that a user stays inside the agent while the marketplace supplies access to paid tools and arranges payment. This moves the work of dealing with individual service providers into the aggregator. It also makes the aggregator and its payment infrastructure part of what the agent depends on to finish a task.

The first demo gives two agent sessions the same request: find email information for the head of crypto and blockchain at Mastercard. One session has the Ampersend skill and paid MCP tools; the other, shown in Claude Cowork, does not. The session without the skill returns Mastercard's email format and leaves the remaining lookup to the user. The equipped terminal returns a specific email address, a social handle, and location information. Because the comparison uses different agent environments, it illustrates access to a paid information source rather than isolating the skill file as the sole cause of the difference. 9:30

The causal step is the purchase behind the answer. The equipped agent reaches an endpoint that charges for the lookup, and Ampersend makes a small transaction to enable the search. The payment buys access to information the other session did not retrieve. Maheshwari initially moves on while navigating the transaction view; during the next demo, he returns to show the authorized transaction for this lookup.

This is the basis for Maheshwari's forecast that useful MCP services will increasingly charge. An agent may know which tool would help and still be unable to complete the task if it cannot pay for that tool. A wallet and payment gateway extend the set of services it can actually use.

The next request is more personal: buy a Father's Day gift through Shopify UCP, keeping the gift below $10. Maheshwari introduces it with the joke that he is generally a good kid. The terminal is expected to find online shops, identify suitable gifts, and purchase one using the Ampersend wallet. The payment capability now supports a physical order rather than a data lookup.

The workflow combines several capabilities:

• Discovery: Find shops and products that could satisfy the gift request.
• Remembered context: Reuse the user's name, address, phone number, and preferences instead of asking for them at each checkout.
• Purchase and follow-through: Place the order through the wallet, return a receipt, and expose order tracking in the terminal.

The order completes, but the spoken amounts complicate the budget claim. Maheshwari describes a $9 total, then says the purchase took $11, and subsequently calls it a $10 gift. The recording does not resolve whether these are item prices, additional charges, or a verbal slip. The demo therefore supports the checkout-and-receipt workflow; it does not establish that the final charge obeyed the requested limit. The distinction matters for the financial harness introduced earlier: expressing a budget in a prompt and enforcing it at payment time are separate requirements.

While the gift workflow finishes, the discussion returns to selling information. Maheshwari uses Cloudflare's x402 gateway as an example of a bot paying a microtransaction to obtain website content. His economic model is direct: when an agent retrieves information without participating in the site's advertising experience, charging for access offers another way to pay the publisher. He then returns to the gift, describing its payment as settled and showing the placed order and tracking. Both examples use an agent's payment capability to turn a request into access or a completed purchase.

The final demo returns to the merchant's decision to accept money. Buyer-side controls alone cannot answer every question for the seller: a merchant also needs to decide whether the wallet offering payment is allowed to transact. Maheshwari sets up two agents, Good Claw and Bad Claw, against the same paid website-scraping service. Bad Claw's wallet is flagged in the simulation; the explanation leaves open whether the flag comes from actual wallet history or simulated screening data.

The scraping service charges 0.1 cent for access to its information. With screening disabled and that setting saved, both agents' transactions authorize. This is the baseline: the service can accept payment from either wallet, including the flagged one. Payment authorization by itself does not apply the demonstrated blocklist policy.

Maheshwari then enables the screening feature built with TRM. It scans the wallet and changes the authorization result for Bad Claw: transactions that previously worked are rejected or denied, with the blocklisted wallet address given as the reason. Good Claw remains the allowed case. The useful change is selective refusal—the system continues serving the permitted payer while stopping the flagged payer. 18:12

What changes when screening is switched on? The comparison below keeps the two payers and the metered service fixed. It makes the policy's effect visible: the flagged wallet moves from authorized to denied, while the ordinary wallet retains access. This demonstrates a wallet-blocking control, a narrower capability than resolving every identity, spending, or compliance question raised at the beginning.

Maheshwari closes with a forecast about the agent interface: payments will increasingly happen through agent wallets or credit cards, and more MCP tools will become paid services. The proposed user experience combines tool access and payment infrastructure so the user can keep working inside the agent instead of visiting each provider's checkout.

The demos give that proposal two distinct responsibilities. Paying for a tool lets the agent retrieve information or place an order. Screening decides whether a particular payer's transaction should proceed. The closing refusal is as consequential as the earlier purchase: useful agent commerce requires the system to complete permitted transactions and stop prohibited ones.