How to Price an AI Agent: The Framework for What to Charge and How to Prove It (Part 1 of 2)

Let's start with a scenario I keep seeing pitched, one that looks perfect on a spreadsheet: a risk-auditing platform charges customers a percentage of the risk value it identifies and prevents. The bigger the enterprise, the greater the exposure, the greater the value prevented, and, naturally, the greater the fee.

Value-aligned pricing. Textbook value-based design. It's also the kind of pricing model that can quietly open the door for a competitor to walk into your largest accounts, not by being better, but by being simpler.

We'll come back to that. It's one of the sharpest examples I've seen of a problem that runs through almost every pricing conversation I have with ISVs: the math can be spot-on, while the underlying psychology is completely off base.

Before we get to why, there's a more fundamental question most teams skip entirely: What are you actually charging for?

The Tier Progression: From Per-Input to Per-Outcome

In the architecture piece, I wrote about seven layers that have to be designed together. Pricing isn't an eighth layer added afterwards; it's a lens across all seven, and it tends to follow a progression as products mature. I think about it as five tiers, each answering the same question differently: what does the customer actually pay for?

1) Per Agent. The customer pays per deployed agent or seat served. Familiar, easy to budget, easy to sell. For the vendor, it's also the most predictable revenue line in the model; headcount is stable, contracts renew annually, and forecasting doesn't swing with usage the way activity- or outcome-based revenue does. But the value of an agent doing more autonomous work doesn't show up in the agent count, so pricing and value begin pointing in different directions, the same disconnect I described in the GTM piece.

This is where the model most often backfires. Microsoft and Google both tried flat, per-seat pricing for their AI assistants - Copilot and Gemini at $20–30 per employee per month, and ran into real customer resistance: value varied sharply by role. For example, a developer might use it daily, an administrator barely at all, yet every seat carried the same flat fee, and a per-seat add-on for a workforce of thousands is hard to defend internally without a clear line from cost to realized value. Per-agent pricing needs either a defined scope ceiling or a visible usage signal attached to it, or it reads as a tax on headcount rather than a price on work.

For example, Claude's own consumer subscriptions work this way in practice: a flat monthly fee paired with a rolling usage window that Anthropic tightens or loosens as demand and available compute shift. It was tightened in August 2025 under heavy load, doubled again in May 2026 once new capacity came online. The ceiling isn't a flaw in the pricing; it's the mechanism that keeps a flat fee sustainable against a cost base that moves.

2) Per Input. The customer pays for what they put in: API calls, tokens, documents processed. Easiest to implement, weakest signal; it charges for effort rather than results. For the vendor, it's also the weakest pricing power in the entire progression: you're monetizing at the cost layer, easy for a competitor to beat on price alone since there's nothing to differentiate on but the rate. The token-metered version of this carries an odd penalty on top: a smarter agent that solves the same task in fewer tokens earns the vendor less, even though call volume (how often the customer actually needs the agent) doesn't shrink just because the model got more efficient. OpenAI's API is priced this way, per million tokens processed, regardless of whether the output was useful; the classic foundation-model metric most agentic vendors build on top of, then move away from as they climb the tiers below. An agent that takes ten attempts costs the customer ten times more than one that gets it right the first time. That completely misses the point.

3) Per Activity. The customer pays per task, transaction, or workflow completed, such as a ticket resolved or a claim adjudicated. This ties price to work customers recognize as getting done, not infrastructure consumed. For the vendor, revenue now scales with actual usage instead of being capped at a flat fee, which keeps growth incentives aligned with the customers, but it requires real metering infrastructure to track reliably, and it can quietly reward maximizing the number of billable activities over the quality of each one. Document processing vendors like Hyperscience and Rossum charge roughly $1.50 per page processed, a clean per-activity metric where the unit is the task itself, not the outcome the task eventually produces.

