Introducing Spoolis: the missing layer in machine commerce

Payment rails move money but they don't tell you whether the work was actually completed, or how well.

Your bank can confirm that $100 left your account and landed in a vendor's. It has no idea whether the 1,000 records you paid for were accurate, whether the patch passed its tests, or whether the brief answered the question.

For most of commerce, that was fine.

A person supplied the missing judgment.

You looked at the vegetables before you paid.

Online, we got away with simpler proxies:

• an order shipped
• a package was marked delivered
• a file downloaded
• an API returned a 200

Those signals were often good enough because the main uncertainty was whether the thing showed up.

Card networks got very good at everything around that moment: authorization, clearing, settlement, refunds, chargebacks, disputes.

They didn't need to understand what the purchase was supposed to accomplish. Somebody else did that part.

I've spent my career around systems that make economic decisions: whether someone is creditworthy, whether a transaction should be approved, how money should move, and what happens when it goes wrong.

Along the way, that has included Bill Me Later, the BNPL pioneer acquired by PayPal; Blispay, acquired by ADS; work at the intersection of crypto and fintech at BlockFi and Costanoa Ventures; and, most recently, Stripe.

A lot of traditional commerce depends on trust, but it also depends on friction. Humans review things. Payments wait. Limits exist. And when something still goes wrong, we've built an enormous amount of machinery for the aftermath: refunds, chargebacks, disputes, reversals.

Agents can act faster, across more systems, with fewer humans inspecting each step. If we want that speed without simply accepting more risk, some of the judgment that used to happen during or after a transaction probably has to move earlier.

Agree on the terms. Say what counts. Check the evidence. Then let the economic result follow from what actually passed.

Agent payments are becoming programmable. The outcome still isn't.

A lot of the machinery around agent payments is arriving quickly.

• AWS now scopes each agent payment session with a maximum spend and an expiry time.
• Ramp has introduced agent cards with spend controls and expiration.
• Link lets people approve agent purchases using their own payment credentials.
• Privy has wallet policies and transfer controls.
• Stripe, x402, MPP, Tempo and others are attacking different parts of machine-initiated payment.¹

They're coming at the problem from different directions, but collectively they're making more of the stack reusable.

Most of these agents are not independent economic actors. A person or company is still the principal; the agent is software acting within authority that principal delegated.

The industry is getting better at answering:

1. May this agent spend?
2. What should it buy?
3. How does the money move?

One question is still much less standardized: what did the purchase actually produce?

That question doesn't matter equally for every purchase.

Most agent transactions today are still small and atomic:

• an API call
• an inference
• a search
• access to content
• a small slice of data

The x402 whitepaper gives examples like:

• $0.02 for market data
• $0.005 for image classification
• $0.10 for a synthetic voice audio clip²

For a two-cent API call, the response itself may be the product. It came back. Done.

But another kind of purchase has a different shape:

• 1,000 enriched company records
• a processed batch of documents
• a code patch
• a research brief
• a milestone
• work handed from one service, person, or agent to another

These are results, not just resources.

Getting 1,000 rows back doesn't mean you got 1,000 good records. A patch can arrive and still fail its tests. A research brief can be 20 pages long and still miss the question.

The useful dividing line may be simpler than human versus agent, fiat versus stablecoin, or card versus x402: is delivery itself the outcome, or does the result still have to be judged?

That's where Spoolis fits.

Acceptance infrastructure is the broader system around that decision: what counted, what failed, what was uncertain, and what was earned.

If only part of the work passes, only part should get paid.

Here's the whole idea in one transaction.

An agent buys 100 enrichment records at $1 per accepted record.

The agreement says a record counts if:

1. it matches the required schema
2. its company domain resolves

The provider returns 100.

Spoolis checks them.

• 98 pass
• 2 fail
  • 1 fails the schema
  • 1 has a domain that doesn't resolve

So the result is 100 delivered, 98 accepted, $98 earned.

The payment system and Spoolis are answering different questions:

• The payment system knows the buyer authorized up to $100.
• Spoolis determines that, under the agreed rules and submitted evidence, $98 was earned.
• The configured payment path can act on that result.

That's a small distinction in this example. It gets more important when the work is longer, more expensive, or handed across multiple agents and providers.

If a workflow has three paid steps, it should know which one failed before that failure becomes input to the next one.

Commerce has always needed a way to decide what counts as done.

This isn't a new problem. We've usually hidden the answer inside people, institutions, marketplaces, or vertical software.

• a merchant inspected goods
• a foreman signed off on work
• a marketplace wrote acceptance rules
• a card dispute process dealt with failures afterward

Software went through something similar.

Not that long ago, a person looked at a code change and decided whether it seemed safe to ship. Then continuous integration made more of that judgment explicit: run the tests, collect the evidence, produce pass or fail, and deploy downstream of the result. Nobody calls that "verification infrastructure" now. It's just how software acceptance works.

Purchased work may need a similar move:

agreement → evidence → verification → economic result → payment

