GaaS Has No MRR Yet, Here's the Metric That Should Replace It

Table of Contents

• The Problem: MRR Was Built for a World That No Longer Exists
• Why Per-Task Revenue Refuses to Behave Like a Subscription
• The Three Things MRR Quietly Assumed
• What the Replacement Metric Has to Do
• Committed Task Throughput: The Anchor Metric
• How to Calculate CTT
• Why "Committed" Is the Load-Bearing Word
• The Supporting Stack Around CTT
• A Worked Example: Two Customers, Same MRR, Different Reality
• What Investors and Boards Should Ask Instead
• Insights Most People Overlook
• References

The Problem: MRR Was Built for a World That No Longer Exists

Monthly Recurring Revenue is the most beloved number in software. It built the SaaS playbook: predictable, smooth, easy to multiply by a forward multiple and slap on a pitch deck. A board could look at MRR, draw a line, and feel something close to certainty about next quarter.

Agentic AI-as-a-Service breaks that comfort. When you sell an AI agent that completes tasks, resolving a support ticket, drafting and sending an outbound sequence, writing and merging a pull request, you usually don't sell a seat or a flat subscription. You sell completed work, priced per task or per outcome. And completed work is bursty. A customer might run 4,000 tasks in a launch week and 200 the week after. There's no "recurring" in the sense MRR means it, because nothing is contractually flowing every month at a fixed rate.

So GaaS founders do something a little dishonest, often without meaning to: they take last month's usage revenue, call it MRR, and annualize it. That number looks great until usage dips and the "recurring" revenue evaporates. The metric was never recurring. It was a snapshot of consumption wearing a subscription's clothes.

This isn't a niche accounting quibble. It's the central measurement problem of the entire category, and it sits underneath every other question in agent economics, from how to define cost-per-completed-task as the core unit to how venture investors should price these companies at all. If you can't describe the revenue honestly, you can't manage it, forecast it, or fairly value it.

Why Per-Task Revenue Refuses to Behave Like a Subscription

Three structural features of agent products make usage revenue fundamentally un-MRR-like.

First, demand is event-driven, not calendar-driven. A support agent's volume spikes when the customer ships a buggy release. A sales agent's volume spikes during a campaign push. The customer isn't paying you for access; they're paying you for throughput, and their need for throughput is lumpy by nature.