4) Per Output. The customer pays for the deliverable produced: a report, a design, a drafted contract, regardless of how many attempts it took. For the vendor, this shifts technical efficiency risk onto you as you absorb the cost of every failed attempt, not just the one that ships, so your margin depends on how efficiently your agent gets to a usable result. For the customer, it's a stronger value signal: they are paying for what they keep, not what they tried. AdCreative.ai prices this way for ad creatives: generation itself is unlimited, and a credit is only spent when the customer downloads a finished creative.

5) Per Outcome. The customer pays for the business result itself: revenue protected, costs avoided, risk prevented. Some of the most attractive economics in agentic SaaS live here, because price scales with value delivered rather than effort or volume. Chargeflow, an AI chargeback-recovery platform, charges 25% of each disputed payment it wins back and nothing if it loses, a clean, real example of the model: no recovery, no fee. For the vendor, it's also the tier that demands the most maturity: you can't charge for an outcome you can't reliably measure and attribute, and unlike every tier before it, the burden of proving causality, not just correlation, sits entirely on your side of the table.

Choosing Your Metric: The COMPASS Framework

The five-tier progression tells you what the options are. It doesn't tell you which fits your product. For that, I'd point to COMPASS (Choice of Optimal Metrics for Pricing Agentic Systems & Solutions), developed by Michael Mansard and published in a joint AWS, Zuora, and Simon-Kucher whitepaper on agentic AI pricing.

COMPASS asks two questions. First, what's the scope of work: narrow tasks like a factory-line worker, a multi-step process like a service, or an open-ended goal like a partner? Second, how attributable is the impact? Can you trace a result directly to what the agent did, or is it mixed with other factors? Plot your product on those two dimensions, and you get a strong signal for where you can credibly operate on the tier progression.

A narrow-scope agent with diffuse attribution belongs closer to per-input or per-activity; claiming per-outcome pricing there is hard to defend to a sophisticated buyer and hard to measure yourself. Broad-scope agents pursuing measurable goals sit at the other end where outcome pricing becomes credible, economically attractive, and, by extension, where premium pricing becomes possible. Broad scope combined with high attribution creates a metric competitors struggle to replicate convincingly.

This is where the example from the architecture piece becomes relevant again. Intercom's Fin support agent moved to outcome-based pricing by charging per resolution and reported net revenue retention climbing from 112% to 146%. That's not a coincidence; resolution is a high-attribution, well-scoped outcome, exactly the COMPASS sweet spot.

The framework's own framing makes this point directly; pricing metrics are often the first thing teams focus on, but they're only one piece of the strategy. In agentic AI, pricing and packaging aren't downstream of go-to-market; they're part of the foundation the rest of the motion gets built on.

Value Measurement and Aligned Reporting

Choosing a high-attribution metric only holds up if the measurement behind it holds up too, and this is where most of the gap actually lives. A Gartner survey found 31% of chief sales officers cite proving the ROI of AI-driven tools as a top challenge to their 2026 objectives, and IBM's Institute for Business Value found only 25% of AI initiatives have delivered their expected ROI. The gap isn't uniform: Microsoft-sponsored IDC research puts the average return at $3.70 per dollar invested, with top-performing, well-measured organizations reaching $10.30; measurement rigor is a large part of what separates the two.

Three practices close that gap.

1. Capture a pre-agent baseline before go-live; you simply can't prove lift retroactively.

2. Build customer read-back access into the contract rather than retrofitting it at renewal, when the ask looks defensive.

3. Publish the methodology itself, not just the number, so the customer can audit it rather than take it on faith.

Reporting cadence matters as much as methodology. A recurring business review that shows the customer the same number you're billing against turns the invoice into a confirmation of something they already saw coming, not a sudden surprise.

So far, that's the foundation: what you actually charge for, the test for which tier you can credibly hold, and the measurement discipline that keeps a high-attribution metric honest. Everything harder gets built on top of it: how you package the metric, what earns you the right to charge a premium, and why an outcome-based model that scores perfectly on every framework here can still quietly cost you your largest accounts. That last one is the risk auditing example I opened with, and Part 2 is where I come back to exactly why it breaks.