Reviewing what it did
How Anna finds out what Scout spent while she was away: the daily summary, the activity trail by task and service, the record behind each purchase, and what to do when something looks wrong.
Anna arrives after the money has moved. The review has to let her judge spending she did not decide, in the few minutes she will give it. So it starts small, with a daily summary, and opens into detail only where she asks or where something is unusual.
The daily summary
Once a day, at the time Anna chose during setup, Scout sends one summary. It opens with anything unusual, then the day's total against the budget, then one line per task.
"Today Scout spent 1,240 sats, about 62p, on one task: home battery prices. 212 data requests, 9 articles. 8,760 sats left, 5 days to go." If nothing unusual happened, the summary says that in one line rather than leaving a gap where a warning would be.
This is the human schedule Letting an agent spend asks for: one summary Anna reads rather than a feed she ignores.
Do
Put refused payments, approvals Anna gave, and any service that kept money without delivering at the top of the daily summary, above the total.
Do
Say "Nothing unusual today" when that is true. A summary that only ever lists problems leaves Anna unsure whether a quiet one means no problems or a missing section.
Don't
Send a summary on a day Scout spent nothing and nothing changed. A daily message with no news is the fastest way to have the useful ones ignored.
The activity trail
The full trail lives in Scout, under Activity. It is grouped first by task, then by service inside each task. "Home battery prices, 3,880 sats" opens into "Example Reports, 1 report, 1,500 sats, approved by you", "Example Data, 312 requests, 1,560 sats" and "The Satoshi Vision, 41 articles, 820 sats". Each of those opens into the individual payments.
Grouping by purpose is the review a person needs, and grouping by service inside it is the Charging per use pattern for hundreds of small payments. Anna's own Bitcoin SV Wallet only ever shows the top-ups she sent to Scout's wallet. The detail belongs here, where the tasks are.
Do
Mark every payment in the trail with the task it served. A payment that belongs to no task is itself something to flag.
Do
Show refused payments in the trail beside the ones that went through, marked "Refused, nothing sent". What Scout tried to buy is part of what it did.
One purchase, opened
Opening one payment answers the questions from The hard parts: what it bought and why. The record shows the service and its domain, what was bought ("Article: Battery storage prices, March"), the amount in sats with pounds beside it, the task, the time, and the reason Scout gave when it paid, labelled "Scout's note at the time".
That note is written when the payment is made, and nobody, Scout included, can edit it afterwards. The pattern is clear that intent cannot be reconstructed later. It is less clear whether the note can be trusted at all, since an injected instruction could shape it too. The screen therefore labels it as Scout's account, not a fact.
Do
Record Scout's reason with each payment at the moment it is made, and keep it unchangeable. A reason written afterwards is a story, not a record.
Don't
Present Scout's note in the same style as the amount and payee. The amount and payee come from the payment; the note comes from the agent, and the screen should show the difference.
Spotting something wrong
The trail sorts the unusual to the top of each task: a service paid for the first time, a payment much larger than Scout's usual for that service, a burst of payments close together, or a service that kept money without delivering. Each carries a short reason it was flagged, such as "Many payments close together".
When Anna thinks something is wrong, the payment offers three actions, in order of urgency: Pause Scout, Remove this service and Report to the service. None of them promises the money back. A payment is final, and whether a service refunds is up to the service.
Do
Put Pause Scout on any payment Anna has flagged, so she can stop it from the place she noticed the problem.
Don't
Offer "Get a refund" or "Dispute" on an agent payment. Scout cannot reverse a payment, and a button that implies it can will be pressed and will fail.
What the team learns from this
The same trail feeds the measures in Measuring a product: how much of each budget was used, how often Scout asked for approval, and how often Anna paused it. A budget that ends half spent, or a request for approval on most tasks, says the setup defaults need changing, not Anna.
Open questions
- Does a daily summary get read past the first week, or does it need to become weekly once the person trusts the agent?
- What counts as "larger than usual" for an agent that has only made a few dozen payments?
- If Scout's note is shaped by something it read, how would Anna ever know? The design labels it, and labelling may not be enough.
- Should Bitcoin SV Wallet show anything of what Scout spent, or only the top-ups, which is what this design chooses?
Related
Written from: /guide/patterns/letting-an-agent-spend/, /guide/patterns/charging-per-use/, /guide/patterns/errors-and-failed-payments/, /guide/product/measuring-a-product/.
Checklist
The rules on this page, in a form you can work through.
9 rules