Serverless Agents Without Machines: Scale-to-Zero for Fleets of Mostly-Idle Agents

1. Idle-time-is-free, minus the machine

An agent spends almost all of its wall-clock life waiting: on model inference, on a human approval, on a cron tick, on an inbound webhook. A runtime built for agents should therefore make idle time nearly free and make waking cheap. This is exactly the bet the serverless-agent category makes. A serverless agent is an addressable, durable actor that sleeps on idle, wakes on request, and persists its state across the gap, so a fleet of mostly-idle agents costs almost nothing while asleep.

The runtimes shipping this today agree on the shape and differ only in the machine underneath. agentOS wraps each agent in a Rivet Actor that sleeps after an idle budget and persists to per-agent SQLite; Cloudflare Agents put each agent in a Durable Object and use the WebSocket Hibernation API to evict it from memory while keeping its socket open; Vercel Fluid Compute bills active CPU and shares compute across invocations so idle CPU is free. All three monetize idle-time-is-free. All three still pay a machine's floor to do it: a sleeping actor is a stopped microVM or an evicted container that reserves a memory quantum when live, and a wake is a boot.

We asked what serverless agents look like when the machine is removed entirely, so that a sleeping agent is not a suspended machine but a kilobyte-scale reference in a blob store, and a wake is not a boot but a deserialization. This paper describes that runtime: the lifecycle it supports, the substrate measurements that make idle genuinely free, the density engineering that keeps tail latency flat as the awake fleet grows, the control plane the fleet story still requires, and the honest boundary of where a machine-based serverless runtime is still the better tool.

2. The serverless-agent lifecycle

A serverless agent is defined by four properties, which the field states consistently and which we adopt: scale-to-zero (an idle agent consumes no compute), hibernate-on-idle (its state is persisted and it is evicted after an idle budget), wake-on-request (a prompt, cron, or webhook reconstitutes it), and durable state (working directory, session, and history survive the sleep). The distinction from a persistent sandbox is precisely the first two: a persistent sandbox stays resident; a serverless agent is expected to disappear when idle and return on demand, indistinguishable to the caller except in latency. Figure 1 shows the cycle on a machine-free substrate.

3. A machine-free substrate

The runtime is built on Naïve Sandboxes, in which a sandbox is a V8 isolate with a content-addressed virtual filesystem and an emulated shell, and no guest kernel anywhere in the stack. Three properties of that substrate are what make the serverless lifecycle cheap at both ends, and each is measured on real server hardware (AWS m7i.8xlarge, 32 vCPU / 124 GB, isolated-vm backend).

Two of these are load-bearing for the serverless story specifically. Idle is storage, not a stopped machine. hibernate() serializes an agent to a StateRef of kilobytes, a filesystem manifest hash plus content-addressed blobs, not a memory image; the sleeping cost is the price of storing kilobytes. And the wake path is a fork, not a boot. Because a warm resume is an in-memory reconstruction and a cold one rebuilds from the blob store, wake latency is roughly 1 ms rather than the tens to thousands of milliseconds a machine boot costs. The substrate mechanics and their four-iteration benchmark history are the subject of a companion report and are used here as measured inputs.

4. The field: serverless agents on machines

The incumbents validate the lifecycle and mark the numbers to beat. Their shared design is worth drawing out, because it is genuinely good engineering and it is what a machine-free runtime must match on completeness while beating on constants. Figure 2 shows the common architecture; the figures in the text are the vendors' own reported numbers, from documentation and self-run benchmarks, and are labeled as such.

