Outcome Pricing for AI Agents

Building an AI agent that works for a customer is only part of the job. The contract that governs the engagement matters just as much. A well-designed engagement can still fail to capture the value it produces if the contract is structured wrongly. The technical work is not unimportant, but the way the vendor is paid decides whether the vendor keeps any of the value that work creates.

Outcome pricing prices the result the customer receives rather than the vendor's resources. This is the framing the source identifies as the right one for AI agents. The alternative is to price on what the vendor consumes while producing the work, such as tokens processed, compute hours used, or seats provisioned. Both approaches involve a price, but they put the vendor's revenue in different places. Under outcome pricing, the vendor's revenue depends on what the customer gets. Under consumption pricing, the vendor's revenue depends on how much of its own resources the work uses.

The diagram shows the difference in one picture. In the outcome column, the contract pays for the completed result, so the vendor's revenue rises when the customer's result rises. In the consumption column, the contract pays for the resources used, so the vendor's revenue tracks its own activity. The source describes the alignment between vendor revenue and customer outcome as the central purpose of a well-designed contract.

A contract sits above both sides of the engagement and sets how the vendor is paid. Value flows from the agent's work to the customer. The question is whether any of that value flows back to the vendor as revenue. When the contract connects revenue to the customer's outcome, the vendor's revenue moves with the gain. When the contract separates revenue from the outcome, the vendor can produce large value and still keep little of it.

A common first instinct is to price an AI agent by the value of the work it takes over. If an agent replaces a role that costs a company a large amount each year, it seems natural for the vendor to charge a meaningful share of that amount. The reasoning feels fair and seems to reflect the value delivered. The source identifies this belief as a misconception. The two numbers that get confused are the cost of running the agent and the value of the work it replaces.

The comparison makes the source's logic visible. Labor value is the large number a customer might be tempted to anchor on. Compute cost is the floor a vendor cannot go below for long. The competitive cap sits in the space the vendor can actually sustain, and that cap is set by what the market accepts, not by what the replaced labor costs.

The source is precise about the cap. The cap on what the vendor can charge is the cost the second-cheapest competitor would charge to do the same thing. The reasoning is that the cheapest competitor can always be undercut by a cheaper entrant, so the price that matters in practice is the one set by the next firm down the list. The source also warns that the competitive pressure is real. A vendor that does not build this pressure into its pricing will overprice itself out of the market.

In a cost center, every new deployment adds expense without adding durable return. In a flywheel, each successful result strengthens both the customer relationship and the vendor's ability to earn from it. The diagram below traces how each completed outcome feeds back through the cycle.

The source describes outcome pricing as the framing that turns the engagement into a flywheel rather than a cost center. The pricing question is therefore not only how much to charge, but whether the contract keeps revenue linked to the result so that each cycle makes the next one more valuable to both sides.