While it works
What Scout does with nobody watching: paying inside its limits without prompts, asking Anna about anything outside them, reaching its budget, and handling a service that fails or asks for too much.
Inside its limits, Scout pays and nobody is asked. Outside them, Scout's wallet refuses, and Anna is asked on her phone, wherever she is.
Paying inside the limits
While Scout works, its task view shows what it is reading and a short list of what it has bought, grouped by service: "Example Data, 38 requests, 190 sats" and "The Satoshi Vision, 4 articles, 80 sats". The status strip from setup stays at the top, updating at a pace a person can read.
No prompt appears for any of these. Anna agreed to a budget, not to each payment, which is the trade Charging per use describes. In return she gets the running total and the pause button, in the place she looks.
Do
Show each purchase in the task view beside the step of the task it served, so "4 articles" reads as part of the research rather than a separate bill.
Don't
Notify Anna's phone for payments inside the limits. She is not watching on purpose, and a buzz per article would teach her to silence Scout entirely.
A request outside the limits
Scout finds a market report from a service it is not allowed to pay, Example Reports, for 1,500 sats. That breaks two limits at once: a new payee, and more than 100 sats in one payment. Scout's wallet refuses, and the request goes to Anna as a push notification on the device she named at setup: "Scout wants to pay a new service: Example Reports, 1,500 sats."
Letting an agent spend asks for exactly this: a push, not a queue she has to go looking for. Meanwhile Scout carries on with the parts of the task it can do inside its limits. Its task view shows the request as waiting rather than failed, following the waiting-state advice in Permissions and allowances.
Opening the notification shows the approval screen. It leads with what is being asked: the service and its domain, the amount in sats with pounds beside it ("1,500 sats, about 75p"), and which limits it breaks. Scout's reason follows in a box labelled "Scout says", because it is Scout's account of itself and Anna should weigh it as one.
The two buttons are Approve once and Decline. Adding Example Reports to Scout's services for good is a separate change on the limits screen, not a third button here.
Do
Show the amount and the payee from the payment Scout's wallet refused, and Scout's explanation separately, labelled as Scout's. If the explanation names a different amount, show both and say they disagree.
Do
Name every limit the request breaks: "New service" and "Over 100 sats a payment". Anna is deciding whether the limits were wrong or the request is.
Don't
Put "Always allow" or "Add to Scout's services" on the approval screen. Widening Scout's scope from a notification is how one odd request becomes a standing permission.
Don't
Let the assistant approve its own request, or accept an approval from anywhere other than Anna's own device.
Reaching the budget
When Scout's wallet has nothing left, it refuses the next payment and Scout stops buying. Anna gets one notification, and the task view says what happened in the words the errors table suggests: "Scout has spent its 10,000 sats budget and has stopped buying."
Underneath, the screen shows what the budget bought, and two ways on: Top up from Bitcoin SV Wallet, which opens the same deliberate transfer as setup, and Finish with what I have, which asks Scout to write up the research from what it already paid for.
The daily limit works the same way on a smaller scale. When Scout reaches 3,000 sats in a day, it stops buying until the next day and says when it will resume. Anna can raise the day's limit herself. Scout can say the limit was reached; it cannot raise it.
Do
Show what the budget bought on the same screen that says it is spent. Anna decides whether to top up by judging the last budget, not by looking at a zero.
Do
Offer to finish the task with what Scout has already bought, as an equal choice beside topping up.
A service that fails or asks for too much
A service asks for more than its listed price. Example Data asks 50 sats for a request listed at 5. The amount is inside the 100 sats a payment limit, so the limit alone would let it through. Scout's wallet also compares each amount with the price Anna saw on the limits screen, refuses the payment, and tells her: "Example Data asked for 50 sats for a 5 sats request. Scout's wallet refused. Nothing was sent." This price check is a design choice we suggest for Scout, not something the payment standards do for you.
A service takes the payment and delivers nothing. Example Data accepts 5 sats and returns an error, three times in a row. Money did move. Scout stops using that service for the rest of the task, records the three payments as "paid, nothing received", and tells Anna once. Charging per use asks for that decision to be made once and reported once.
Do
Refuse a payment above the price shown on the limits screen, even when it is inside the per-payment limit, and send it to Anna like any other request outside scope.
Do
Say plainly when a service kept the money: "Example Data was paid 15 sats and sent nothing back." Whether money moved is the first thing the errors pattern asks every failure to answer.
Do
Cap paid retries to one service at a fixed number per task, show that number on the limits screen, and stop using the service when it is reached. Each retry is another payment, and a loop of small failures is how an agent spends its budget on nothing.
Open questions
- If Anna does not answer an approval request before Scout's end date, should the request lapse with the delegation, or stay open as prompt liveness suggests?
- How many failed requests to one service should Scout tolerate before it stops using it? Three is a guess.
- When a service took payment and sent nothing, what can Anna ask of it, and should Scout ask on her behalf?
- Does a "Scout says" label make people weigh the agent's reason more carefully, or do they read it as the product vouching for it?
Related
Written from: /guide/patterns/letting-an-agent-spend/, /guide/patterns/charging-per-use/, /guide/patterns/permissions-and-allowances/, /guide/patterns/errors-and-failed-payments/.
Checklist
The rules on this page, in a form you can work through.
11 rules