Per-Task, Per-Outcome, Per-Seat: A Field Guide to the GaaS Pricing Taxonomy

Table of Contents

• Why Pricing Is the Hardest Problem in GaaS
• The Three Anchor Models
• Per-Seat: The Comfortable Lie
• Per-Task: The Honest Meter
• Per-Outcome: The Salesperson's Dream and the CFO's Nightmare
• The Hidden Fourth Axis: Who Holds the Cost Risk
• How the Three Models Compare on Risk and Margin
• Hybrids Are Where the Market Is Actually Landing
• A Practical Decision Framework
• Insights Most People Overlook
• References

Why Pricing Is the Hardest Problem in GaaS

Pricing a traditional SaaS product is, by comparison, a solved exercise. You count humans who log in, you charge per head, and your costs barely move whether a user clicks ten times a day or ten thousand. The marginal cost of one more session rounds to zero. That single fact is why per-seat pricing dominated software for twenty years.

Agentic AI breaks that arrangement at the foundation. When you sell an agent that does work, you are no longer selling access to a tool that a human operates. You are selling the labor itself. And labor has a real, variable, sometimes brutal marginal cost: every task an agent completes burns tokens, calls external APIs, retries on failure, and occasionally spirals into a reasoning loop that costs ten times what you budgeted. The economics of inference are not free, and they are not stable. A vendor who prices a GaaS product the way they priced their old SaaS seat is, in effect, writing the customer a blank check drawn on their own gross margin.

So the pricing question stops being a packaging decision and becomes an existential one. Get the meter wrong and you either cap your revenue below the value you create, or you ship negative-margin work at scale and call it growth. The taxonomy below is the map most teams are missing when they wander into this.

The Three Anchor Models

There are really three pure forms, and almost everything else in the market is a blend of them. Think of them as three points on a triangle, with most real pricing pages sitting somewhere inside.

Per-Seat: The Comfortable Lie

Per-seat pricing charges for the number of human users who have access to the agent. It is the model buyers already understand, the model procurement teams already have line items for, and the model your sales team already knows how to sell. That familiarity is its entire appeal, and it is not nothing, friction in enterprise procurement is a real tax, and a known unit of account skates past a lot of it.

The problem is conceptual. An agent's job is to reduce the number of humans needed to do the work. Charging per seat ties your revenue to headcount at exactly the moment your product is designed to shrink headcount. You are pricing the thing inversely to the value you deliver. A customer who deploys one agent to do the work of five analysts will, under per-seat logic, pay you for one or two seats while capturing the value of five salaries. The better your product performs, the worse your capture ratio gets.

There is also a usage mismatch that bites the vendor. A single "seat" might run an agent that processes fifty tickets an hour, all day. The seat metaphor assumes a human's natural rate-limiting; agents have no such governor. Per-seat with no usage component is how you end up subsidizing your heaviest users while your light users subsidize nothing. We cover the structural case against this model in depth in #58.

Per-seat is not dead. It survives as a floor, a predictable base that anchors enterprise budgets, and it is making a quiet comeback among vendors who got burned by metering complexity, a trend examined in #70. But as a standalone meter for an autonomous agent, it is increasingly a comfortable lie both sides tell to keep the contract simple.

Per-Task: The Honest Meter

Per-task pricing charges for each discrete unit of work the agent performs: a resolved support ticket, a drafted contract, an enriched lead record, a reconciled invoice. It is the most economically honest of the three because it tracks the thing that actually costs you money, work done, and aligns the bill with consumption.

The buyer appeal is obvious in a pilot. "You only pay for what the agent actually does" is an easy sentence to say in a sales call. And on the vendor side, per-task gives you a clean unit economics story: if a resolved ticket costs you 18 cents in inference and you charge 90 cents, your margin is legible and defensible. This is the logic behind per-resolution support pricing, the model popularized by Intercom's Fin and dissected in #77.

The catch with per-task is twofold. First, it introduces buyer anxiety. A metered bill that moves every month makes finance teams nervous; they cannot forecast it, and humans are loss-averse about variable costs in a way that quietly suppresses usage. There is real research showing metered billing changes user behavior, people ration, hesitate, and under-adopt to avoid the meter, which is exactly the opposite of what a land-and-expand motion needs. Second, "task" is a slippery unit. Is a half-completed task billable? What about a task the agent attempts, fails, and escalates to a human? Defining the billable event precisely is harder than it looks, and ambiguity there is where customer trust quietly erodes.

