Before an agent spends: five checks for a paid workflow

Autonomous commerce begins with an ordinary question: can software buy something useful on a person’s behalf, within the permission that person gave it?

Consider a simple example. A researcher needs a fresh data lookup. Their agent finds an API that charges for the result. The job looks small, but several decisions sit between finding the endpoint and delivering an answer. What is the price? Is this a permitted purchase? What happens if the request fails? How will the person know what was bought?

A practical design should make those decisions visible. Here are five checks we would use when evaluating a paid agent workflow.

1. Define the job before the purchase

Write down what a usable result means. For a data lookup, that might include the fields required, an acceptable age, and the source. For document conversion, it might include a file format and a check that no pages disappeared.

This gives the agent a reason to reject a service that is cheap but unsuitable. It also helps the person distinguish a completed job from an attractive-looking response. A product can make this easier with examples: show the kind of result it will accept before giving it authority to buy.

2. Put spending limits at the authorization point

A task should have a budget. It should also have a permitted destination or category, an expiry time, and a rule for asking the person when the situation changes. Consider the total cost of a job, including fees and retries, rather than only the price of its first request.

Lightning Labs’ agent tooling describes scoped credentials and a remote signer, alongside a client for paid API access. Those are useful building blocks. Their presence alone does not establish that an application enforces every spending rule correctly. Test the actual enforcement point. Lightning Labs, February 11, 2026

Ask concrete questions during testing. Does the next request fail safely after the budget is used? Can a retry trigger another charge? Can someone stop future spending while a job is running? A convincing answer includes observed behavior.

3. Keep the payment exchange understandable

L402 offers one approach to paid digital access using Lightning. A service returns a payment challenge; the client pays and presents a credential with payment proof to access the resource. The credential’s scope and lifetime matter because a service may permit reuse. Lightning Labs, March 11, 2026

For the person using the product, the interface can stay plain: service, purpose, amount and outcome. A developer may need protocol details, while a buyer mainly needs to understand what their agent did. Both views should refer to the same transaction.

4. Check what arrived

A successful payment does not evaluate the usefulness of a response. The application needs a separate delivery check.

For the hypothetical data job, check whether the response has the expected fields and is fresh enough. Record whether the check passed. If it failed, follow a defined recovery policy rather than buying repeatedly without a limit. Set expectations about refunds before payment; do not promise that a protocol automatically resolves a commercial dispute.

Some jobs need a person to judge the result. That can be an appropriate part of a reliable workflow. The important point is to decide who makes the judgment and what happens next.

5. Leave a record the person can use

Keep the original permission, the purchase and the result connected. Google’s AP2 tutorial provides a useful reference for thinking about authorization mandates and receipts. It addresses a different part of the system from a settlement rail. Combining protocols still requires implementation and testing. Google Developers, March 18, 2026

A useful record should answer: what was requested, what was allowed, what was spent, what arrived and what remains unresolved? It should avoid exposing credentials or unnecessary private information.

Loop XXI’s direction is infrastructure for autonomous commerce built on Bitcoin and Lightning, for humans and agents. These five checks describe a design standard and a way to evaluate progress. They are not a claim that Loop XXI currently offers a live, fully integrated purchasing service.

The next meaningful milestone for any team building this kind of product is a reproducible job with clear evidence across permission, payment and delivery. Start small enough that every step can be inspected.