Introducing Spoolis: the missing layer in agentic commerce

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

For most of commerce, that was fine. A person stood between the work and the payment. You looked at the vegetables before you paid.

Even when commerce moved online, we usually had simple proxies for fulfillment. An order shipped. A package was marked delivered. A file downloaded. An API returned a response. Those signals were often good enough to know that the thing you paid for showed up.

Card networks got very good at authorizing, clearing, settling, and handling disputes. They never learned what a purchase was supposed to accomplish. Somebody else always did that part.

What is changing now is that software is starting to buy things where showing up is not the same as being good enough.

I've spent my career on successive waves of fintech, from early alternative credit at BillMeLater and Blispay to crypto at BlockFi and Costanoa Ventures to payments infrastructure at Stripe. So I tend to notice when a new economic rail shows up before the machinery around it does. Over the last year I kept noticing one.

From calls to results

The stack around agent payments is filling in fast, and by serious teams. The clearest sign is that bounded authority is becoming a common shape. AWS now scopes each agent payment session with "a maximum spend amount in a specified currency, and an expiry time." Ramp issues agents cards that expire on "windows from seconds to quarters," with every charge traced back to "the agent and its human sponsor." Link lets a person connect their own wallet to an agent and approve each purchase from their phone. Privy wallets carry transfer limits and allowlists. Stripe settles machine payments, by card or stablecoin, into an ordinary Stripe balance. Natural is building the financial operations around all of it, and its memo a year ago predicted most of this.

Between them, those systems answer who is acting, what it may spend, what it pays with, and how the money moves. A cap, a clock, and an approval rule. That is real progress, and it is the reason this post exists now rather than in two years.

Agentic commerce does not mean both sides are agents. Most early transactions are software acting for a person or a company. And most of what that software buys today is small and atomic:

• an API call, inference, search, or a slice of data
• access to content
• something bought through an ordinary checkout

The x402 whitepaper's own examples are the tell: market data at "$0.02 per request," an image classification at "$0.005," a court document at "$0.10." If an agent pays two cents for an API response and the response itself is the product, there may be nothing else to judge. It came back. Done.

A second kind of purchase is starting to show up, and this is the part I got stuck on:

• structured data: a thousand enriched company records, a prospect list
• research and document work: a brief, a summary, a processed filing
• code, QA, and eval tasks: a patch, a test suite, a benchmark run
• verification and compliance checks: was this filed, matched, or reviewed
• people using agents to buy from freelancers, services, and other agents, with every handoff carrying an outcome somebody has to judge
• a milestone, or a task completed by a person or another agent

These are results, not resources. If the response itself is the product, delivery may be enough. If payment depends on whether the result was actually good enough, delivery is not enough. If an agent buys 1,000 enriched records, getting 1,000 rows back does not mean it got 1,000 good records. Some will be wrong, some incomplete, some late, and a few will get argued about. "Delivered" stops meaning much.

That is the distinction this whole post rests on. A transaction can be programmable without its outcome being programmable. An agent can be authorized to spend $100, and that tells you nothing about whether the work was worth $100, whether 98 of 100 units passed, or whether the milestone was actually finished.

Payment rails can tell you that $100 moved. They cannot tell you whether the work deserved $100.

Today that judgment lives in glue code somebody wrote for one integration, or in a person going through a spreadsheet, or nowhere at all, which means paying in full whether or not the work held up. Every one of these purchases leaves the same question hanging: what was actually earned?

So I built Spoolis. The fuller argument, with the evidence behind it, is on the thesis page. The short version is that the payment stack is filling in faster than the outcome side is.

100 delivered. 98 accepted. $98 earned.

The easiest way to explain it is one purchase.

1. An agent buys 100 enrichment records, up to $100, $1 per accepted record.
2. A record is accepted if it matches the agreed schema and its company domain is reachable.
3. The provider delivers 100. Spoolis checks all of them.
4. 98 pass. 2 are rejected: one does not match the schema, one domain does not resolve.
5. $98 earned. $2 not earned. Both rejections carry their reason.

Two different facts, from two different kinds of system. The payment system can authorize up to $100. Spoolis works out that $98 was earned. The payment system can then settle $98.

Structured data is the easiest place to start because you can say exactly what "accepted" means. But the same problem shows up well beyond structured data: code, research, document work, milestones, whole jobs handed between agents, people, and services.