Per-task is the workhorse model of the current GaaS market, and for good reason. It is honest, it scales with value reasonably well, and it keeps your margin visible. But it is not the model that lets you charge for the full value you create, only for the activity that produces it.

Per-Outcome: The Salesperson's Dream and the CFO's Nightmare

Per-outcome pricing charges only when the agent achieves a defined business result: a meeting booked, a deal closed, a dollar recovered, a fraud case prevented. This is the model everyone in GaaS marketing wants to talk about, because it is the one that aligns price with value most directly. "We only get paid when you win" is the strongest positioning statement in the entire category, strong enough that there is now an outright marketing war over who can claim it most credibly, which we explore in #78.

When it works, outcome pricing is extraordinary. It collapses the buyer's risk to near zero, which obliterates sales friction. It lets the vendor capture a slice of genuine value rather than billing for activity. And it tells a story that maps cleanly onto how executives think, they buy outcomes, not software. The venture community has been loudly bullish on this shift; analysts at a16z have argued that outcome-based and usage-based pricing represent a structural change in how software value gets captured, not a passing fad, in their writing on the new business of AI and what it means for pricing.

Then the CFO does the math, and the romance fades. Outcome pricing creates three hard problems. The first is attribution: who decides the outcome happened, and who audits it? If your agent and the customer's own team both touched the closed deal, what share do you bill? This definitional fight is serious enough to warrant its own treatment in #57. The second is margin volatility. You still pay for every token the agent burns chasing outcomes that never materialize, you eat the cost of all the misses and only get paid on the hits, so your effective cost per successful outcome can be many times the inference cost of that single success. The third is legal exposure. Tying payment to results edges toward success-fee and contingency structures that carry real contractual landmines, a topic covered in its own right elsewhere in this beat (#62).

Outcome pricing also quietly favors incumbents. To price on outcomes you need historical data to know what a "normal" success rate looks like and to price the risk. A vendor with years of outcome data can price aggressively; a startup pricing blind is gambling. That asymmetry is underappreciated and worth sitting with.

The Hidden Fourth Axis: Who Holds the Cost Risk

Most pricing discussions treat the taxonomy as a one-dimensional menu, pick seat, task, or outcome. That framing misses the axis that actually determines whether a GaaS business survives: who absorbs inference cost volatility.

Inference costs are not a fixed input. They swing with model choice, context length, retry behavior, and the underlying provider's pricing, which itself drops in sudden steps as new models ship. A pricing model is, underneath the marketing, a contract about who eats that volatility.

Per-seat puts all cost risk on the vendor. The customer pays a flat number; if their agents go on a token bender, that is the vendor's problem. Per-task shares the risk, the customer pays more when they do more, but the vendor still eats per-task cost spikes from a particular task running expensive. Per-outcome concentrates the most cost risk on the vendor, because the vendor pays for every failed attempt and only recovers on success.

This is why margin-safe pricing, passing through or hedging volatile inference costs, has become its own discipline, treated in #63. It is also why sophisticated vendors quietly route requests to the cheapest adequate model to protect margin regardless of which headline meter they advertise. The meter the customer sees and the cost structure the vendor manages are two different layers, and conflating them is how startups discover their "profitable" outcome pricing was bleeding cash all along.

How the Three Models Compare on Risk and Margin

A quick side-by-side, because the tradeoffs compress nicely:

Dimension	Per-Seat	Per-Task	Per-Outcome
Value alignment	Weak (inverse to headcount reduction)	Moderate (tracks activity)	Strong (tracks results)
Revenue predictability	High	Low to moderate	Low
Buyer-side budget anxiety	Low	High	Moderate
Vendor margin risk	High (flat fee, variable cost)	Moderate	Highest (pays for misses)
Sales friction	Low (familiar)	Moderate	Lowest (risk-free framing)
Definitional/audit overhead	Minimal	Moderate ("what is a task?")	Severe ("who owns the outcome?")
Best fit	Stable, internal-tool agents	High-volume, well-defined work	High-value, attributable results

The pattern that falls out: predictability and value-alignment trade off against each other almost perfectly. Per-seat gives you a forecast and surrenders alignment. Per-outcome gives you alignment and surrenders the forecast. Per-task sits in the uneasy middle, which is exactly why it is the default and exactly why so few teams are happy with it.

McKinsey's analysis of the economic potential of generative AI frames the value at stake in labor terms, trillions in productivity, which is precisely why pricing that captures value (outcome) is so tempting and pricing that captures access (seat) leaves so much on the table.

