Charge what it's worth.
Dynamic pricing for agentic products.
The price of every request follows the value it creates for your user, decided before the run.
01 / The opportunity
Today you price effort. Your users buy worth.
That is the whole opportunity: price each job on the value it delivers, and collect the spread. One price list for everyone, a different price per job, set before the run and explained by the rule that set it. Today agentic products price one of these four ways instead, and each one caps what the agent can earn.
Cost-plus
Tokens burned, plus a margin.
Revenue tracks the cost curve, not the value delivered. Every efficiency win cuts your own price, and the model vendor sets your profit.
Flat price
One price for every job.
A button tweak and an app that replaces a subscription go out at the same number. Work that differs by orders of magnitude is sold at one price.
Priced by size
Bigger job, bigger bill.
Steps, tokens and tiers measure effort, not worth. A run of hundreds of steps that fails is expensive. A one-shot that replaces a SaaS is cheap.
Subscription
One price a month, no matter what.
A flat fee, blind to how much the agent was used and to what its work was worth. The user who fixed one button and the user who shipped ten apps pay the same.
Priced by value
This is where Quoted comes in.
Quoted is designed to price every job on the value it delivers, the way a professional quotes work: what is it worth to the client, what will it cost to deliver, and the price lands between the two. Agents took over the professional's work. This gives them the professional's pricing.
02 / How it works
Job in. Price and reason out.
Before the run starts, Quoted reads the job, prices it on the value it carries, and returns the number with the rule that set it, in words the user can read.
1 · A job comes in
Your user asks for something. The job and its metadata go to Quoted before the run.
2 · Quoted estimates the cost
What serving this job will cost you, learned from jobs like it, tail included. This sets the floor.
3 · Quoted estimates the value
What the result is worth to this user: the scope of the ask, and the declared attributes of who is asking. This sets the ceiling.
4 · Quoted picks the price between them
Never below your cost plus your margin. As close to the value as this user will accept, learned from every yes and no before.
5 · A price and the reason come back
A value-based price plus an explanation you can show your user, returned before the run starts.
03 / The mechanism
How a price gets set.
Four parts behind one price. Three of them each answer one question about the job. The fourth picks the number, and says why. One of the four runs today; three are designed.
What will the job cost to serve?
Cost prediction
Finds the jobs that look like this one and returns what they actually cost, tail included. The tail sets the number, not the average, so the floor holds on the expensive runs too.
Returns the floor
Running prototype
What is it worth to the buyer?
Value prediction
Reads the scope of the ask and the declared attributes of who is asking. A whole campaign is worth more than the sum of its images, because the specification is the part they came to buy.
Returns the ceiling
Designed, not built
What does the price list allow?
Rule-based pricing
The published price list, as rules the decision has to obey: tiers, volume steps, contracted rates, minimum margin, caps. Nothing it returns falls outside what a customer could read on the pricing page.
Returns the bounds
Designed, not built
Where in the band does it land?
The decision
Not the highest price. The highest price times the odds this buyer accepts it, learned from every offer made, including the ones that came back no. Every price comes back with the rule that produced it, in words the product can put in front of the user.
Returns the price, and the reason
Designed, not built
Rejections are the asset. Every no is a point on the demand curve, and today most products throw them away. For a product that does not store rejected prices, the first step is not a model. It is starting to store them.
04 / Questions
The hard parts, up front.
- Who this is for
- An open task space, where the user asks in free text and the work varies by orders of magnitude. A charge decided in real time, before the run starts. And an agent loop doing the work, not a fixed pipeline.
- Who this is not for
- A closed set of intents, where a fixed price per intent is enough. One clear task per call, where the ask is always the same shape and a formula on the inputs already gets the price right. Enterprise passthrough with caps, where the risk already sits with the customer and there is no pain to solve.
This explodes in procurement.
Nobody is priced by identity. The price derives from declared attributes that are printed in the price list (average deal value, vertical, scope, close rate, LTV, sales cycle length) and the buyer classifies itself.
Identity-based pricing dies at the first invoice comparison and the first MFN clause. Attribute-based pricing is the version both customers can read.
We will build it ourselves.
The floor, probably. The acceptance curves have no source: a new customer of yours has no history, so the prior has to come from similar sellers, matched on the same declared attributes that set the price.
That is cross-customer data, and it only exists for a party sitting with many customers. Here it is a condition of the thing working, not a nice-to-have.
Users will split one big job into small ones.
To split "a campaign for every social network" into 100 image jobs, they have to already know which 100. That knowledge is the thing they came to buy.
The commercial precedent is the partner's hourly rate against the analyst's, same deliverable, published rate card. Volume buyers get a volume tier that prices them directly.
I do not want users thinking about price.
They will not. The band is internal and what surfaces is a credit charge, not a dollar figure. Your users already see a credit count on every run.
Who decides what counts as delivered?
Differential pricing starts arguments, and today the vendor rules on its own invoice. Outcome-based billing in support already had this fight: resolutions were counted that the customer would not have called resolutions, and the definition had to be rewritten in public.
Once prices differ per job, a third party that both sides can read is worth more than an in-house dashboard.
Thirty minutes on how you price today.
We go through what you charge now, where in the flow the price is decided, and which jobs you already suspect you are underpricing. You leave with the spread we think is sitting inside your current pricing and what it would take to capture it. No deck.