Setting it up
Giving Scout its own wallet, choosing its four limits, funding it from Bitcoin SV Wallet, and the one review of the whole delegation before it starts.
Setting up is the only point where Anna decides anything in advance, so it carries most of the weight. There are four screens, then the status Scout shows once it starts: why Scout has a wallet of its own, the limits, the top-up from Bitcoin SV Wallet, and one review of everything before Scout starts.
The order matters. Anna sets the limits before she sends any money, so the amount she sends is the budget she just chose rather than a number she has to remember.
Scout's own wallet
The first screen explains the arrangement in three lines before asking for anything: Scout pays from a wallet of its own, Anna's money stays in Bitcoin SV Wallet, and Scout can only spend what she sends it.
This is the decision Letting an agent spend calls architectural. It is also a sentence Anna can repeat to somebody else, which is a fair test of whether she understood it. Scout's wallet has its own keys and its own identity, so it never holds Anna's identity key or her Passes. Wallet setups gives the reasons.
Do
Say on Scout's first screen, in one line, that the worst case is the amount Anna sends it. "Scout can't spend more than you give it" is the reassurance the whole design rests on.
Don't
Offer to connect Scout to Bitcoin SV Wallet with a spending permission as a quicker alternative. Two routes to the same task make the safer one look like the slow one.
The four limits
One screen has four rows, matching the four bounds in the pattern: how much in total, how fast (per payment and per day), who Scout may pay, and until when. Each row is prefilled for the task Anna has just described, so she edits rather than invents.
For a task like "compare home battery prices across Europe", the screen proposes 10,000 sats in total (about £5), no more than 100 sats a payment and 3,000 sats a day, two services, and an end date seven days away. The services row lists each one with its price, "Example Data, 5 sats a request" and "The Satoshi Vision, 20 sats an article", because Anna can only judge a budget against what things cost. Beneath the rows, one line states the retry cap: "Scout stops using a service after 3 failed paid requests."
Scout's wallet enforces all four. The assistant never receives them as instructions to follow; see Prompt injection is a payments problem now.
Do
Show the services row as named services with their prices, never as a field where Anna types an address or a domain.
Do
Translate the budget into what it buys for this task: "10,000 sats is about 2,000 data requests, or 500 articles." The number only means something beside its use.
Don't
Offer "no end date" as an option on this screen. A delegation with no end is the one nobody comes back to review.
Funding it from Bitcoin SV Wallet
Scout's Fund from Bitcoin SV Wallet button opens Bitcoin SV Wallet with a payment request for exactly the budget. Anna sees her own wallet's ordinary review screen: Scout's wallet as the recipient, 10,000 sats, about £5, and her confirm button. Scout never touches Bitcoin SV Wallet, and Bitcoin SV Wallet gives Scout no standing permission.
That makes funding a deliberate human action, as both Letting an agent spend and Wallet setups require. Every later top-up goes the same way.
Do
Request exactly the budget Anna set. If she changes the amount in Bitcoin SV Wallet, show the new figure as Scout's budget on the next screen rather than holding on to the old one.
Don't
Ask Anna to switch on a low-balance refill during funding. Topping up is a separate decision each time, made when she can see what the last budget bought.
Reviewing the whole delegation
Before Scout starts, one screen states everything Anna is agreeing to, in sentences rather than settings: the task, what Scout may spend and how fast, who it may pay, when it stops on its own, what will come to her for approval, and the device where approvals will arrive.
This is the consent screen for the whole job. The permission prompt guidance applies, with one addition specific to an agent: Anna will not be present for the payments this screen allows, so it also has to say what she will see later.
Do
List on the review what will come to Anna for approval: "a new service", "anything over 100 sats", "going over 3,000 sats in a day". The approvals are part of the deal, not a surprise later.
Do
Name on the review the one device where approvals will arrive, and accept approvals only there.
Do
Say when and where the daily summary will arrive, and let Anna change the time on this screen.
Do
Disable Start Scout until the top-up has arrived, and say so beside the button: "Waiting for 10,000 sats from Bitcoin SV Wallet".
Started
Once Scout starts, the four limits turn into a status strip: "0 of 10,000 sats, 0 payments today, 2 services, 7 days left". It sits wherever Scout's work is shown, with Pause Scout beside it, as Charging per use asks of any running total.
Don't
Move the status strip into a settings page once setup is done. Anna checks on Scout from where its work is, and that is where the total and the pause belong.
Open questions
- Is seven days the right default end for one research task, or should the end be the task finishing, whichever comes first?
- Do people set a total budget by thinking about the task, or about the money? The prefilled figure assumes the task.
- Does showing a price per service on the limits screen help Anna judge the budget, or make it look more expensive than a single figure would?
- Should a second task reuse the same wallet and limits, or start a new delegation each time?
Related
Written from: /guide/patterns/letting-an-agent-spend/, /guide/patterns/permissions-and-allowances/, /guide/how-it-works/wallet-setups/, /guide/getting-started/the-hard-parts/.
Checklist
The rules on this page, in a form you can work through.
12 rules