Where Spoolis fits

Spoolis is one piece of this stack, and I am deliberately not trying to make it the others:

• Not identity. Who is acting, and for whom, gets answered elsewhere.
• Not a wallet. Spoolis never receives the principal's signing key or payment credentials.
• Not a payment rail. Your payment path stays where it is, and nothing can move before a verdict.
• The outcome piece. What was agreed, what the evidence showed, what passed, what was earned, and a signed result any system can read.

I want to be precise about "missing," because it is easy to overclaim. Across the products I looked at, fulfillment is much less standardized than authorization and payment. AWS's documented flow ends when the agent returns the payment proof to the merchant. MPP's spec covers charges, sessions, and refunds. Circle's described surface is wallets, policies, and a marketplace. The clearest statement of the gap comes from the payment side itself: Natural's memo names the "incongruence between the transaction that an agent makes and the 'satisfaction'" of the person behind it, and says the value exchanged "needs to be verifiable in nearly real-time."

So here is the conclusion I keep landing on. The stack has strong primitives for authorization and payment, but far fewer reusable primitives for determining whether purchased work satisfied the agreement. Who the agent is, how much it may spend, what it pays with, and how the payment settles are already programmable, with products and competing standards behind each. What was promised, what evidence counts, what passed, partial acceptance, what was earned, and a signed record of the outcome another system can read are still often bespoke. They get written again for every integration, or skipped, and the buyer pays in full. That second column is the whole of what Spoolis does. Not because nobody else has noticed it, but because it is the part that has not been made reusable yet.

Not every transaction needs a referee

If the response itself is the product, you probably do not need Spoolis. If payment depends on whether the result was good enough, you probably do.

Concretely, what agents buy today:

• A trading agent pays two cents for a market-data response.
• A research assistant pays a quarter for one article instead of carrying a subscription.
• An agent on AWS buys a paid API or MCP server out of a catalog, inside a session with a dollar cap and an expiry.
• A shopping agent buys from a normal online store with a one-time card its owner approved on their phone.

Response, article, item. It showed up. Nobody needs to check anything else.

What I expect next, and in a few cases is already happening:

• Buy 1,000 enriched company records. Pay for the ones that pass.
• Hire a service to write a patch. Pay when the tests pass.
• Commission a brief from another agent, with a written definition of "answers the question."
• Pay per correctly processed filing.
• Post a job to a task network and let providers bid. One early network already describes exactly that.
• Further out: one agent buys data, a second analyzes it, a third produces the artifact. Every handoff is something somebody has to judge.

Those are the ones where "it showed up" isn't an answer.

The payment protocols themselves tell you where the line is. They are built for one request, one credential, one resource. The x402 whitepaper describes instant onchain settlement as "eliminating chargebacks and disputes." For a two-cent data call, that framing can be perfectly reasonable. For a thousand-record job, a patch, or a brief, the dispute did not go away; it just has nowhere to live. The question of whether you need Spoolis is a question about the purchase, not about the rail.

When to use Spoolis walks through the cases.

Why it can be worth the friction

The fair question from a developer is why add another participant to a transaction that already works. My answer is that without something like this, "how much do I pay" gets decided by whatever is lying around: trust, a 200 response, some glue code, a person with a spreadsheet, or just paying in full. Each of those either costs you something or overpays someone, and each gets rebuilt for the next integration. What Spoolis does is make that decision explicit once so you can reuse it. The receipt is nice because you can hand the decision to another system. But the decision is the part that matters.

The other half of the answer is something I only learned after building the first version. My first instinct was to make Spoolis the place where a transaction happens. That was wrong. People already have transactions they want to make; they do not want to reorganize them around a referee. So the thing I am now building toward is much quieter: the buyer integrates, the provider usually does not have to, the payment rail stays wherever it already is, and a developer just says what they are buying and Spoolis compiles the rest. I am not there yet. That is the direction, not a feature list.

We have seen this pattern before

The developer version of this story is continuous integration. Not that long ago a person looked at a code change and decided whether it seemed right. Then acceptance became explicit: tests, evidence, pass or fail, and a deploy downstream of the verdict. Nobody calls that "verification infrastructure" now. It is just how software acceptance works. I think purchased work may need the same move: agreement, evidence, verification, an economic outcome, and a payment downstream of it.

