Start with a small, specific job.
Software might buy a search result, computing time or access to a service. An assistant comparing documents, for example, might need one paid retrieval. The human should decide the task and what spending is allowed before the assistant acts.
Giving software a way to pay is only one piece of the design. It also needs clear authority, trustworthy price information and a way to stop when the result is missing or inadequate.
Make each step accountable.
A safe design checks the destination, exact price, currency and requested service against a human-approved policy. Enforce the budget outside the model, in the system that authorizes payments. Instructions in a chat are not a spending limit by themselves.
The quote and approval should refer to the same purchase. If the destination or amount changes, stop and recheck. Track pending spending as well as completed payments so simultaneous requests cannot exceed the budget.
A budget is a boundary, not a suggestion.
- Human sets scopeDefine the job, total budget and approved destinations.
- Service quotesName the service, amount and destination.
- System approves + paysEnforce limits outside the model; stop on a mismatch.
- Service deliversRecord the payment status and return the requested work.
- Review the resultCheck delivery and usefulness; escalate uncertainty.
Payment and access can fit together.
L402 is one approach to paid API access. A server can return a payment challenge with a Lightning invoice and an access credential. The client pays and presents the required proof to request access.
That mechanism can connect payment to authorization. It does not guarantee that the response is accurate, that a service will remain available, or that an answer meets the user’s needs.
Keep a record. Check the delivery.
Record what was requested, the approved destination, the amount, payment status and the result. If a request times out, check its status before trying another payment. Repeated attempts should not quietly become repeated purchases.
Then inspect the work. Was the file delivered? Does the answer cite relevant material? Did the computing job complete? Escalate uncertain outcomes to a person instead of treating a receipt as evidence of quality.
Check your understanding
An assistant has a valid payment receipt. Does that prove its answer is correct?
No. The receipt supports a payment claim. Accuracy, delivery and usefulness require separate checks.
Sources & further reading
Reviewed 16 October 2026. Sources support the explanations; hypothetical examples and diagrams are labelled where they appear.
- Lightning Labs: L402
How Lightning payment challenges and access credentials can support paid APIs. The surrounding budget and review flow is an educational design proposed here.