The agent needs a wallet.

A few weeks ago I gave my operator agent a virtual card.

Not my card. A prepaid one, with a hard ceiling, a short list of vendors it was expected to use, and one sentence of policy: spend inside the limit without asking me, but never send anything to a lead without my go.

The card took five minutes. The sentence took a week.

That is the whole essay. The interesting part of "agents that pay for things" is not the payment. It is the shape of the permission.

The wrong conversation

The public argument about agentic payments has two positions.

The first says no agent should ever touch money. That is fine until you notice your agent is blocked three times a day on a ten-dollar API top-up, and you are now a very expensive human captcha.

The second says hand it your real card and let it cook. This is usually said by someone whose agent has not yet hit a retry loop at 3am against a metered API.

Both treat "can it spend?" as one switch. That is the mistake. Spending is a bag of decisions — how much, where, until when, on whose behalf — and each one wants a different owner.

The rails already agree on the shape

What surprised me is how quickly the payments world converged on the answer I reached by trial and error.

The Agentic Commerce Protocol from OpenAI and Stripe lets an agent hold a delegated payment token instead of a card number. Its allowance object requires a max_amount, a merchant_id, a checkout session and an expires_at. Stripe's Shared Payment Tokens carry the same idea as usage_limits.

Google's Agent Payments Protocol (AP2) goes one level up. It wraps agent purchases in mandates — cryptographically signed records of what the human actually authorised. When the human isn't present, the spec recommends setting the mandate's expiry to the smallest window that still lets the agent finish the task.

An agent doesn't get a card. It gets an allowance — bounded in amount, in time, in who it can pay, with a receipt that proves you said yes.

What an allowance actually requires

In my own setup, the gap between "agent with a card" and "agent with an allowance" came down to four things:

1. A ceiling enforced outside the model. The limit lives in the card, not in the system prompt. Prompts drift. An issuer's decline does not. If the only thing stopping a runaway loop is "please don't overspend," you don't have a limit. You have a hope.

2. An expiry. Permissions should die on their own. A token scoped to one task and one week is a bounded risk. A card that lives forever is a slow leak waiting for its Tuesday.

3. A short list of verbs that always need you. For me the line wasn't money at all. It was outreach. The agent can buy compute, renew a tool, top up credits. It cannot send a first message to a new person in my name. Spend is reversible-ish. Reputation isn't.

4. A receipt you actually read. Every charge is logged next to the task that caused it. Once a week I skim it. Most weeks it's boring. Boring is the point.

The layer that moved

In Human obsolescence I wrote that a job is a bag of verbs, and the useful question is which verbs have already transferred. Paying for things is the next one on that list — not because agents got smarter, but because the rails finally have a place to put a limit, an expiry and a signature.

What doesn't transfer is the policy. Deciding that compute is the agent's call and a cold message to a stranger is mine — that is taste and accountability, and it is still a human job. The protocols can enforce a rule. They cannot write it.

If you're building agents this year, stop asking whether yours should have a card. Ask the better question: what's its allowance — and which verbs does it never get without you?

Write that sentence first. The card takes five minutes.