Agents Are the Heaviest SaaS Users You'll Ever Onboard

TL;DR

• The dominant narrative says AI kills SaaS. Jensen Huang thinks the opposite, and his framing is right: every capable agent becomes a power user of the software underneath it, so the install base explodes rather than collapses.
• I've shipped this pattern in production. My AI voice receptionist is one caller on one phone line, and inside a 90-second conversation it hits the calendar, the customer record, the booking engine, the SMS service, and the payment flow. One agent generates more tool use than three human sessions.
• The implication isn't "SaaS survives." It's that the SaaS worth running in 2028 looks like a company with a fraction of its human logins and a multiple of its programmatic load. You price, instrument, and build for agents, or the agents route around you.

---

The consensus in AI investor decks is that SaaS is cooked. Agents will commoditise workflows. Customers will spin up their own tools. The per-seat model falls apart, the UI becomes a liability, and the whole category drifts toward zero.

Jensen Huang just argued the exact opposite in a recent interview on the Dwarkesh Patel podcast, and he has the more interesting thesis.

His claim, roughly paraphrased: the number of agents is going to grow exponentially, which means the number of tool users is going to grow exponentially. Excel, Synopsys design tools, Cadence floor planners, every serious piece of software in the world. The install base skyrockets, not collapses. The reason software companies haven't felt it yet is that the agents aren't good enough at using tools yet. When they are, the volume hits.

That reframes the whole debate. AI isn't a wrecking ball swinging at your ARR. It's the onboarding of a new class of user who never sleeps, never leaves the product, and never ignores a workflow step.

What "tool use explodes" actually means

A human product manager hits your app maybe six to ten times a day. They click around, run a couple of reports, update two statuses, leave the tab open. That's the shape of a seat.

An agent hits your app differently. It opens, does one atomic thing in three API calls, and closes. But it opens a hundred times for every workflow the human used to run, because everything the human did by feel gets decomposed into verified, logged, tool-called steps. Agents don't batch. They don't shortcut. They grind the workflow.

In Jensen's language, you used to be limited by the number of engineers. Tomorrow, those engineers are going to be supported by a bunch of agents, and those agents are going to explore the design space in a way humans never could. Replace "engineers" with any role your SaaS serves. Replace "design space" with the decisions your software helps users make. The output is identical: more throughput per customer, more tool use per job, more workflow per dollar.

This isn't hypothetical. I've shipped it.

The voice receptionist is already a heavy agent user

OpenChair ships with an AI voice receptionist that answers the phone for beauty and wellness venues. A customer calls. The agent greets them, qualifies the request, checks availability, books the appointment, sends the SMS confirmation, and handles the deposit if one is required.

Count the tool calls.

A single 90-second call typically consumes around a dozen internal API calls: availability lookup, service catalogue fetch, staff roster check, customer record read, customer record write, booking create, SMS dispatch, payment intent create, payment confirm, calendar webhook, CRM sync, notification event. One caller. One phone line. One minute and a half.

Now compare that to how a salon owner used to work. A client walks in, they look at a paper diary, they scribble a name, they maybe send a text message that evening. The CRM entry happens three days later if it happens at all. The deposit is handled at the counter. Half the "workflow" lives in the owner's head.

The agent flattens all of that into traffic against the SaaS underneath. Not because the agent is showy. Because it has no shortcuts available to it. Every step it takes has to be a verified, idempotent, logged call into the platform.

Multiply that across a venue that takes forty calls a day. Then across a thousand venues. The total tool use from agent-handled calls dwarfs the tool use I'd get from the humans doing it manually. Same venue. Same revenue. Ten to fifty times the programmatic load.

That's the shape of what Jensen is describing. The agent is the substrate's heaviest user, not its replacement.

Why this is different from "hollow SaaS is dead"

I've argued before that hollow SaaS is dead. The CRUD-app-with-a-login category is structurally impaired because agents can bypass the interface and replicate the core function. That's still true.

This post is a different claim. The SaaS that survives doesn't just survive. It carries an order of magnitude more load per customer, because every agent operating on behalf of a user is a new class of power user transacting against the platform.

Three consequences flow from that.

