
Jason Lemkin published the customer's side of agent pricing yesterday. Almost every pre-AI vendor SaaStr uses has now announced a charge for agent access. I want to write the vendor's side, because I have sat in that chair, at Salesforce and at the company where we killed the per-seat tier, and the move he is describing is the one I would retire.
The short version
Per Jason Lemkin, Salesforce is metering third-party agent access: every successful agent call through MCP or the API becomes a Flex Credit charge, at $5,000 to $100,000 per million calls against about $83 per million for the same call from an integration, 60x to 1,200x. HubSpot meters its own agents and leaves its MCP server free. Lemkin says the meter is not the problem, the stacking is (seat, storage, API tier, and a per-call meter, three bills for one piece of work), and offers vendors three fixes: cap the rate, let a registered agent replace a seat, or price the outcome. From the vendor side those are one migration in a fixed order, and the third is the hardest. When we killed a per-seat tier, disputes ran 12x projection, the unit definition produced 200-plus contested cases a week, and margin recovered to 71% only in month 22. The per-call meter stacked on the seat is the one pricing move that takes that trough and never reaches outcome revenue. Kill it.
What Lemkin published
The post is worth reading in full, so here is only what the argument needs.
HubSpot's increases are mainly for its own agents: Breeze credits, per-resolution pricing, custom agent metering since July. Its MCP server stays free for agents you bring. Salesforce goes the other way and meters third-party agents. Every successful call through MCP or the API becomes a Flex Credit charge, agents have to be registered, and existing customers migrate to the new billing at renewal.
His comparison is the part that will get quoted. Salesforce already sells extra integration API capacity at about $83 per million calls. The agent meter, by his reading, lands between $5,000 and $100,000 per million. Same endpoint, same record, same write. The multiple is decided by whether an integration or an agent made the call.
His reaction as a customer is already in motion. Agents read far more than they write. Most of the calls a vendor would meter are lookups against data the customer already has a copy of. So sync the records to your own database, read from the copy, write back only when something changes. He calls it a weekend project.
Then the spiral. Meter the access, usage drops because customers route around it, new agents get built against other systems from day one, less of the work touches the platform, and the thing that made a system of record sticky goes away before the renewal.
And the claim I want to argue with. The meter is not the problem, he says. The additive version is. Keep the seat, keep the storage premium, keep the API tiers, add a per-call meter. Three bills for one piece of work. The vendors who get it right, he says, will do one of three things: publish the rate and cap it, let a registered agent replace a seat instead of stacking on top of one, or price the outcome the way they already price their own agents.
Three fixes, one sequence
Those are not three options a vendor picks from. From the inside, they are one migration in a fixed order, and the order runs the opposite way from how easy they sound.
Publish the rate and cap it is what ships this quarter. It needs a pricing page and an admin switch. Lemkin rates Atlassian's version better for exactly this reason: Rovo credits cover the CLI and MCP calls, overage starts on a published date at a published rate, every paid plan carries a pooled allowance, reads draw nothing today, and an admin can cap it. A meter you can plan around.
Let a registered agent replace a seat is the migration itself. It is the thing The Pricing Migration Sequence: An 18-Month Quarterly Playbook spends six quarters on: internal alignment and a lead-customer pilot, hybrid pricing for new customers, cohort waves for strategic and mid-market accounts, then the long tail and the legacy sunset. The gross margin trough bottoms out around month 12 at 58 to 65%. Recovery to 70% and above lands somewhere in months 18 to 30. Four conversations decide whether it survives politically, with the CFO on the trough math, the CRO on the comp rewrite, the board on pre-selling the trough, and the lead customer on the reference, and each one takes six to eight weeks.
Price the outcome is month 18 of that program, not a checkbox next to the other two. Per-Outcome Pricing: What Gets Clearer and What Gets Terrifying has three redesigns. The cleanest one took $800 a seat to $1.75 per resolved ticket, which turned $16K a month into $31.5K at 77% margin with a happier customer. None of it could be invoiced until five things were in the contract: the unit definition, a dispute window, an arbitration path, a committed minimum, and a price ceiling.
What the migration actually costs
The reason I am blunt about the order is the after-action from the day we sunset a per-seat tier, written up in Field Report: What Broke When We Killed Our Per-Seat Tier.
Dispute volume came in at 12x projection. We had modeled 50. We got 600.
The unit definition, which had held through the pilot, produced more than 200 contested cases a week at scale.
Twelve accounts had migrated on paper and were barely using the product. Fourteen of 35 mid-market accounts, the ones with edge use cases, churned. Reps quietly negotiated unauthorized extensions for three accounts.
By month 22, outcome revenue was 91% of the base and blended gross margin was back to 71%. The board had approved the trough before month one. The strategy decks make the curve look smooth. It is not.
That is the bill for doing it right. Now look at what the stack does.
Why the stack is the one to kill
The per-call meter on top of the seat is not a smaller version of the migration. It is a substitute for it, and it takes the same trough without the payoff.
Here is the sequence from the vendor's chair. The meter goes live. The customer's platform team does the weekend project Lemkin describes, and the agents start reading from a copy. Agent traffic through the platform drops, so the metered revenue the finance model counted on does not arrive. The humans were already logging in less, which is why the meter moved to the API call in the first place, so at the next renewal the seat count shrinks too. The vendor now has fewer seats, less agent traffic, and a pricing model that has not moved an inch toward the outcome. It took the trough and skipped the migration.
There is a second cost, and it is the one I argued in Kill the System-of-Record Slide. Owning the record buys retention, not growth. ServiceTitan cut off a partner, kept essentially all of the roughly 1,000 shared customers, and added no revenue. Zero Copy proved the data layer is rentable. Lemkin's workaround is the customer proving it again, from the other side: a synced copy is a rented data layer with the vendor's own records in it. Pricing the reads does not defend the moat. It spends the retention that was the moat's only remaining value.
Lemkin is right that agent traffic is real load and somebody pays for it. He is right that agent identity, with scoped credentials per agent, is worth having regardless. What I would strike from his post is the idea that the three fixes are interchangeable. A vendor that ships the cap and calls it done is one renewal away from the same place as a vendor that shipped the stack.
What to do this week
If you own pricing at a pre-AI SaaS company and someone has asked for "a meter for agent access" this quarter, do three things in this order.
Ship the cap. Published rate, published date, pooled allowance, admin switch. Atlassian's shape, per Lemkin, is the one to copy.
Start the migration. Registered agents replace seats, one cohort at a time, with the trough math in front of the board before the first cohort moves. Pricing for AI Products has the full sequence.
Write the unit definition and the dispute window before the meter, not after. That is where the 600 disputes came from, and it is the part no pricing page fixes.
This belongs to the argument running through SaaS to AI Business Models: software priced per seat is priced against a labor cost that AI removes, and the pricing model has to move to the outcome. A meter on the call is the seat model refusing to move, with a coin slot bolted on.
Related answer: Should a SaaS vendor charge per API call for agent access?
Sources: Almost Every Pre-AI Vendor We Use Is Raising Prices for Agent Access. They May Be Building an Agentic Death Spiral, Jason Lemkin, SaaStr, September 28, 2026. Field Report: What Broke When We Killed Our Per-Seat Tier, falkster.com, May 11, 2026. Per-Outcome Pricing: What Gets Clearer and What Gets Terrifying, falkster.com, May 18, 2026.
Frequently asked
How is Salesforce pricing agent access to its APIs?+
As Jason Lemkin describes it in his 2026-09-28 SaaStr post, every successful call an agent makes through MCP or the API becomes a Flex Credit charge, agents have to be registered, and existing customers migrate to the new billing at renewal. His comparison: Salesforce already sells extra integration API capacity at about $83 per million calls, and the agent meter lands between $5,000 and $100,000 per million, 60x to 1,200x for the same endpoint and record.
What is the agentic death spiral Jason Lemkin describes?+
A vendor meters agent access. Customers route around it by syncing records to their own database, reading from the copy, and writing back only on change. New agents get built against other systems. Less work flows through the platform, so the thing that made a system of record sticky, that everything touched it, shrinks before the next renewal. His fix is any of three: publish and cap the rate, let a registered agent replace a seat, or price the outcome.
Why is a per-call agent meter on top of a seat a bad pricing move for a vendor?+
Because it is a substitute for the pricing migration rather than a step in it. The three fixes Lemkin offers are one sequence: cap the rate this quarter, let agents replace seats over the migration, price the outcome around month 18. The stack takes the margin trough that migration causes, agents leave first and seats follow a renewal later, and nothing has been repriced at the end of it.
What breaks when a SaaS company kills its per-seat tier?+
In the sunset I ran, dispute volume came in at 12x projection, 600 against 50. The unit definition produced more than 200 contested cases a week at scale. Fourteen of 35 mid-market accounts churned on edge use cases. Outcome revenue reached 91% and blended gross margin recovered to 71% by month 22, after a trough the board had approved in advance.
What does a per-outcome contract need before the meter goes live?+
Five things in writing: the unit definition, a dispute window, an arbitration path, a committed minimum, and a price ceiling. In one redesign, $800 a seat became $1.75 per resolved ticket, $16K a month became $31.5K at 77% margin, and none of it could be invoiced until those five terms existed.
How is Atlassian's Rovo credit pricing different from Salesforce's agent meter?+
Per Lemkin, Rovo credits cover calls through the Teamwork Graph CLI and the Rovo MCP server, overage billing starts 2026-12-03 at $0.01 a credit with a basic action at 10 credits, every paid plan carries a pooled allowance of 25, 70, or 150 credits per user per month by tier, reads draw no credits today, and admins get a switch to cap extra usage. He rates it better because the rate and the date are published and the meter can be planned around.

Comments (0)
Sign in with LinkedIn to leave a comment.
Sign in with LinkedIn