Why Your AI Agent Needs a Wallet: USDC and Nanopayments — Harshal Bhangale, Circle

An agent can have a capable model, many tools, and elaborate orchestration, then stop at a paid endpoint. Someone has to create an account, enter payment information, or manage an API key before work continues. Harshal Bhangale, an engineer on Circle’s Agent Tech product team, opens with this practical reason for bringing a stablecoin company to an AI engineering conference: Circle issues USDC, and payment can interrupt an otherwise automated task. 1:14

The proposed next step follows a progression from prompts in 2023, to workflows in 2024, to MCPs, skills, and orchestration in 2025. Bhangale expects 2026 to bring agents that purchase the services they need. He cites approximately $24 million transacted against paid API endpoints over x402 in the preceding thirty days, with 99% settled in USDC. These are his adoption figures for that window, rather than a measurement of the entire agent economy.

x402 gives a paid resource a request-and-retry flow. An agent asks a server for something; the server returns 402 Payment Required with payment details. The agent signs a payment authorization using its wallet and retries the request to obtain the resource. Payment becomes part of the API interaction, avoiding a detour through a human signup process. 2:45

That flow fits a different pattern of consumption. A human might buy a subscription and browse a service over time. An agent may need one piece of data, a little compute, or a single inference result while completing a larger task. It can inspect hundreds of pages, then skip the paid endpoint that would have supplied a useful answer. Selling that endpoint’s output in a small increment gives the agent another way to continue.

Two changes have to meet:

• Buyer behavior: Agents purchase small amounts at high frequency. Payment overhead repeats with every call, so both cost and latency matter.
• Seller packaging: A merchant can sell a subset of its data instead of requiring a subscription. Bhangale’s example is a ten-cent purchase for one piece of data, with repeated API calls producing repeated small payments.

Bhangale uses a roughly 3% card fee on a one-cent transaction to illustrate the mismatch. A percentage alone does not explain the full economics; Circle’s supplied Nanopayments deep dive also identifies fixed fees, settlement latency, and operational overhead. The target is payment that works at the rhythm of API calls: real-time, low-cost, programmable, and always available. Circle Agent Stack connects those requirements.

After some terminal-window wrangling, the demo puts two Claude Code sessions side by side. One is a regular session; the other has a funded Circle agent wallet and can pay for premium content. Both receive the same assignment: plan Bhangale’s trip to the FIFA World Cup final. 7:06

The task crosses several kinds of information. It asks for flights, hotels, and logistics; Argentina’s chances of reaching the final and its possible opponent; secondary-market ticket prices; and practical advice from people who have visited the stadium. The requested output goes beyond research: email the summary, then, if possible, call and brief him. A six-to-eight-minute instruction keeps the demonstration moving.

Both sessions begin working. The regular session launches subagents and researches hotels and flights. The wallet-equipped session purchases premium information. One paid API request carries a fifteen-cent maximum; another queries Polymarket data through a provider and parses the results under a spending limit. Payment becomes another step in collecting the trip’s inputs.

The spending controls belong in the wallet. Approving every one-cent, five-cent, or ten-cent purchase would turn a fast agent into a queue of human interruptions. Instead, the owner sets limits and the wallet enforces them while the agent chooses individual purchases. A maximum for a request and a session or daily cap control different scopes: permitting one small purchase does not grant an unlimited budget. 9:13

The first clear divergence appears at email delivery. The regular session can add a draft to Bhangale’s logged-in Gmail account, but cannot send it. It eventually returns highlights in the terminal and acknowledges that it cannot place a phone call. The wallet-equipped session can pay a provider to send the email and arrange the call. In this setup, buying a service turns a requested action into something the agent can complete; the comparison does not establish that every agent without a wallet lacks email or telephone tools. 12:23

The received email carries the research out of the terminal and into Bhangale’s inbox. After briefly opening an older message, he finds the new one and describes its stadium directions, maps, ticket information, and advice drawn from Reddit. One session has prepared material it cannot deliver; the other has delivered a trip brief through a purchased service.

The phone call takes longer. Bhangale notes that it can take a few minutes to arrive and returns to the slides while waiting. Payment confirmation and service delivery have separate clocks: authorizing a purchase quickly does not make the purchased service instantaneous.

A blockchain makes programmable transfers possible, but settling every tiny purchase separately creates another cost problem. Gas can consume a substantial fraction of a small payment. It also serves a purpose: charging for transactions discourages network spam and abuse. Removing that expense from each API purchase requires changing how payments reach the chain. 15:57

Shared block space creates a timing problem as well. Agent payments compete with other blockchain uses, so congestion can make latency unpredictable and degrade performance under load. Nanopayments, built on Circle’s Gateway, is introduced as a layer for sub-cent transactions, gas-free payment for the seller, and cross-chain operation. The aim is to keep each resource request from waiting on its own blockchain settlement.

Then the explanation is interrupted by the call. The synthetic phone agent begins briefing Bhangale on the World Cup trip and suggests nonstop flights from SFO to EWR or JFK. He asks how to reach the stadium from his hotel. The agent responds with NJ Transit to Secaucus Junction, followed by the Meadowlands rail spur to the stadium. These are demonstration outputs rather than verified travel guidance; their significance here is that the purchased calling service supports a follow-up conversation about the researched task. 17:24

Bhangale closes the call by saying he will read the rest in his email. The assignment has moved through research, paid data access, email delivery, and a spoken exchange. The wallet supplies the means to purchase missing services; those services perform the delivery and conversation.

The mechanism starts with funding. Circle works with providers that convert US dollars into USDC; the wallet’s funds can then be deposited into a smart contract. For an individual purchase, the agent signs an off-chain authorization naming the recipient address and the amount. That signature permits a particular payment without requiring the agent to submit a separate on-chain transaction at that moment. 18:33

The merchant’s server relays the authorization to Circle. Bhangale describes confirmation within a few hundred milliseconds: the merchant learns that the buyer has funds and can release the requested resource. What does the merchant wait for before supplying the data? The diagram follows the authorization through confirmation to delivery. Circle’s confirmation lets the resource request proceed without waiting for a separate blockchain transaction for that purchase.

Circle’s supplied technical deep dive fills in the later settlement step. Nanopayments checks the authorization against the available balance, deducts the off-chain amount, and confirms to the merchant. Thousands of signed authorizations are then batched, verified in a Trusted Execution Environment, and periodically settled on-chain. Gas remains at the batch level. Fast confirmation depends on Circle’s verification service and the TEE-based batching design, while the chain supplies eventual settlement.

The closing stack separates three jobs:

• Agent wallets: Hold funds and enforce the owner’s spending limits while the agent makes individual purchases.
• Merchant integration: Wrap endpoints and resources with payment handling using Circle’s SDKs, so sellers can charge for access.
• USDC and Nanopayments: Carry value and provide the sub-second payment path beneath those interactions, avoiding separate on-chain settlement for every tiny request.

For agent builders, Bhangale’s closing invitation is to visit agents.circle.com, equip an agent with a wallet, and try purchasing services such as phone calls. For merchants, the Nanopayments documentation explains the buyer and seller integration paths. Its signature requirement matters when choosing a wallet: Nanopayments and x402 batch settlement require externally owned account (EOA) signatures and do not support ERC-1271 smart-contract signature validation. 20:03