First, the workflow-embedded SaaS that Linear's Kirill Vasiltsev defended gets more essential, not less, because agents need the context the platform holds. Linear isn't a CRUD app. It's the place where work originates, gets structured, and accumulates history. An agent that bypasses Linear to "do product management directly" produces generic work, because the context lives inside Linear. So the agent becomes a Linear user, and a heavier one than any human.

Second, the platforms that already own the queue of work become the natural homes for the agents that operate on that queue. Once your support tickets, your sales calls, your bookings, and your fulfilment events live in one system, every agent that does any of those jobs calls into that system. It doesn't bypass it. It couldn't, even if it wanted to.

Third, the vertical SaaS thesis gets stronger. Domain-specific software encodes decisions no foundation model will ever surface by itself: how trades quote a job, how salons handle a no-show, how accountants close a month. Agents need those decisions encoded somewhere. That somewhere is the vertical platform.

The dead category isn't SaaS. It's SaaS with no workflow, no context, no queue, and no domain.

What metrics should you track for agent traffic?

Most product teams still report the wrong metrics for this world.

Monthly active users assumes one log-in equals one workload. In an agentic setup that's false, because an agent handling a customer's week of work might generate ten thousand API calls and zero log-ins.

Session counts are similarly useless. The useful session length of an agent is sub-second. You get a spike graph, not a distribution.

Seat counts stop telling you anything about actual value delivered. A five-seat account where four seats are humans and one seat is an agent wrapper running the place could easily be your highest-revenue customer, and the seat report will say it's mid-tier.

What you actually want to measure:

• Tool calls per customer per day (and the rate of change)
• Ratio of agent-initiated to human-initiated actions
• Long-tail API endpoints hit by agents that humans rarely touched
• Workflows that shifted from "email attachment" to "agent loop through platform"

If you've been writing quarterly reviews with "monthly active users down 8% but feature adoption up" and nobody can explain why, the answer is probably that agents are already eating the human log-ins and multiplying the workload. Your metrics just weren't set up to see it.

How do you price SaaS when agents are heavy users?

Per-seat pricing collapses in the agentic era. That point I've made before. The new point is harder: if you reprice on pure usage, you accidentally tax your own success.

When an agent replaces a human bottleneck, consumption goes up by a factor of ten, twenty, fifty. Pure usage pricing turns that into an invoice shock that kills the customer. Pure outcome pricing is fairer but hard to instrument. The realistic answer is a hybrid stack: a platform fee for access, outcome-based metering for the value the agent delivers, usage guardrails so the bill doesn't spike when a rogue loop runs overnight.

The thing to avoid is the naive response of "we'll just charge per agent." You'll get one agent per account with a clever human routing every call through it. Every pricing mechanism based on counting discrete actors eventually gets gamed into one.

Price for load. Price for outcomes. Let the agents explode as they will.

What to do next quarter if you're a PM of a surviving SaaS

Three moves that actually matter.

Instrument for agent traffic. Separate your analytics into human-initiated and programmatic-initiated events. If you can't tell which is which, you can't size the opportunity, and you can't defend the metric when your board asks why seats are flat.

Harden the APIs that agents will want. The endpoints built for a human UI often have assumptions baked in: pagination defaults that don't match programmatic use, auth scopes that leak internal admin power, rate limits calibrated for human click speed. Fix them before the first customer's agent finds them.

Design at least one workflow that only makes sense with an agent driving it. Not a chat bubble. Not a copilot popover. An actual end-to-end flow where the human sets intent and the agent operates the platform on their behalf, beginning to end. If you can't picture that workflow for your product, your product is what gets bypassed.

The bet

Jensen's company makes its money selling accelerated compute, so of course he thinks tool use will skyrocket. The volume he's describing is literally his sales pipeline. Discount that incentive and the argument still holds, because the mechanism he's pointing at is a structural one: agents that are competent enough to do real work will do that work through software, not around it, because software is where the context, the history, and the levers live.

The SaaS companies that survive the next five years aren't the ones that hold their seat count. They're the ones whose platforms become the execution layer for every agent their customers deploy. The install base goes up. The human log-in count goes down. The programmatic load goes through the roof.

That's not a death sentence for SaaS. That's the second act.