Where agent spend should live
Approvals in the harness do not settle a dispute. The payment rail does. A note on limits, one-time cards, and who is on the hook.
Sample note, written to show the format. Any figures are illustrative. This is not a real company’s results.
An agent that can book a room can book the wrong room. The product question is not whether the model can be told to be careful. It is where the limit sits when the model is wrong, and who can undo the charge.
Most demos put the control in the harness. A system prompt says to ask before spending, a tool wrapper checks a flag, and a person clicks approve. That is enough for a prototype on one laptop. It does not survive a merchant, a scheme rule, or a disputed stay. The approval lives in a chat log. The payment lives somewhere else.
The rail is the better home for the limit. A card, a virtual account or a one-time credential can carry a ceiling, a merchant category, a currency and an expiry. If the agent steps outside that box, the authorisation fails before money moves. The model can still be fluent. It cannot be generous.
Two shapes
Two credential shapes keep showing up.
One-time cards. A fresh number for a single merchant and a single amount. Useful when the task is known: this hotel, tonight, under a ceiling you chose. Clumsy when the agent must pay a string of small bills.
Tokenized cards. A longer-lived credential, locked to a policy: a daily cap, a category list, a country list. The token can be paused without killing the agent, and the account stays put.
Neither shape replaces a dispute process. Someone is still the cardholder of record. In a personal setup that someone is you, or a company program that has agreed to stand behind the agent. “The model did it” is not a reason code a scheme will accept.
A workable split of duties is boring. The agent proposes a payment. A policy, not the model, decides whether the proposal fits. The issuer authorises or declines. The person sees an exception queue, not every coffee.
A policy that stays boring
The policy can be a small piece of data. The block below is an illustrative shape, not a production spec and not any issuer’s API.
{
"instrument": "one-time-card",
"maxAmount": "120.00",
"currency": "USD",
"merchantCategory": "travel",
"expiresMinutes": 30,
"onDecline": "queue-for-human"
}The amounts are round on purpose. A live program would set them from its own contracts, not from a sample file.
What to count
If this were a live program, the number to watch is not how often the agent asks permission. It is three other counts.
| Signal | What it suggests | Where it shows up |
|---|---|---|
| Declines you intended | The policy is doing its job | Authorisation logs |
| Disputes and refunds | The policy was too loose | Scheme reports |
| Time in the exception queue | People are still the control | The ops queue |
Those three tell you whether the limit is in the right place. A quiet decline rate with a noisy dispute line means the agent is spending and the rail is not stopping it.
The open question is product design, not model design. If agents are going to spend, the card program has to know they exist: separate credentials, separate limits, a story a scheme already understands, and a person who owns the outcome. Put that on the rail. Leave the harness for the conversation.