Agent with a budget

A worked example of software spending money for a person who is not watching. Scout is a research assistant. Anna Keller gives it a question, and it pays for what it needs to answer it: requests to Example Data at a few satoshis each, and articles from The Satoshi Vision.

Every other reference design in this guide has a person present when money moves. This one does not, which is the problem described in The hard parts. The design answers it as Letting an agent spend recommends: bound what Scout can do before it starts, and report what it did afterwards in a form Anna can judge.

Who it is for

Anna is closest to Ilse, privacy-minded: she is technically capable and reads what she agrees to. She wants the research done while she does something else. She fears coming back to find that Scout spent money on something she would never have bought, with no way to tell why.

Scout runs in her laptop's browser. Requests that need her answer reach her phone as notifications from Scout, on the device she named during setup.

The team building Scout is closer to Emma: they need a permission model they can explain to Anna in a few lines.

What it does

Scout has two parts, and the design depends on keeping them apart.

• The assistant reads, searches and decides what to buy next.
• Scout's wallet holds its own keys and its own money, and enforces the limits. The assistant asks it to pay; it pays or refuses. Neither the assistant nor an instruction it reads somewhere can change the limits.

Anna's main money stays in Bitcoin SV Wallet, her everyday wallet. Scout's wallet only ever holds what she chooses to send it. This is the agent wallet described in Wallet setups.

The flows

Four, in the order Anna meets them.

1. Setting it up. Why Scout gets its own wallet, choosing the four limits, funding it from Bitcoin SV Wallet, and one review of the whole delegation before anything starts.
2. While it works. Paying without prompts inside the limits, a request outside them that needs Anna, reaching the budget, and a service that fails or asks for too much.
3. Reviewing what it did. The activity trail by task and service, the daily summary, and what Anna does when something looks wrong.
4. Stopping it. Pausing now, revoking, sending what is left back to Bitcoin SV Wallet, and what Scout says about the task it was halfway through.

The patterns it applies

• Letting an agent spend, for its own wallet, the four bounds, approvals outside scope, review by purpose, and one stop control.
• Permissions and allowances, for plain-language grants, limits that expire, and an agent that can never widen its own permissions.
• Charging per use, for grouping hundreds of small payments, and deciding once what happens when some fail.
• Errors and failed payments, for saying whether money moved, and telling the owner rather than the agent.
• Wallet setups, for separate keys and funds, topped up by a person.
• Measuring a product, for budget used, approvals asked for, and stops pressed.

What it deliberately leaves out

• Automatic top-ups. Scout's wallet is refilled by Anna, each time, from Bitcoin SV Wallet. A standing refill turns a bounded loss into an unbounded one.
• Anna's identity and Passes. Scout pays as itself. It cannot sign in as Anna, show her Passes, or reveal how her keys are linked.
• Limits Scout can edit. Anna changes a limit on her own device. The assistant can ask; it cannot grant.
• One wallet for several agents. A second assistant gets a second wallet, so each one's spending can be read and stopped on its own.
• A refund process. If a service took money and delivered nothing, Scout records it and tells Anna. Getting the money back depends on the service, and the design does not pretend otherwise.
• Judging the research. Whether Scout's answer is any good is outside this guide. What it spent getting there is not.

How to use this

Related

• Letting an agent spend
• Wallet setups
• Spending, saving and delegating
• Daily spending wallet: what Bitcoin SV Wallet would be