agentOS on Rivet Actors reaches its speed with three stacked tricks, none exotic: a shared, already-running sidecar so a new agent is an incremental tenant rather than a fresh process; V8 startup snapshots so each guest isolate is deserialized from a pre-evaluated heap image; and agent-SDK heap snapshotting so the SDK module graph is evaluated once per host and content-hash cached. It reports a 4.8 ms p50 cold start and about 22 MB marginal RSS for a shell agent. Each agent is a Rivet Actor that sleeps after an idle budget (RivetKit's default is 30 s idle; agentOS sets a 15-minute graceful window and a very long action timeout so a human permission review is never cut off) and persists working directory, session catalog, and completed history to per-agent SQLite over a local socket, waking a fresh VM on the next trigger. Rivet's control plane is designed to schedule zero to millions of concurrent actors by capacity.

Cloudflare Agents put each agent in a Durable Object on always-running Workers isolates; the WebSocket Hibernation API evicts an idle agent from memory while keeping its socket open and recreates it on the next message, within a 128 MB per-isolate cap. Its stated lifecycle, wake, load state, handle event, sleep, is the same one. Vercel Fluid Compute bills active CPU (about 0.128 dollars per active-CPU-hour plus 0.0106 per GB-hour) and shares compute across invocations so idle CPU inside a running function is free, advertising up to 90 percent savings for idle-heavy agent workloads; the isolation unit is still a function instance with a reserved memory floor.

The common design is a shared, always-warm host on which an agent is an incremental tenant, plus scale-to-zero with hibernate and wake. The common limitation is the machine: the marginal footprint is tens to hundreds of megabytes, a sleeping agent is a suspended or evicted machine, and a wake is a boot. agentOS is candid that its isolate boundary alone is not a hard security boundary and should be wrapped in an already-hardened environment such as Lambda or Cloud Run for internet-facing untrusted input, which is the same defense-in-depth posture the isolate substrate has.

5. Comparison

The lifecycle is the same; the constants are not. What we have actually run is 2,000 concurrent hot agents on one AWS m7i.8xlarge at a p99 execution latency of 37.5 ms, under an 8-second heartbeat across 16 pods on the isolated-vm backend, at about 1.2 MB per agent. At 4,000 the p99 rises to 73.8 ms and misses our 50 ms objective, so that is a tuning frontier we have not yet cleared rather than a headroom figure. The per-agent memory divides into a host's RAM to give a far larger number, and we are deliberately not quoting it: RAM is not the binding constraint at that scale, and a density we have not sustained under an SLO is arithmetic rather than a result.

6. Holding tail latency under fleet load

Cheap per-agent lifecycle is necessary but not sufficient. A serverless host runs many awake agents at once, and the number that decides whether the density is real is the exec p99 under load, not the median in isolation. The pattern the field converged on, and the one the substrate uses, is a reactor split: one shared, fixed-worker asynchronous runtime handles all I/O as tasks, guest execution runs on separate bounded, thread-affine executors, and readiness is delivered by coalesced, capacity-one wakes with a revision or epoch counter to kill races, bounded completion queues, and real backpressure. This is precisely engineered to keep p99 flat as the awake count rises. On the substrate, replacing synchronous isolate calls with asynchronous dispatch across pods took exec p99 under heartbeat load from hundreds of milliseconds to 37.5 ms at 2,000 concurrent agents, under a 50 ms target; the remaining work is holding the same bar at 4,000 and beyond, where p99 is 73.8 ms today. The point for serverless is that idle economics do not help if waking a thousand agents at once melts the tail, so the density number always travels with the SLO it was held under.

7. The fleet control plane

A cheap lifecycle per agent still needs a control plane to be serverless at the scale of millions of agents. The substrate delivers the per-agent primitives today, create, hibernate, resume, fork, and durable content-addressed state. The fleet layer is design and adoption in progress rather than a measured result, and we mark it as such. Figure 3 sketches it.

Migrating state by reference is the one place the machine-free model is strictly easier than the incumbents' rather than merely cheaper: because a hibernated agent is a content-addressed reference, moving an agent between hosts is moving a hash and lazily faulting in blobs, not shipping a memory image or a VM disk. Speaking the agent-native wire protocols (a durable public session identity with lazy restore, and the tool protocol) is what makes the runtime a drop-in for the same agents the incumbents court.

8. What this runtime is for, and what it is not

The machine-free serverless runtime is the right tool for massive fleets of long-lived, mostly-idle agents, per-user agent profiles, event-waiters, cron-for-prompts, where idle cost dominates the bill and must be storage rather than compute, and for orchestration that creates, forks, and resumes constantly, where 2 ms create, 1.5 ms fork, and 1 ms resume make parallel exploration casual. It is not the right tool for a workload that needs arbitrary native binaries and a full Linux userland resident inside the sandbox, native compiler toolchains as the primary job, in-sandbox services, or headless browsers; those are served by a metered burst tier or by a machine-based sandbox that runs them natively. Honesty on isolation is part of the position: the isolate boundary is defense-in-depth, not a hard boundary, so the model offers an optional hardware-isolation escalation tier the pure-isolate incumbents lack and states which tier is hardware-backed rather than claiming a boundary the isolate cannot deliver. The serverless regime, a fleet of mostly-idle agents that must wake cheaply and cost nothing asleep, is where removing the machine is uncontested.

9. Conclusion

The serverless-agent category has settled on the right lifecycle, scale-to-zero, hibernate-on-idle, wake-on-request, durable state, and then implemented it on machines, so idle is a stopped machine and a wake is a boot. Building the same lifecycle on a V8-isolate substrate changes the constants: an idle agent is a kilobyte-scale reference rather than reserved memory, a wake is a 1 ms deserialization, a create is 2.3 ms, and a resident agent is 1.2 MB, one to three orders of magnitude below the machine-based runtimes' own reported figures. The per-agent lifecycle and the density under load are measured and in hand; the fleet control plane, addressing, wake sources, and cross-host scheduling, is the work ahead. The thesis is simple: idle-time-is-free is a much stronger promise when idle time is not a machine.

References

1. Naïve Research. Sandboxes Without Machines: a V8-isolate runtime for massive fleets of resident agents. usenaive.ai/lab, July 2026.
2. Rivet. agentOS: architecture, benchmarks, and persistence (sleep/wake, SQLite over UDS, agent-SDK snapshots). github.com/rivet-dev/agentos and rivet.dev/docs, accessed July 2026.
3. Rivet. Actors: zero to millions of concurrent actors, capacity scheduling, hibernation, and wake. rivet.dev/actors, accessed July 2026.
4. Cloudflare. Agents on Durable Objects and the WebSocket Hibernation API. developers.cloudflare.com/agents and blog.cloudflare.com/project-think, accessed July 2026.
5. Vercel. Introducing Active-CPU pricing for Fluid Compute; Fluid: how we built serverless servers. vercel.com/blog, accessed July 2026.
6. Agent Client Protocol. ACP: the agent wire protocol. agentclientprotocol.com, accessed July 2026.
7. Agache, A. et al. Firecracker: lightweight virtualization for serverless applications. NSDI 2020.