Authorization is not earned value

On August 27, I ran a tiny transaction that I kept coming back to after it finished.

Not because of the amount. It moved 97 cents.

I wanted to test something much more basic: could one system decide how much an agent was allowed to spend, while another independently decided how much the work actually earned?

The agent had a $1.00 spending cap. It bought a batch of work: 100 records at one cent per accepted record. The work came back, Spoolis checked the agreed conditions, and the payment description carried the Spoolis receipt reference with it.

That was the part I cared about. The wallet never had to understand the work. Spoolis never had to control the wallet. They only had to agree on one number: what was earned.

The whole transaction was four steps

1. Authorize up to $1.00.
2. Verify 100 units of work.
3. Count 97 accepted and 3 rejected.
4. Pay exactly $0.97.

This split is becoming more relevant because the surrounding agent-payment stack is getting real. Wallets and spend limits, cards, machine-payment protocols, and agent-native financial products are increasingly good at answering who may spend and how money moves.

What they generally do not answer is whether a piece of purchased work actually satisfied the agreement. That is the part I wanted to isolate in this experiment.

Two questions that usually get collapsed into one

Neither system had to become the other. They only had to coordinate around the Outcome.

This is the same separation I wrote about in Introducing Spoolis: authority, selection, Outcome, and settlement are different jobs. The Natural run was a small real-money test of just two of those layers staying separate.

Real transaction · Aug 27, 2026

What the three failed units did

Nothing dramatic.

• one record was missing the required source
• one was missing a required field
• one was stale

That is actually why I like the example.

Without an explicit Outcome, software often has to pretend the answer is binary:

• 100 delivered = done

But the real answer can be:

• 97 counted
• 3 did not
• here is why
• $0.97 earned

That is a much more useful thing for another system to act on.

• a retry loop can retry the 3 failures
• a billing system can count 97
• a wallet can pay $0.97
• a human can inspect the reasons

Same Outcome. Different next steps.

Why I think this gets more interesting

1. The work can be partial. Software does not have to pretend 100 delivered means 100 accepted.
2. The next system can act immediately. A runtime can retry failures, a billing system can count accepted units, and a wallet can pay the earned amount.
3. The payment layer does not need to understand the work. It only needs the economic result.
4. The result can travel. The payment can carry a reference to the signed Outcome Receipt.

That still doesn't prove anyone needs Spoolis. It does make the seam concrete.

What this is not

• Not escrow. Spoolis did not hold the money.
• Not dispute resolution. There was no disagreement to resolve.
• Not a Natural partnership announcement. We used Natural's public API the same way another developer could.
• Not proof of demand. It was a 97-cent reference transaction.

I wanted to see whether two independent systems could coordinate around the same economic result with real money.

They could.

The generic pattern

1. Authorize the ceiling.
2. Do the work.
3. Determine what counted.
4. Pay what was earned.

That becomes more interesting as software starts buying work, not just resources.

If an agent buys an API call, delivery often proves enough.

If it buys a result that can be partial, wrong, stale, or incomplete, someone still has to answer:

What actually counted?

That is the seam I am interested in.

The part I keep thinking about

The 97 cents is not the point.

The point is that the payment system did not need to know why three units failed, and the verification system did not need custody of the money.

That separation feels important to me.

If agent commerce grows into software buying more complicated work from other software, I suspect more transactions will need some version of this split:

permission to spend on one side, explicit Outcome on the other.

I don't know yet which workflows will care enough to make this infrastructure. That's what I'm trying to learn.

Try the same walk

The verification half runs against the free Spoolis sandbox with no account required.

The example uses the same shape:

• 100 units submitted
• 97 accepted
• 3 rejected with reasons
• $0.97 earned on a $1.00 cap

The payment half can be wired to whatever payment system owns your agent's spend.

The important part is not reproducing Natural specifically. It is reproducing the separation:

one system authorizes the spend; another determines what was earned.

Notes

1. Natural developer documentation (agents, agent keys, spend limits, payments). The run used the public API with an agent key; spend limits are owner-controlled.
2. Natural, "The agentic payments memo", for the broader agent-wallet and spend-limit context.