Today, when a purchase needs judgment, "how much should I pay?" often gets answered by whatever is available: trust the provider, treat a successful response as success, write custom checks for one integration, have a person review the work, or pay in full and sort it out later.

That last option is why we've built so much useful machinery for refunds, chargebacks, disputes, reversals, support queues, and manual investigations. Those systems aren't going away.

But if software is going to transact more autonomously, we can probably resolve more of that uncertainty before payment depends on it.

The goal isn't to replace every dispute system. It's to avoid creating some of the disputes in the first place.

Card payments existed long before developers could easily build software around them. Companies like Stripe made payments far easier to program, and that changed what developers could build.³

I think economic outcomes could become another useful programmable input: not just "did money move?", but "what was actually earned?" For purchases that need judgment, that answer may become a natural step before payment settles.

Spoolis should fit into the transaction, not become the transaction.

My first instinct was to make Spoolis the place where a transaction happens.

That was wrong.

I was designing around the system I'd built instead of around the transactions people already wanted to make. The first version assumed both sides would come into Spoolis, agree there, complete the work there, and settle there. That adds too much friction and makes Spoolis own parts of the transaction that aren't the interesting part.

The better version is simpler: the buyer can add the outcome layer without forcing the provider to reorganize around Spoolis. The wallet stays a wallet, the payment rail stays a payment rail, and the marketplace stays a marketplace.

Spoolis handles:

• what was agreed
• what evidence came back
• what passed
• what was earned

There's a bigger reason I care about that separation.

If the answer only exists inside one wallet, marketplace, or payment provider, it's a feature of that system. If another system can consume the same result, it starts to look more like infrastructure.

Spoolis turns an agreement and evidence into an economic result.

1. A buyer says what it's paying for and what counts as done.
2. Spoolis turns that into explicit acceptance criteria.
3. Evidence comes back.
4. Spoolis evaluates it against the agreed criteria.
5. Spoolis determines the result.
6. The result is signed so another system can verify and use it.

There's one constraint I care about a lot: if Spoolis can't tell what a condition means or how to check it, it should stop and ask. It shouldn't quietly invent a check (watch Spoolis refuse to guess).

It would be easy to point a model at every result and ask, "Was this good?"

I don't think that's enough if money is going to depend on the answer. Another system should be able to understand why the verdict happened.

The signed artifact that carries that result is an Outcome Receipt. It includes:

• the agreement
• the evidence evaluated
• the verdict
• the earned value

verdict     PARTIAL
units       total 100 · accepted 98 · rejected 2
rejections  nulls.absent × 2
earned      98.00 of 100.00 USD
spool       spl_RDEQ7agQSjqDMKLZdW2uC
signature   Ed25519 · verifiable with the published key

Anyone can verify that Spoolis issued the receipt and that it hasn't been altered using the published public key.

The signature doesn't prove:

• that the submitted evidence perfectly represented the real world
• that a payment was authorized
• that settlement happened

Its job is narrower: make the outcome inspectable and portable.

The receipt is important, but the work upstream is what makes it valuable.

You can use the first version today.

Today Spoolis has:

1. 1
   A real compile-and-verify loop

   • describe what you're buying
   • compile acceptance criteria
   • submit evidence
   • run verification
   • get a signed result
2. 2
   Deterministic verification with partial acceptance

   • same evidence + same criteria → same result
   • a batch doesn't have to collapse into pass or fail
   • 98 of 100 can mean 98 of 100
3. 3
   Agent-native interfaces

   • REST
   • MCP
   • OpenAPI
   • CLI
   • machine-readable docs
   • a skill an agent can inspect before deciding whether to integrate
4. 4
   Payment integrations

   • verified outcomes can feed configured settlement paths
   • Spoolis doesn't have to become the payment rail
5. 5
   A real Outcome Receipt

   • generate one
   • verify the signature yourself
   • inspect why the verdict happened

If outcomes become portable, the next transaction can use the last one.

A verified outcome is useful first because it tells you what to pay. It gets more interesting when other systems start using it.

A portable outcome can become input to the next decision:

• pricing based on observed acceptance rates
• routing based on who actually delivers
• reputation based on verified fulfillment instead of ratings
• agent authority based on actual performance history

Over time, the same history could also matter for procurement, guarantees, insurance, or underwriting.

A provider that has completed 42 verified jobs with a 97% accepted-unit rate has something different from five stars and a handful of reviews.

None of that works unless people trust the underlying verdict.

A judgment trapped inside one wallet, marketplace, or payment provider can't do much outside that system. The result has to be precise enough that money can depend on it and portable enough that other systems can use it.

If this works, the compounding asset is the ability to express and verify what "done" means across more kinds of economic work, and to make that answer useful to more systems.

One of the biggest mistakes we could make in agentic commerce is teaching agents to transact exactly like humans do.

Humans built commerce around trust first, then layers of dispute machinery when transactions went wrong.

Agents give us a chance to invert that.

Software can already spend, buy, and move money.

What it still needs is a reliable way to know whether the work was actually done and what it earned.