Second, the cost of delivery is variable and sometimes ugly. A SaaS seat costs you roughly the same to serve whether the user logs in twice or two hundred times. An agent task costs real money every single time, inference, tool calls, retries. When a task quietly balloons from one model call into fifty because of retries and sub-agent fan-out, your margin on that "revenue" can go negative without anyone noticing until the cloud bill lands. (That dynamic, one task becoming many calls, deserves its own teardown, and it's a recurring theme across agent unit economics.)

Third, the unit of value is contested. With per-outcome pricing, you only get paid when the agent succeeds. But "success" and "completion" are not the same thing, and the gap between an agent's success rate and its task-completion rate is where a lot of phantom revenue lives. If you book revenue on completions but the customer only values successes, your reported numbers and your real value diverge.

Put those together and you get revenue that is real but not recurring, valuable but not smooth, and impossible to forecast with a SaaS-style linear projection. Bessemer's long-running work on cloud and consumption businesses has made a version of this point for years: usage-based companies need different efficiency and retention metrics than seat-based SaaS, and agents push that divergence to an extreme.

The Three Things MRR Quietly Assumed

It helps to name what MRR was secretly relying on, because every assumption fails for agents.

1. Continuity. MRR assumes the customer relationship produces revenue every month by default, and that a missing month is an anomaly (churn). For agents, a quiet month can be perfectly healthy, the customer just didn't have work. Treating zero-usage months as churn signals will make you panic at the wrong customers and ignore the right ones.

2. Decoupling of revenue from cost. In SaaS, once the software is built, marginal cost to serve is near zero, so revenue ≈ contribution. MRR can stand in for gross profit. For agents, revenue and cost move together task by task, so a dollar of "MRR" might be 70 cents of margin or negative 20. The number tells you nothing about whether you're making money.

3. A single, stable price. MRR assumes a knowable monthly price per customer. Agent pricing is a moving target: token costs swing, blended multi-model rates shift, and the same task can cost wildly different amounts depending on difficulty. There is no clean "price per month" to recur.

When all three assumptions break, you don't fix MRR. You replace it.

What the Replacement Metric Has to Do

Before proposing a number, it's worth stating the job description. A good GaaS top-line metric must:

• Predict the near future from observed behavior, not from a contract that may not reflect reality.
• Be margin-aware, or at least pair cleanly with a margin metric, so a dollar of it means roughly the same thing across customers.
• Treat lumpiness as signal, not noise, distinguish "this customer's natural cadence is quarterly bursts" from "this customer is leaving."
• Be poolable across customers so the company can roll it up into something a board and an investor can reason about.

MRR fails the first three. The fix is to stop measuring dollars-per-month and start measuring the durable behavior underneath the dollars: how much real work a customer reliably sends you.

Committed Task Throughput: The Anchor Metric

The metric I'd put at the center of a GaaS company is Committed Task Throughput (CTT), the volume of completed, margin-positive tasks a given customer reliably generates per period, measured at the customer's own natural cadence and then normalized.

CTT is deliberately not a dollar figure. It's a throughput figure, because throughput is the thing that actually recurs in an agent business. Customers don't recur on price; they recur on the kind and volume of work they hand off. A support team that has decided to route tier-1 tickets to your agent will keep routing tier-1 tickets, week in and week out, even as the dollar amount bounces around with ticket volume and per-task cost. That routing decision, that committed handoff, is the durable asset. CTT measures it.

How to Calculate CTT

A workable definition:

CTT = the trailing-period count of completed tasks that (a) cleared your success bar and (b) carried positive contribution margin, smoothed over the customer's natural usage cycle.

Three pieces matter:

• Completed and successful, not merely attempted. A task that retried fifty times and failed is cost, not throughput. Counting it would repeat MRR's original sin of confusing activity with value.
• Margin-positive. Tasks you served at a loss don't count toward healthy throughput. This is what keeps CTT honest in a way MRR never was, it bakes the cost side in at the definition level. (You'll still want a separate gross-margin metric; CTT just refuses to credit you for unprofitable volume.)
• Smoothed to the customer's cadence. If a customer naturally bursts quarterly, you measure CTT on a trailing window that captures a full cycle, then express it as a normalized per-period rate. This is the step that turns lumpiness from noise into signal.

From CTT you can derive a revenue view by multiplying throughput by realized price per task, but the point is that throughput and price are tracked separately, so when revenue moves you immediately know whether volume changed or price changed. MRR blends those two and hides the cause of every move.

Why "Committed" Is the Load-Bearing Word

Raw task volume is too noisy to anchor a business. The word that does the work is committed: throughput that reflects a customer's structural decision to route a category of work to your agent, as opposed to a one-off experiment.

You detect commitment through behavior, not contracts: repeated use across multiple cycles, integration depth (the agent is wired into their systems), and breadth of task types handed off. A customer who has moved an entire workflow to your agent has high committed throughput even in a slow month. A customer running a free trial against synthetic tickets has near-zero committed throughput even if this week's raw volume looks huge. Distinguishing the two is exactly the judgment MRR can't make and CTT can.

The Supporting Stack Around CTT

No single number runs a company. CTT is the anchor, but it needs three companions to be useful:

• Task-based Net Revenue Retention (Task NRR). Measure expansion and contraction in task volume per cohort, not dollars. Did last year's customers send more tasks this year or fewer? Dollar NRR can look flat while underlying engagement collapses (price went up, usage went down) or look healthy while you're quietly losing the relationship. Tracking retention on tasks surfaces the truth earlier, which matters enormously because churn in usage-based models is notoriously invisible until it's catastrophic.

• Contribution margin per task. CTT only counts margin-positive tasks, but you still need the actual margin number, trended over time, because token volatility and retry behavior can erode it week to week. This is the metric that catches the "we'll just pass through model costs" trap before it eats the business.

• Human-intervention rate. The share of tasks that required a human to step in. This is the closest thing GaaS has to a leading churn indicator: when intervention rates climb, the customer's trust, and their committed throughput, is about to fall. It's effectively the new "product engagement" health score for agents.

Together these four, CTT, Task NRR, contribution margin per task, and human-intervention rate, give you what MRR pretended to give you alone: a read on whether the business is growing, healthy, and worth more next year than this year.

A Worked Example: Two Customers, Same MRR, Different Reality

