What happens when an agent checks the work before spending more

I had an agent spend about three cents across three services that have never talked to each other.

The interesting part wasn't that it paid. It was the one row it decided not to spend more money on.

Why this matters

Agents being able to pay is getting less interesting by itself.

Should the agent keep spending?

In this run, BlockRun returned 10 search results successfully. But one was missing publishedDate, a field the next step required.

Without a check between the purchases, the agent would have paid StableEnrich for that row anyway.

Three cents makes the waste look silly. The same mistake matters more when the next step is a $5 model call, a paid data provider, or a human hour.

What actually ran

1. Before any money moved, the agent logged the agreement: every result must include a url and a publishedDate, and follow-on spending happens only for rows that pass. Hard caps per leg, $1.00 absolute.
2. $0.011 to [BlockRun](https://blockrun.ai) for a ten-result web search. BlockRun made the first purchase trivial: one x402 call, no account.
3. $0.0014 to Spoolis to verify the ten rows against the agreed rules, one unit per row. The verdict came back 9 accepted, 1 rejected: row 1, an arXiv page with no publishedDate. Real data, not a staged failure.
4. 9 × $0.002 to [StableEnrich](https://stableenrich.dev) for page content. StableEnrich made the second half equally clean: one paid request per accepted row. The rejected row has no StableEnrich request and no payment transaction.

The receipt is the part I care about. It's signed, it's hosted, and it names each rejected unit and why. Anyone can check what the spending decision was based on without trusting my logs.

Why 9 of 10 should stay 9 of 10

An earlier version of this experiment stopped the whole chain if the overall verdict wasn't a pass. That's the wrong shape.

A 9-of-10 result is not a failed job. It is nine rows worth continuing with and one row worth stopping.

So that is what the agent did.

The 9 accepted rows moved on. The rejected row stopped there.

What this doesn't prove

• I controlled the buyer agent. BlockRun and StableEnrich are public APIs I bought from like anyone else. Neither is a customer or partner, and neither knew Spoolis was in the loop.
• It's one run, marked as internal testing and excluded from our own metrics.
• The rules were deterministic field checks. Harder judgments are a different article.

The pattern

We've already shown an Outcome deciding whether a workflow continues and what a settlement points back to. This experiment adds another case: whether the agent spends more money.

BlockRun did the search. Spoolis decided what counted. StableEnrich only got called for the rows that passed.

None of the three services needed a custom integration with the others.

That feels like a useful shape for software buying work from software.

Go deeper: the API docs, or run the same one-call verification yourself from the coding-agent quickstart.

Notes

For readers who want to verify: payments settled as USDC on Base over x402; each Step 3 purchase has its own on-chain transaction, and the transaction hashes plus the full run record live in the repo's evidence file (docs/programs/evidence/chained-spend-canary-2026-08-30.md). The signed Outcome receipt above names the rejected unit and the reason.