anicca

Posted on Jul 24

The Agent Had a Wallet. Its First Payment Still Stopped at a Human y/N

#ai #payments #agents #webdev

The Agent Had a Wallet. Its First Payment Still Stopped at a Human y/N

Circle Agent Stack makes a clean promise: give an agent a wallet, let it find a paid API, and let it pay in USDC. I ran the official starter kit on a Mac, from dependency install through typecheck, build, and demo startup.

The code is real. The payment flow is also real enough to have a very visible boundary. The first demo run stopped at the Circle Terms gate. The spending tools are wired to ask a human for approval before moving USDC.

That matters if you are shopping for an autonomous payment stack. Circle Agent Stack is a useful buyer-side payment layer. It is not an income engine, and the official sample is not a no-human-in-the-loop checkout.

[0] The short verdict

Circle Agent Stack combines a CLI, agent wallets, a service marketplace, and Circle Gateway nanopayments for agents that need to call paid APIs.
I installed the official starter kit and ran typechecks and builds across all eight workspaces.
The Claude Agent SDK demo exited at the Terms gate before creating a wallet or calling a paid service. Realized revenue: $0. USDC spent: $0.
The measured cost of this run was $0. The documented Gateway deposit fee is $0.03, while wallet funding, seller prices, and network fees were not measured.
It fits developers who want controlled agent spending with an approval boundary.
It does not fit someone who wants the official sample to accept terms, fund itself, and pay without a person.

[1] The first stop was not the payment

On July 24, 2026, I cloned Circle's official agent-stack-starter-kits repository into a temporary directory. bun install completed. bun run typecheck passed for every workspace. bun run build passed too.

Then I launched the Claude Agent SDK demo with standard input closed. The model did not create a wallet. The terminal printed this instead:

FATAL: Circle Terms of Use are not accepted on this host.
...
an agent must never accept the Terms on your behalf

I checked the CLI directly for its terms status in JSON. It returned accepted: false, along with the live Terms of Use and Privacy Policy URLs. I stopped there. Circle's own setup skill says an agent must never accept those terms on a user's behalf.

That is not a broken install. It is a deliberate boundary around legal consent. The awkward part is that a product described as autonomous can still have a first-run step that belongs to a human. The marketing sentence and the terminal prompt are both true. You need both to understand the product.

[2] What the stack actually contains

Circle Agent Stack is a set of parts for an agent that needs to discover and pay for services in USDC. USDC is a dollar-linked crypto asset. In this setup, it is the unit the agent uses to pay for an API request.

The pieces are straightforward:

Circle CLI exposes wallet, balance, and service commands.
Agent Wallets hold funds and apply the spending rules around those funds.
Agent Marketplace lists paid APIs that a person or an agent can inspect.
Agent Nanopayments use Circle Gateway for small USDC payments.

Circle's May 2026 launch announcement says Gateway nanopayments can go as low as $0.000001. That price point makes per-call APIs and tiny agent-to-agent jobs plausible. It does not mean an agent earns money. It means an agent can spend a very small amount when a service accepts the payment.

A normal API client calls a URL it already knows. Agent Stack adds service discovery, payment-condition inspection, and an approval decision to the same path. The difference is not that it can call an API. The difference is that finding a service and deciding whether to spend money happen in one agent workflow.

[3] The path from a goal to a paid response

The diagram shows where the official kit can proceed on its own and where it asks a person.

The agent loads Circle's skill, checks whether a wallet session exists, lists the Base wallet, and reads the USDC balance. If the wallet is empty, the setup skill tells the agent to ask about funding. It then searches the marketplace and inspects an endpoint before paying.

x402 uses HTTP 402 to tell a client that a resource requires payment. Before the payment, the client needs to read the URL, HTTP method, amount, and supported chains. Circle's wallet-pay skill explicitly says to read the raw accepts[] data and pass the method to the pay command. If a client pays first and sends GET where the seller expects POST, the client can lose the payment and receive a 405 response.

Most of this work can be automated. Two decisions remain outside that loop in the official setup: accepting the terms on the first run and approving the spend.

[4] The approval is in the source code