Hybrids Are Where the Market Is Actually Landing

If you stop reading pricing-page headlines and start reading the fine print, almost no serious GaaS vendor ships a pure model anymore. The market is converging on hybrids, because each pure form has a fatal flaw that a second meter can patch.

The dominant emerging shape is base plus usage: a platform or seat fee that anchors the budget and pays for the vendor's fixed costs, plus a per-task or per-outcome component that captures variable value. This gives the vendor a revenue floor (solving outcome pricing's unpredictability) and the customer a value story (solving seat pricing's misalignment). Done well, it is the best of both; done badly, it is double-charging that buyers resent. The right way to construct it is its own subject (#59).

Around that core, the market is layering in budget-protection mechanisms that have become near-mandatory: prepaid credit pools that smooth out metered anxiety (#66), floor-and-ceiling structures that cap a customer's downside risk (#67), and usage caps that protect both parties from a runaway agent (#80). These are not pricing models so much as guardrails on pricing models, and their rapid spread tells you the market learned, fast, that raw metering scares buyers.

The honest read on 2026: the taxonomy is no longer "pick one." It is "pick a primary meter that aligns with your value, then bolt on the predictability and guardrail mechanisms that keep the buyer's CFO calm." The vendors winning enterprise deals are the ones who let the buyer feel the safety of a subscription while paying for the value of an outcome.

A Practical Decision Framework

If you are pricing a GaaS product right now, three questions cut through most of the noise:

Can you cleanly attribute the outcome? If yes, and the outcome is high-value, lean toward per-outcome with a base fee. If attribution is contested or multi-touch, do not, you will spend more on disputes than you earn on the premium. Move to per-task.

Is your per-unit cost stable and known? If your inference cost per task is predictable, per-task pricing is safe and honest. If costs swing wildly per task, you need either a base fee to absorb the variance or aggressive model routing to flatten it before you expose a per-task price.

How sophisticated is the buyer's finance function? Mature FinOps buyers (#92) can handle and even prefer consumption pricing; they want to pay for value and have the tooling to forecast it. Less mature buyers will choke on a variable bill and need the comfort of a subscription floor. Price to the buyer you actually have, not the rational buyer you wish you had.

The taxonomy is a map, not a menu. The skill is knowing which meter aligns with the value you create, which guardrails keep the buyer comfortable, and which cost structure quietly protects your margin underneath all of it.

Insights Most People Overlook

The meter the customer sees and the cost model you run are different layers, and should be. Plenty of vendors advertise per-outcome pricing while internally running aggressive model routing to keep cost-per-attempt low. The headline meter is a value-capture and sales-friction decision; your cost structure is a separate margin-defense decision. Treating them as one number is how teams ship "outcome pricing" that quietly loses money on every win. Decouple them deliberately.

Per-task pricing can actively suppress the adoption you need to expand. The same metered bill that feels "fair" creates a psychological tax: users ration their usage to avoid the meter ticking up. In a land-and-expand motion, that is poison, you want usage to grow unconsciously, and a visible per-task meter trains the customer to do the opposite. Prepaid credit pools exist largely to hide the meter and remove that friction. The pricing that feels fairest can be the pricing that strangles your growth.

Outcome pricing structurally favors whoever already has the data. To price on outcomes you must know the base rate of success and price the risk of failure. A vendor with years of outcome history can price tight and win; a startup pricing blind is effectively underwriting an insurance policy on a risk it cannot estimate. This means outcome pricing is not the great equalizer it is marketed as, it is an incumbent's weapon, and challengers should think twice before fighting on that ground.

"What counts as a task" is a contract clause, not a pricing detail. The single most under-specified thing in GaaS pricing is the billable event. Does a failed attempt bill? A partial completion? An escalation to a human? Vendors who leave this fuzzy to keep the sales conversation smooth are seeding their biggest future disputes. Define the billable event with the precision of a legal term, because that is what it is.

Falling model costs are a repricing time bomb. When inference costs drop, and they keep dropping, your margins quietly expand, which sounds great until a sophisticated customer notices and demands a price cut, or a competitor passes the savings through and undercuts you. Every per-task and per-outcome price you set today is implicitly a bet on future model costs. The vendors who think about the grandfather problem now will not get caught flat-footed when their cost basis halves.

References

• The New Business of AI (and How It's Different From Traditional Software), Andreessen Horowitz
• The Economic Potential of Generative AI: The Next Productivity Frontier, McKinsey & Company