A software price tag usually shows up at the very end of an article, in small print. But with agent software, there are times when you have to put that price tag on the table before the product design.
Let's start with a scenario. Up until yesterday, three people split the work. Today, one person and an agent handle it together. So who should the company that sold this software charge, on what basis, and how much? By headcount? By the volume of work processed? By the results that actually got done? The answer doesn't fall out easily. And how you answer this question is exactly what decides "what kind of company are we, really." This article isn't about what any particular company charges. It's about where the axis of competition shifts when the unit of pricing changes.
The default unit of traditional subscription software (SaaS — software you pay for monthly) is the "seat." Per-seat pricing means you charge by the number of people using the software. If 20 people use a collaboration tool, you pay for 20. It's simple, and the math is easy for both buyer and seller.
There's one reason this approach held up so long: software was a tool that assisted human hands. The one actually doing the work was the person; the software was the instrument sitting beside them. Pricing by how many hands are gripping the instrument feels natural.
With agents, this premise breaks. An agent is software that takes a goal a human assigns, then works through multiple steps on its own to get it done. It reads the email, compares schedules, checks inventory, drafts a reply, and brings only the approval to the person. It doesn't assist the hand — it takes over part of it.
Then a question arises. Who is the agent's "seat"? The agent itself, the person supervising it, or the number of cases it processed? If one person runs five agents, is that one seat or five? Conversely, if an agent finishes the work overnight with no human present, how many seats are those hours? The moment the unit detaches from the person, the seat as a yardstick stops fitting.
Let's be clear about one thing here. Change the pricing unit, and you change the scope the company is responsible for; change the scope of responsibility, and you change the product you have to build. That's why pricing isn't a number the marketing team sets at the end — it's a design decision that sets the product's direction first.
Three models are broadly mixed in the market today. Let's look at what pressure each puts on the vendor, and where that pressure gets stuck.
The buyer's budgeting is easy. Twenty-five people this month, so twenty-five seats, done. There's no variability, so the finance team likes it, and the seller can forecast revenue easily.
The problem is that the pricing moves in the opposite direction from what agents aim for. An agent is a thing built to keep the work running with less human attention. Yet per-seat pricing charges more the more people are attached. If a customer uses the agent well and cuts their staff from three to one, the vendor's revenue actually drops. The customer's success becomes the vendor's loss. Under this structure, the vendor is tempted to pile on notifications and dress up the dashboard to make people open it every day. While selling automation, the force pushes toward less automation. (Nothing fully prevents this temptation, but the fact that customers can grow sick of a product that "just keeps making me log in" and leave puts some brake on it.)
You charge by the volume processed. By number of cases handled, or by token count (a token is the unit a large language model — the AI that processes human language — uses to slice up text and count it, roughly one fragment of a word). Use more, pay more. The distance between value and pricing is shorter than with seats.
It gets stuck in two places. First, the customer gets anxious. You can't know in advance how big this month's bill will be. If the agent happens to run the same task several times, the cost spikes. For an organization that has to lock down a budget, this uncertainty alone blocks the purchase. Second, it creates an odd incentive for the vendor: the more it processes, the more it earns. Splitting a one-shot job into three steps isn't free for the vendor — the extra inference, tokens, and tool calls carry real cost — but under usage-based pricing those added steps can be billed to the customer, so the weight of that cost shifts off the vendor. The reason to improve efficiency weakens.
You get paid only when the work actually gets done, or in proportion to how much got done. So much per inquiry resolved, per booking confirmed, a percentage of receivables recovered. On the surface it's the fairest. The customer pays only for results, and the vendor gets paid only by producing results, so both interests face the same direction.
So outcome-based pricing puts the pressure on the vendor to "own it all the way through." But this pressure doesn't translate directly into a "product that owns it all the way through." That's because of the three walls we'll see next. In fact, the same pressure can also push the vendor in the wrong direction.
To count outcomes, you first have to define them so they can be counted. But work in the field doesn't break off cleanly.
Say you charge an agent that handles customer inquiries "per inquiry resolved." Then when is it "resolved"? When the agent sends a reply? When the customer doesn't ask again? When the customer presses the "resolved" button? Each criterion produces a different number. A customer who gave up and left and a customer who left satisfied look identical in the data — both just "didn't ask again."
If the criterion is loose, the vendor can inflate the number toward the easy side; if it's too strict, even work done properly doesn't get credited as an outcome. So half of outcome-based pricing is writing, clearly into the contract, "how outcomes are defined." In particular, if how rework is handled is left out, the billing interpretation for the same case splits month to month.
When a result comes in, it's hard to tell whether it was the agent's doing.
Say there's an agent that recovers receivables. 50 million won came in this month. The vendor says, "Our agent pressed for it, so it came in." But a substantial part of that may have been money that would have come in on schedule whether or not the agent did anything. Only the amount the agent pulled in additionally is the real outcome — and separating the two is hard.
To measure it properly, you'd need something close to an experimental design, comparing the side that used the agent against the side that didn't. Most customer organizations don't have the capacity to go that far. So attribution always ends up a guess, and trust breaks down as the vendor claims it contributed a lot while the customer says it would have happened anyway.
Cream skimming — in plain terms, "picking out only the easy ones" — means that when you get paid only on results, the vendor comes to want to do only the jobs that will "definitely succeed."
Under outcome-based pricing, the vendor, to avoid losses, hands the agent only the cases that look winnable and quietly passes the hard, unlikely cases off to humans or pushes them to the back. The result is a nice number like "agent success rate 95%." But that number is merely the result of picking out only the easy jobs; the thorny work the customer actually wanted automated remains untouched. What the customer wanted to buy was the handling of the hard work — but the pricing structure pushed the vendor toward the easy work.
So when you use outcome-based pricing, you can't look at completion rate alone. Only by placing the rework rate (the share that had to be reworked) and the share handed off to humans right next to the completion rate does it become clear whether that success rate is the result of dodging the hard work. Because of these three walls, pure outcome-based pricing works cleanly only in a very narrow band of work — where results resolve neatly into numbers, attribution is clear, and difficulty is even. Most real-world work isn't like that.
The pricing model decides in advance which company the fight favors. That's because the pressure of each model we saw above works differently depending on the shape of the company.
A player that already owns a big, broadly-used tool (the kind every employee opens daily — email, documents, collaboration tools) finds per-seat pricing convenient. They layer the agent onto existing seats and sell it bundled. When it comes in as a bundle with no added cost, even if a startup focused on a specific task says "our agent is smarter," the buyer easily answers, "why pay separately."
A company that owns the infrastructure to run models itself has a low processing cost, so it can lower the usage unit price and still hold out. This fight slides into cost competition, and the smaller player is at a disadvantage.
A specialist that knows a specific task deeply has room to differentiate on outcomes. To own outcomes, you have to know exactly how that task's results come out, where they go wrong, and what counts as "done" — and a broadly-deployed general-purpose tool struggles to define the different "done" for each task. The narrow-and-deep player, finally, can fight from a different spot than the big player.
Since each of the three models has flaws, the actual market doesn't tip toward one — it blends. The direction visible now reads roughly like this. This is the author's judgment, not settled fact.
At the bottom you lay a small fixed fee. It's the charge for keeping the platform running and the connections open. It gives the customer the reassurance that "at least this much is predictable." On top of that you add a variable fee tied to volume or outcomes. The outcome portion, because of the three walls above, gets attached carefully — limited to work where measurement and attribution are relatively clear. Outcome-based pricing is a structure where the vendor absorbs the cost of failed work, so the earlier and shakier the company's product is, the more fatal this volatility becomes. That's why it's safer to lay down cash flow first with a small fixed fee, and to add outcomes starting from the work where measurement has become clear.
Changing the unit itself is also handled carefully. Changing the pricing unit is, in effect, changing the nature of the contract, so the finance person pushes back first. So the usual path is to keep the existing unit while first adding the new unit as an option, applying it only to customers who want to move, accumulating data, and then considering a full switch.
Once this structure settles in, the competitive question changes too. The old question was "does it have more features, or is it cheaper?" The new question becomes "can this company show its outcomes in numbers, and can those numbers be trusted?"
Let's follow the abstract discussion through a single scene. For what it's worth, the author is on the side that builds these agents, and ONTLE is a service that attaches an agent playing the role of a PM (project manager) to the work. The case below isn't a real contract with a specific customer; it's constructed to show how pricing design reveals a product's identity.
There's a small parts manufacturer, and a client calls to say, "Move next month's delivery date up from the 15th to the 10th."
In a per-seat world, this request pops up as a notification on a staffer's screen. The staffer personally checks inventory, looks into the production schedule, calls logistics, and replies to the client. The software merely assists this process, nicely. Work runs only as long as one staffer is attached, and the vendor's revenue holds as long as that staffer logs in. How fast and how error-free the staffer finished has nothing to do with the billing.
Now say the PM agent receives the same request. The agent works through multiple steps on its own. It checks whether there's enough material inventory for the pulled-up deadline, matches an open slot on the production line against the schedule, finds which other orders get pushed back if it's moved up, and confirms whether the shipping time fits. Then it brings a tidy judgment to the person: "The 10th deadline is possible, but Client B's order slips by two days. Please decide whether to ask B for understanding." The person reads it and approves.
Here, how you set the pricing reveals this service's identity. Charge per seat, and the more the agent shrinks the staffer's two hours to five minutes, the more the customer cancels seats. The better it does, the more revenue gets cut. Charge by usage, and the more complex the deadline adjustment, the more the customer worries the bill will spike — so they come to not want to use the agent on exactly the complex cases.
So the design we chose blends all three, but makes the weighting clear. The baseline for keeping the service attached is charged as a fixed fee so the customer can budget, and on top of it we add variability with "the number of cases closed by human approval alone" as the core metric. Having chosen to count by outcomes, we take on the wall of measurement ourselves first. We nail down, at the head of the contract, when to regard something as "closed" — whether at the point the client's acceptance reply comes in, or at the point it's reflected in the production schedule — and we set the latter (reflected in the schedule) as the standard, so the number doesn't inflate from loose tallying. To that extent we accept the burden of billing later, and less.
What comes after approval matters more. If the person approves but, at the execution stage, the client reneges or materials fall through, that case is not counted as "closed" — the agent runs the re-adjustment procedure again. How many times the re-adjustment ran is tallied separately as the rework rate mentioned earlier, so the customer can check whether we dodged the hard cases. This is why I said pricing has to be put on the table before the product design.
Competitive analysis isn't only the seller's job. A buyer bringing in an agent can also gauge the vendor's intentions by reading the pricing unit. First, check whether the pricing unit faces the same direction as your company's "success." If you're buying an agent to attach fewer people, but the vendor earns more the more people are attached, the two will collide someday.
Next, before you close the proposal, it's good to ask the vendor these three things directly and get them in numbers:
Outcome numbers that can't clearly answer these three are likely to be marketing copy. There's no one correct pricing model. An organization that has to lock down a budget will find a proposal heavy on variable fees hard to pass, and an organization that wants to bet money on results will find pure per-seat pricing stifling. The product with a pricing structure that fits your organization's grain is the product that fits your organization.