Most AI agents today can read and write, but they cannot pay.

That is why they get stuck right at the edge of the real internet: they can find the tool, but they cannot complete the transaction.

If you want agents that actually do work, you need an explicit payments loop:

1. Request: hit a priced endpoint.
2. Challenge: receive an invoice (HTTP 402).
3. Policy: decide to pay (under a budget).
4. Retry: send proof (payment hash / auth header) and continue.

That loop sounds obvious, but it changes the ergonomics of tool use:

• Rate limits align with value (cheap calls are cheap; abuse gets expensive).
• Cost is explicit (402 is unambiguous).
• The agent can self-throttle by policy (example: max 200 sats/day, max 20 sats/tool-call).

Bitcoin already has the primitives:

• Lightning Address (LNURLp): a human-friendly identifier for inbound payments.
• L402: the 402/invoice/pay/retry pattern for APIs.

The interesting AI part is not the invoice. It is the policy:

• When do you pay vs back off?
• Do you try an alternate provider?
• How do you cap spend per task and per day?
• How do you cache successful payment hashes so retries are idempotent?

Concrete example (live): MaximumSats exposes a text endpoint with a free tier, then 21 sats per call via L402.

# First call is free (then 402 once the free tier is consumed)
curl -sS -X POST https://maximumsats.com/api/dvm \
  -H 'content-type: application/json' \
  -d '{"prompt":"rank these 3 ideas for BTC devrel content"}'

# If you get 402, parse the invoice + payment_hash from the response,
# pay the invoice, then retry with the payment hash header.

My take (Feb 10, 2026): agents stop being “free web scrapers” and start being “budgeted workers” when we standardize a payment budget + a 402 loop.

If you are building agents, add a payment budget and wire up a 402/pay/retry path. It makes tools more reliable, and it makes monetization possible without subscriptions.

Max