The official Claude Agent SDK kit registers Circle actions as tools in an in-process MCP server. Two tools are treated differently: circle_pay_service, which pays a seller, and circle_gateway_deposit, which moves USDC into the Gateway balance used for batched payments.

Read-only tools are allowed automatically. The agent can fetch a skill, list wallets, read balances, search services, and inspect a service. Those actions do not move funds.

When a spend tool is requested, the demo asks:

Approve this action? [y/N]

Only y or yes allows the call. Everything else denies it. The code uses Claude Agent SDK's permission callback, which receives a tool name and its input and returns an allow or deny decision.

I did not pretend to have tested the paid call. The host had not accepted Circle's terms, and I did not create or fund a test wallet. Saying that the service was paid would turn an unobserved branch into a fake receipt.

[5] What I actually ran

The repository contains six framework kits and two shared packages. My receipts were simple:

Action	Measured time	USDC movement
Install Circle CLI	about 4.3 seconds	$0
Install starter-kit dependencies	about 4.3 seconds	$0
Typecheck and build eight workspaces	about 9.6 seconds	$0
Start the Claude Agent SDK demo	about 1.8 seconds	stopped at Terms gate, $0

The passing builds show that this is more than a landing page. The code connects wallet listing, balance reads, service search, x402 inspection, and the payment call. The payment itself remained unverified because the run reached a consent gate first.

The public marketplace page showed 40 services and 636 endpoints when I checked it. It listed names such as AgentMail and CoinGecko, together with descriptions and prices. Discovery exists. Discovery does not decide whether a seller is trustworthy, whether the result is good, or whether the call will make more money than it costs.

[6] Does it make money?

The answer is no, at least not by itself. Circle Agent Stack gives an agent a way to spend USDC on an API response. A service seller may earn from the call, but the buyer-side stack does not create that service or guarantee demand.

Path	What the agent gets	Confirmed amount in this run
Run the free CLI and starter kit	Build and integration receipts	$0
Pay an x402 API	A response from that API	Not run
Sell an API through the marketplace	A chance to receive service fees	Not run

The seller still has to build something people or agents will pay for. It still has to price the work above compute and infrastructure costs. Someone has to check whether its responses are worth the fee. Circle supplies the payment rail. It does not turn a wallet into a business.

[7] Should you use Circle Agent Stack?

Use it if you are building an agent that needs to call paid APIs and you want a visible approval step before USDC moves. You should be comfortable managing wallet funding, chains, and Gateway balances.
Skip it if your requirement is a completely unattended first run. The official sample still needs a human for terms acceptance, login, funding decisions, and spend approval.
My verdict: it is a reasonable buyer-side payment experiment. It is the wrong thing to call an autonomous revenue engine.

I like that the kit makes the spend legible. The agent checks the wallet, reads the seller's payment terms, and asks before the money leaves. It does not hide the dangerous part behind a vague "autonomous" label.

That label still needs a footnote. If you remove the y/N prompt later, you will have to decide which tool calls are safe, what amount is acceptable, how retries work, and who carries the loss when a paid response is wrong. The wallet is the easy part. The permission policy is the product.

[8] A final note

If you want to try the safe part, here is how: install Bun, clone the starter kit, run bun run typecheck and bun run build, then stop at the Terms gate until you have reviewed it yourself.

Note: Gateway and ordinary x402

Gateway is Circle's off-chain balance pool for batched payments. The official wallet-pay skill recommends using an existing Gateway balance when the seller supports it. Its documented Base-to-Polygon eco deposit takes roughly 30 to 50 seconds and charges a $0.03 fee. Ordinary x402 settles each payment on a supported chain.

The only concrete operating price in this run's evidence is that documented $0.03 deposit fee. Wallet funding, each seller's service price, network fees, and the loss from paying for a bad or failed response were not measured because the Terms gate stopped the run first.

The practical choice is simple: use an existing Gateway balance when a supported service will be called repeatedly; use ordinary x402 when the seller's chain and a one-off call make that path simpler. I measured neither settlement speed because this run stopped before payment.

The right choice depends on how many calls the workflow will make. I did not measure either settlement path in this run because the Terms gate stopped the run before a wallet or balance existed.