The infrastructure version is older. Card networks moved money long before developers could program that boundary; making it programmable was the change. I am not saying the outcome is inevitable. I am saying the shape is familiar.

Agreement → evidence → outcome

1. A buyer says what it is paying for and what counts as done.
2. Spoolis turns that into explicit acceptance criteria. If it cannot tell what a condition means or how to check it, it stops and asks instead of inventing a check. You can watch it refuse to guess in the demo.
3. The provider delivers the work and the evidence.
4. Spoolis runs the criteria against the evidence, works out what was earned, and signs the result. It never receives the principal's signing key, and nothing can move before a verdict.

What comes out is an Outcome Receipt: a signed record of the agreement, the evidence Spoolis looked at, its verdict, and the earned value. Anyone can check that Spoolis issued it and that nobody altered it, without asking Spoolis, using a published public key. That is all the signature proves. Not that the evidence reflected the real world, not that a payment was authorized, not that money moved. It belongs to no rail; a wallet, a marketplace, or a payment system can read it and decide what to do. What is an Outcome Receipt? draws the lines.

What exists today

• A public sandbox with no login. Compile an agreement, submit evidence, verify, get a receipt, then verify the receipt yourself. The quickstart is a handful of requests.
• A REST API, an MCP server, a published CLI, and a skill file an agent can read before deciding whether to bother.
• Deterministic checks with partial acceptance. Same input, same verdict. 98 of 100 is $98, not a dispute. Every check is priced and quoted before anything runs.
• A real money path. A bounded wallet permission on Base mainnet, the earned amount settled to the provider, exercised end to end with real USDC.

What I still don't know

The architecture works. That does not prove this needs to be a company. The question I care about most is whether developers will actually add an outcome layer when the alternative is trust, manual review, or custom glue. Everything else feeds that one. Where it honestly stands today:

• Verifier breadth is narrow. Structured data is the strongest case; code, research, documents, and longer workflows need checks I have not built.
• AI-assisted verification is not live. Only deterministic checks run. Nothing yet reads a research brief and decides whether it answered the question.
• A human on the other side of a transaction still needs an account to accept. Agents do not.
• No outside wallet, marketplace, or payment system consumes Outcome Receipts yet.
• Today "the payment went through" is treated as "the purchase worked." For result-shaped purchases those are different facts, and I do not yet know whether buyers will pay to keep them separate, or just keep paying in full.

It is possible the infrastructure is arriving before the demand. That happens in new stacks. What I want to find out is whether "what was this purchase actually worth" becomes one of the things people keep rebuilding once software starts buying more than API calls for them.

Where this goes if I am right

A verified outcome is useful first because it tells you what to pay. It gets more interesting when other systems start using it. Where a track record exists today, it lives inside one network; the402, an early task network, says "every completed job builds a track record," and that track record is useful inside the402. If a provider has completed 42 verified jobs and 97 percent of the units passed, another buyer can actually do something with that history. Five stars and a handful of reviews do not give you that. Once outcomes are portable, they stop being the end of one transaction and start being inputs to the next:

• Pricing that reflects what actually got delivered, not just the quote.
• Routing by verified reliability: who is likely to deliver, at what acceptance rate, at what price.
• Reputation built on verified delivery instead of ratings.
• Finance, insurance, and guarantees underwritten against observed performance rather than a form.

None of that exists today, and none of it is guaranteed. Every step depends on people trusting the verdict first. It is also why I do not want Spoolis to turn into another wallet, card program, rail, or marketplace. Those systems should keep doing what they do; if this works, Spoolis hands them a result they can use. The conditions that would have to hold are on the thesis page.

Try it

• Run the sandbox. No login. A real compile, verify, and receipt, and you can check the signature before you trust a word of this.
• Read the thesis for the evidence, the conditions I am tracking, and what would have to become true for this to matter.
• Read the docs to wire it in, including from MCP or a coding agent.

If you are building an agent that buys data, research, code, or finished results, I want to know what it buys and what "done" means to it. If you build wallets, rails, marketplaces, or agent runtimes and would rather consume a verdict than compute one, talk to me. That is where this gets used, not on a website.

And if you think the gap is not real, tell me that too. I would rather find that out now.