What comes after usage-based software?

In 2024, I wrote about a question that had nothing to do with agents: what comes after usage-based software? My answer at the time was outcome-based business models: businesses charging not for access to software or units consumed, but for results achieved.

I kept the idea in the back of my head. Two years later, AI agents have made the question more interesting. Not because every company is suddenly going to charge for outcomes. Because software is beginning to become the buyer too.

Once one piece of software can hire another piece of software to do work, "usage" is not always the thing the buyer cares about. The buyer cares whether the work actually worked. And that creates a different infrastructure problem.

Business models follow what technology makes possible

Software monetization has expanded as technology made new things measurable enough to price.

License: pay for the right to use. Subscription: pay for continued access. Usage: pay for consumption. Outcome: pay for an agreed result.

These models coexist. The interesting progression is not replacement, but measurement. Each new model became practical when technology made another unit of value observable enough to price.

Cloud made metering easier. APIs made consumption programmatic. Better data made usage observable almost in real time, which is why so much developer infrastructure now bills by the token, call, or gigabyte.

AI and agents may push the frontier one step further. If richer kinds of work become programmable, the work's result may become observable enough to price too. That is the opening for outcome-based models. Not a certainty. An opening.

Why outcome pricing is attractive

For the seller, outcome pricing is a way to capture more of the value a product creates when it works, and a way to differentiate beyond commodity unit pricing. If everyone charges a fraction of a cent per record, the vendor confident in quality would rather charge for records that meet the bar.

For the buyer, it means paying closer to realized value. Less risk of paying for activity that produced nothing.

The difference is concrete:

• $0.01 per enriched record returned, versus $X per record that satisfies agreed criteria.
• Paying for a research agent's tokens, versus paying for research that satisfies the specified deliverable.
• Paying per automation run, versus paying per successfully completed workflow.

I am not claiming outcome pricing is always preferable. It often is not. The more subjective the outcome, the harder the model gets. That difficulty is the point of this essay.

Three things have to exist. Then a fourth.

In 2024, I argued an outcome-based model needs a few components working in concert: contracts, multiparty payments, and constant connectivity and data. The 2026 version of that list, sharpened by two more years of watching agents transact, looks like this:

1. An explicit agreement. A machine-readable definition of what counts. Not a PDF. Something software can evaluate against.
2. Evidence. Something capable of showing what actually happened: the records delivered, the checks run, the logs produced.
3. Action. The ability to pay, partially pay, release, retry, remediate, or escalate based on what happened.

In 2024 I had agreements, payments, and data in the framework. What I had not fully isolated was the decision in the middle.

4. Outcome judgment. Something has to decide whether the evidence satisfies the agreement, which units passed, and what happens next. Agreements, evidence, and payment rails do not do this on their own. The judgment is its own piece of infrastructure, and it is the piece I now think matters most.

Agents make this more important

A human buyer can eyeball a deliverable. An agent needs a computable answer.

That difference gets sharper as agents take on more economic responsibility. Delegated jobs get larger. Agents hire other agents, so a bad result becomes paid input to the next step in a chain. Dynamic routing means novel counterparties instead of long relationships. And downstream actions increasingly happen without a human reviewing anything in between.

The useful question for any given transaction is this: is delivery itself the outcome, or does the result still have to be judged?

If delivery itself proves success, no special outcome layer is needed. A successful API response may be enough. A lot of machine commerce today looks like this, and it should stay simple.

If the result still has to be judged, the missing infrastructure becomes visible. Someone or something has to hold the definition of done, look at the evidence, and decide what counted.

Not just a pricing question

Here is the part I got wrong in 2024, or at least underweighted. Outcome judgment is useful even if pricing never literally becomes outcome-based.

A verified result can tell software to release a fixed payment. Or calculate a partial one. Or continue a workflow, retry a step, remediate, switch providers, escalate to a human. The price attached to the transaction can be flat, usage-based, milestone-based, or anything else. The judgment underneath is the same.

Outcome-based pricing is only one expression of a broader shift toward software that can act on verified outcomes.

Why this may take time

Outcomes can be subjective. Attribution gets messy when several parties contribute. Evidence is incomplete. Downstream value may not show up for months. And many buyers will prefer simpler pricing simply because it is easier to understand and harder to argue about.

Platforms may also decide the judgment is core and keep it internal.

So I do not think outcome-based pricing is inevitable. Better infrastructure simply makes it practical in more places than before.

The question underneath the pricing

I originally thought about outcome-based business models as an evolution in how software gets priced.

I now think the more interesting question sits underneath the price.

If software is going to pay for work, someone has to define what counts, observe what happened, and decide what was actually earned.

That is true whether the final payment is fixed, usage-based, milestone-based, or outcome-based.

Agents make that missing decision easier to see.

That is the part I am building Spoolis around.