Unit Economics of Deploying One Agent per SaaS User
Per-user agents force SaaS builders to rethink margins and pricing from scratch.
The software industry is moving from stateless AI assistance into persistent, autonomous delegation, and that shift forces a new cost model on every SaaS builder who wants to stay in the game. The pattern has moved through three distinct generations: prompt in, answer out; then prompt, tool call, result; and now intent, persistent agent, plan, execute, observe, re-plan, escalate. A user today doesn't need to know how to book a table. They can say "book a restaurant for Friday at 8 PM, use my usual preferences, ask before spending too much," and the agent works out every intermediate step on its own. None of that works without memory that survives between sessions. An agent that forgets everything when the session ends can never build a working picture of the person it serves, so it never actually delegates anything, it just answers the same question over and over.
The major platform vendors have already built for this. Sundar Pichai describes Gemini Spark as a personal AI agent that runs continuously in the background on Google Cloud, on dedicated virtual machines. xAI goes further with Grok Bots, describing them as always-on AI teammates that each get their own computer, a cloud machine shared per user, signing into the tools people already use, working continuously, and only surfacing when something needs approval. When hyperscalers treat dedicated per-user compute as the baseline, SaaS builders who serve those same users face the same architectural expectation. This isn't a frontier experiment anymore. More than half of enterprises already run AI agents in production as of 2026, and Gartner projects a sharp rise in enterprise applications integrated with task-specific agents by the end of the year, among the steepest adoption curves enterprise software has ever seen.
Once a company commits to running one agent per user, rather than one shared model serving many users through stateless requests, the per-user compute model produces a cost structure that looks nothing like anything a SaaS finance team has had to model before. That's the problem the rest of this piece works through.
SaaS unit economics for persistent agents
Classical SaaS economics rest on a simple idea: build the product once, and each additional customer costs almost nothing to serve, which is how the industry built its 80 to 90 percent gross margin targets. Persistent agents break that model at exactly one line item: cost of goods sold. Traditional software has a marginal serving cost close to zero, and mature SaaS companies post gross margins well above what AI-native companies manage today. An agent, by contrast, runs compute, inference, memory retrieval, and storage every time it does something, and those costs scale with how much the agent actually works. Bessemer Venture Partners reports that AI companies run at significantly lower gross margins than traditional SaaS companies, and ICONIQ's surveyed average has been improving year over year but still sits structurally below software margins.
Seat-based pricing suffers a second, separate failure. It was built around the assumption that one human seat does roughly one human's worth of work. An AI agent breaks that assumption outright: one agent can do the work of many human users, so charging per seat stops tracking the value a customer actually gets. The vendors with the most resources and the most pricing sophistication in the industry are still visibly working this out in public. Salesforce launched Flex Credits at a per-action price in May 2025, then added per-user licensing in late 2025, and now runs four pricing models at the same time. Atlassian bundles a set number of Rovo AI credits into its standard per-user plans, then bills extra for Virtual Service Agency conversations once a customer goes past the included limit. HubSpot charges an overage rate once a customer's AI credits run out, and Zendesk prices its AI resolution agent per resolved conversation rather than per seat. None of these companies has landed on a single stable answer, and that instability is the clearest evidence available that the old pricing playbook doesn't map onto agent-based delivery. Before a company can fix its pricing, it has to understand what it's actually paying for when an agent runs, which is a question most initial deployments answer wrong.
The four components of a running agent's cost
Most bad unit-economics estimates come from treating these as one undifferentiated blob instead of pulling them apart.
Inference is the most visible cost and, for most builders, the most overestimated per task. Raw token costs on a mid-tier model are modest on their own, but once a company adds embeddings, vector retrieval, orchestration, evaluation, and monitoring on top, the loaded cost per attempt settles in a range of roughly $0.15 to $0.30. At small-builder scale, the numbers stay manageable: one reported scheduling agent serving a few hundred active users ran on a low total monthly API bill, which works out to a modest variable cost per user per month. The figure to hold onto is that these costs apply only to active tasks. An agent sitting idle doesn't burn tokens, and that distinction is the hinge the entire economic model turns on.
Memory retrieval is the cost most developers skip over entirely when they first model this. The architecture that's become standard across the industry uses two tiers: a persistent store, whether that's a SQL database, a vector index, or a dedicated memory framework, holds everything the agent has ever learned about a user, and it feeds a small number of relevant memories into working memory on demand, rather than replaying the user's full history on every turn. Production-viable systems keep retrieval inside a tight token budget per query, and systems that need several times that budget simply aren't economical to run at scale. Token consumption per retrieval call can now be benchmarked directly, and the spread between a well-built memory system and a poorly built one changes whether the product is viable. Memory isolation itself carries a cost too, but a manageable one: scoping each user's memory by the identity already authenticated in the application avoids the need for a separate identity layer, which keeps that overhead under control.
Compute isolation is where most of the hidden cost actually lives, because most of it is idle time rather than work. A persistent agent doesn't run constantly. It spins up an environment, does a task, and then waits, on a model response, on a human reply, on a queue to clear. If the isolation layer underneath the agent is slow to spin up fresh, the only way to stay responsive during that wait is to keep the whole environment warm, reserving CPU and RAM and paying for compute the agent isn't using. Multiply that across thousands of mostly-idle tenants and idle compute can dwarf the cost of the actual work being done, which makes it the single biggest lever in the entire model. The wrong assumption treats idle compute as a standing charge per tenant, billed whether or not anything is happening. The right assumption treats idle compute as something that should approach zero, and it can, once snapshot-restore infrastructure makes that possible.
Storage is the correct thing to be paying for while an agent sleeps. A snapshotted, sleeping agent costs storage and nothing else, which is a fundamentally different billing shape than a warm virtual machine or a serverless function with a minimum billing unit that charges whether or not it's doing anything. Storage costs shrink further at fleet scale through copy-on-write memory: when many tenants start from the same configured baseline image, forking that one snapshot shares memory copy-on-write, so a hundred forks don't cost a hundred full copies of RAM.
How snapshot-restore changes the idle-cost calculation
Snapshot-and-restore is the mechanism that turns idle compute from a fixed standing charge per tenant into something priced closer to plain storage, but it only delivers the economics the per-user model needs if restore happens in under a second.
That latency threshold isn't an engineering nicety, it's a commercial requirement. An agent that takes several seconds to wake up loses the responsiveness that makes it feel like a live assistant rather than a broken one. Users don't experience a slow wake as "resuming," they experience it as the product failing. Sub-second wake time is the baseline a product needs to feel alive, and anything slower forces a company back into keeping agents warm around the clock, which reintroduces the exact idle compute cost the whole model is trying to eliminate.
The infrastructure that makes sub-second restore possible rests on micro-VM isolation. Firecracker micro-VMs emulate only a handful of devices rather than the full hardware surface a traditional virtual machine emulates, and that smaller footprint is what makes snapshot creation and restoration fast enough to be economically useful. Production deployments bear this out. One managed tier running Firecracker microVM isolation delivers fast cold starts from snapshot and bills at a low per-second rate. Another provider gives each workload a 100GB durable filesystem, backed by object storage with NVMe acting as a cache, that survives between sessions, and checkpoints and restores the entire disk state in roughly 300 milliseconds, with billing stopping the moment the workload goes idle and the data staying intact the whole time.
Once restore is that cheap, the economically correct move is to snapshot and delete outright: capture the agent's state, tear down the virtual machine completely, free the host for other work, and recreate the agent in under 200 milliseconds the next time a request comes in. Idle time is close to free because nothing is running that could generate a charge. For tenants carrying expensive warm state, like a large dependency tree, a headless browser, or a model already loaded into RAM, hibernation is the middle path: snapshot both memory and disk, stop the virtual machine, and wake it only when the next task arrives. Copy-on-write forking multiplies this benefit across a whole fleet. When many tenants share the same configured starting point, a same-host fork of that baseline snapshot runs in 400 to 750 milliseconds and shares memory copy-on-write, so the fleet gets cheaper per tenant as the user base grows, not more expensive.
None of this comes free of complications, and the model would be incomplete without saying where it strains. At high concurrency, setting up CNI plugins and virtual switches becomes the primary bottleneck in the system, and it can increase startup latency enough to turn a fast virtual machine boot into a multi-second delay. That's a real ceiling on naive fleet scaling, and any multi-tenant deployment expecting bursty, concurrent wake events across thousands of users at once needs to plan around it directly, rather than assume snapshot speed alone will carry the system through a traffic spike.
Unit economics with idle time modeled correctly
Once idle time is stripped out of the compute bill and storage becomes the only cost a dormant agent carries, the per-user monthly cost for a persistent agent falls into a range most SaaS pricing structures can absorb without resorting to usage-based billing workarounds.
Building that model component by component makes the shape of the savings clear. Inference cost only applies while a task is running, and at a loaded cost of $0.15 to $0.30 per attempt, a user who triggers their agent a handful of times a month generates a modest inference bill. Memory retrieval cost is bounded by tokens consumed per retrieval call rather than by how long a session runs, so a well-built memory system adds a small, predictable amount per active interaction instead of ticking up like a running meter. Idle compute cost approaches zero once snapshot-restore is in place, because a dormant agent isn't consuming CPU or RAM at all while it waits. Storage cost is the one expense that persists through the entire idle period, and at standard cloud storage pricing, a snapshotted agent pays for disk space, not for a process that's actually running.
Put together, the four components stop behaving like one unpredictable number and start behaving like a model a finance team can actually plan around: a small, bounded inference charge tied to real usage, a small and predictable memory charge tied to real interactions, close to nothing for the hours or days an agent spends waiting, and a flat, low storage charge that covers the rest. That's the structural correction most initial deployments miss, and it's the reason the naive version of this math, the one that assumes an agent is a standing virtual machine running around the clock for every user on the platform, overstates the real cost by a wide margin. Model idle time correctly, and the per-user agent stops looking like an unaffordable luxury reserved for enterprise contracts and starts looking like an architecture a mainstream SaaS pricing tier can actually carry.