Picture two customers of a support-agent company, each generating $10,000 of usage revenue last month. By MRR logic they're identical: $10K each, $20K combined, annualize to $240K, done.

Now look through the CTT lens.

Customer A ran 50,000 successful, margin-positive resolutions across the month at a steady daily cadence. The agent is integrated into their helpdesk; tier-1 tickets route to it automatically. Human-intervention rate is 4% and falling. Contribution margin is 68%. Their committed task throughput is high and stable. This is a customer you could lose only through a deliberate decision on their part.

Customer B also billed $10,000, but it came from a single chaotic launch week. They ran 90,000 tasks, of which a third failed or required human cleanup, and the retry storms pushed contribution margin to 11%. Outside that week, usage was near zero. Their committed throughput is low; what looks like $10K of revenue is really one risky experiment that may never repeat.

MRR says these customers are twins. CTT, Task NRR, margin-per-task, and intervention rate say one is a durable asset and the other is a coin flip booked as recurring revenue. If you're forecasting next quarter, valuing the company, or deciding where to spend customer-success time, that distinction is the whole game, and it's precisely what investors will need as the category matures past SaaS-style revenue multiples that don't fit usage businesses.

What Investors and Boards Should Ask Instead

If you sit on a GaaS board or write checks into the category, retire the question "what's your MRR and what's the growth rate." It invites the annualization fiction. Ask instead:

• What's committed task throughput, and how is it trending per cohort? (Are customers structurally handing you more work over time?)
• What's contribution margin per task, and how volatile is it? (Is the revenue actually profitable, and how exposed are you to inference-cost swings?)
• What's the human-intervention rate, and which direction is it moving? (Is trust building or eroding?)
• What share of "revenue" comes from committed vs. experimental usage? (How much of the top line would survive a bad quarter?)

Those four questions can't be answered with a single smoothed dollar figure, which is exactly the point. The category that sells autonomous work needs metrics that respect how autonomous work actually flows, in bursts, at variable cost, tied to outcomes. MRR was a beautiful abstraction for a world of fixed seats and near-zero marginal cost. GaaS doesn't live in that world, and pretending otherwise just delays the reckoning.

Insights Most People Overlook

• Zero-usage months are often your healthiest signal, not your scariest. A customer who runs nothing for three weeks and then routes their entire workload to you in week four has higher commitment than one who dribbles tasks daily out of an unfinished experiment. MRR-brain trains you to fear the quiet customer; CTT-brain teaches you to read cadence. The companies that win will get good at distinguishing "dormant by design" from "dying," and that's a behavioral-analytics problem, not an accounting one.

• Counting only margin-positive tasks changes sales behavior, not just reporting. The moment your North Star metric refuses to credit unprofitable volume, your team stops chasing logos that generate cheap, money-losing tasks. This is the opposite of the SaaS land-grab instinct, where any seat was a good seat. In GaaS, throughput you serve at a loss is negative-value growth, and a metric that says so out loud quietly fixes a lot of strategy.

• The "outcome" in per-outcome pricing is frequently unmeasurable, which corrupts any revenue metric built on it. If you can't cleanly observe whether the agent actually produced the outcome the customer cares about, a closed deal, a genuinely resolved issue, then revenue booked on "outcomes" is partly fiction. CTT sidesteps this by anchoring on completed, success-bar-clearing, margin-positive tasks, which are observable, rather than on downstream business outcomes you can't always attribute.

• Falling token prices will not save your margin metric, so don't build forecasts that assume they will. Cheaper tokens have historically been absorbed by agents simply doing more, more reasoning, more tool calls, more retries, rather than by bills going down. Any CTT or margin model that pencils in "inference gets cheaper, margins improve" is likely to be wrong. Model the work-per-task expanding to fill the cost savings.

• MRR's real damage is cultural, not numerical. The deepest problem isn't that the number is slightly off, it's that calling usage "recurring" trains the entire org to expect smoothness and to treat every dip as a fire. Switching to throughput-based metrics resets expectations: lumpiness is normal, cost is part of the unit, and trust (intervention rate) is the thing to defend. That mindset shift is worth more than any single dashboard tile.

References

• Scaling Usage-Based Pricing, Bessemer Venture Partners
• The Economic Case for Generative AI and Foundation Models, Andreessen Horowitz (a16z)