Sleeping agent fleets are cheap. Waking them must be fast.

Kendall Clark · Pentad Labs · 14 September 2026 ·PLRN-026

Abstract

Unix systems measure fork() performance because process creation is an operating-system primitive, not an incidental property of an application. Agent lifecycle performance belongs to the same class, particularly at fleet scale. An operating system for enterprise agents should optimize how many agents it can register, reactivate, and spawn per second.

But this metric isn’t just process count alone. A process is cheap, but an agent owns more than a process. In WunderOS an agent includes storage, indexes, arenas, and a microVM supervised runtime. We will see below that WunderOS integration of agent state, storage, and runtime has performance implications.

This gives an agent OS two populations:

1. Agent lifecycle operations: register, wake, spawn

A WunderOS node can support a large durable population only if these populations can differ. The distinction also divides WunderOS booting into distinct operations:

  1. Register / restore reconstructs durable identity, contract, routing, and residency metadata after a node restart. It allocates no cognitive context.
  2. Reactivate / wake moves a registered dormant tenant into the active set. It allocates the cognitive context, attaches storage, restores durable state, starts the tenant subtree, and reaches ready-for-turn state.
  3. Spawn / provision creates a new tenant, its durable identity and binding, its first active subtree, and a ready routing target.

Each operation has its own throughput, measured in completed lifecycle operations per second.

These operations have different preconditions and failure meanings. Their rates cannot be combined into one useful boot measurement. A node must report registers, reactivations, and spawns per second separately.

2. Registration changes the scale of restart

WunderOS restores each durable non-system tenant as a dormant registration. Warden rebuilds the authoritative identity and routing relation, records the tenant as registered, but doesn’t allocate its CognitiveContext or its context-owning children.

Register throughput across increasing durable populations, measured in completed registrations per second.

At 5,000 durable tenants, restart completes about 11,800 registrations per second. Throughput rises roughly in the batch size because fixed node startup dominates the measured interval. This does not prove a zero-cost registry. It shows that durable population no longer implies active-context allocation during restart. Registration is not a sleeping process with an expensive heap still attached. It is a durable address, a contract, a route, and a residency state. The system knows who the tenant is and where a waking request must go, without pretending that the tenant is already awake.

3. Waking and spawning are concurrent operations

A dormant agent already has an identity, a contract, and durable state. Waking it restores the resources that the agent needs to run. Spawning starts from a shared template, creates a new identity, and adds the agent’s private state.

In enterprise-scale fleets, with multi-tenant placement, different agents can wake or spawn at the same time. Requests for one dormant agent share a single wake operation. That is, if several requests reach the same sleeping agent simultaneously, WunderOS wakes that agent once. All those requests wait for the same wake to finish. Requests for different agents can still wake concurrently. This rule prevents duplicate active agents without serializing work across the whole fleet.

Wake-ready and template-based spawn-ready throughput for isolated requests and measured high-concurrency bursts.

At concurrency 192, wake-ready reached 164.1 operations per second. At concurrency 256, spawn-ready reached 215.5 operations per second. In isolation, wake-ready p50 latency was 86 ms and p50 spawn-ready 141 ms.

Concurrency increased total throughput because independent lifecycle work overlapped. The increase was not free. Each request competed for storage, memory bandwidth, execution sessions, and the other finite resources of one node.

4. Ready means ready for a turn

Many infrastructure measurements stop when a microVM starts. That boundary is useful, but an agent cannot run a turn at that point. These measurements stop when the agent has a runnable execution session, that is, its next action may be a turn, tool call, etc. Wake-ready and spawn-ready here are ready for work.

Wake-ready includes the resolution of an existing run-place and restoration of its execution session. Spawn-ready includes placement of a new run-place and acquisition of its execution session. That is, these metrics include microVM lifecycle operations and are, thus, only comparable to other sandbox or run-place systems performance claims when those are also inclusive of agent state, storage, and include readiness for work.

Median and ninety-ninth percentile latency for isolated and high-concurrency wake-ready and template-based spawn-ready operations.

Under concurrent load, individual operations took longer. The width-192 wake burst had a p50 of 781 milliseconds and a p99 of 1.05 seconds. The width-256 spawn burst had a p50 of 800 milliseconds and a p99 of 1.19 seconds.

We use latency and throughput here with their usual senses. Throughput states how much work the WunderOS node completed. Latency states how long one agent waited while a WunderOS node served the fleet.

5. Capacity has two numbers

The durable population and the active population are different quantities. A node can know about thousands of agents without keeping thousands of cognitive contexts in memory. That maintenance and avoidance of memory pressure, as well as other resources, at fleet-scale is the benefit of WunderOS agent-sleep capability, patterned, of course, on the way an operating system for non-agent users and applications manages system resources of sleeping processes and apps.

An active agent owns private mutable state. The system shares immutable model, tokenizer, and inference resources across active agents; but it does not share each agent’s private working state. In the measured case, sharing the immutable resources reduced the added memory per active agent by about 75%.

The measured active-memory cost remains approximately linear. The tests support an active population in the hundreds on the relatively modest test node (16-core, 32-thread AMD with 96 GB RAM). They will support thousands of simultaneously active agents on suitably resourced nodes, though that remains to be shown, not just extrapolated.

When the active set reaches its limit, another dormant agent remains dormant. Memory-pressure handling can hibernate inactive agents separately. This separation keeps one agent’s wake latency independent of another agent’s hibernation cost.

6. What the measurements establish

The tests cover registry recovery, tenant-correct routing, lazy wake, capacity refusal, concurrent spawn, and concurrent wake. They also cover repeated requests for one agent, agent failure, and isolation of dormant peers.

The p99 results describe the measured samples. They do not characterize p999 or rarer events. Further work is necessary before making claims about the distribution’s longest tail.

7. Why BEAM/OTP belongs here

A founding wager of WunderOS system design is that, at enterprise scale, the traffic of an agent fleet resembles the traffic of a large chat system. Both systems have many durable identities, many idle participants, long-lived sessions, supernodes and hot spots, and bursts of messages addressed to particular recipients.

WhatsApp built its server infrastructure on Erlang and BEAM. Discord built its original infrastructure in Elixir on the same virtual machine. Discord assigned each connected user a process and each server another process. Those systems made concurrency part of the application model rather than a pool around it.

WunderOS makes the same wager for agents. Each agent has isolated control state and a mailbox. BEAM schedules runnable processes across cores, while OTP supervises their failures and restarts. A sleeping agent need not consume a thread while it waits for a message, timer, approval, tool, or person.

The analogy has a limit. An agent owns more state than a chat connection, requiring both private storage and a microVM. BEAM coordinates those resources. That doesn’t make their physical costs disappear.

The lifecycle results show part of the value. Hundreds of wake and spawn operations can make progress concurrently without one fleet-wide execution queue. These measurements do not isolate BEAM from every other design. They establish that the concurrency model remains effective when an agent carries more state than a chat session. Further measurements will cover sustained traffic, failure, distribution across nodes, and longer latency tails.

8. The analogue is fork() performance

Unix systems measure fork() because process creation is both an interface and a systems operation. The result depends on how the operating system represents identity, memory, and execution state. Copy-on-write made fork() cheaper by separating logical creation from immediate physical copying. A child process existed before it copied every page that it can later change. The logical population and the private resident population were therefore different.

WunderOS applies the same separation to different objects. Register creates durable addressability without active cognition. Wake creates an execution context for an existing agent. Spawn creates both a durable identity and an execution context.

WunderOS shares an immutable cognitive base across active agents. A wake or spawn still creates a mutable overlay and attaches private storage. This design resembles copy-on-write in purpose, but it is not copy-on-write memory.

9. Lifecycle scalability is an OS metric

An agent OS must answer two capacity questions.

  1. Carrying capacity: how many durable agents can the node address?
  2. Active-set capacity: How many agents can the node keep ready for turns?

Register throughput measures recovery of the durable population. Wake throughput measures movement into the active population. Spawn throughput measures growth of both populations at once. These rates need population and concurrency context. A wake rate without the registered population is ambiguous. A spawn rate without the residency budget says little about sustained capacity.

Latency percentiles answer the agent’s question: how long did this operation take? Operations per second answer the node’s question: how much lifecycle work did the system complete?

In WunderOS, an agent can exist without being awake. Once an agent OS represents that fact directly, node restart becomes recovery of addresses rather than compulsory thought by every agent at once.

The POSIX specification for fork() defines the process-creation interface. The Linux fork(2) manual describes its copy-on-write implementation and cost. Agache et al., “Firecracker: Lightweight Virtualization for Serverless Applications”, describe the microVM system used as WunderOS run-place.

Rick Reed’s WhatsApp presentation, “That’s ‘Billion’ with a ‘B’”, describes its Erlang and FreeBSD server infrastructure. Discord’s engineering account, “How Discord Scaled Elixir to 5,000,000 Concurrent Users”, describes its process-per-session and process-per-server design. The Erlang documentation covers lightweight processes and scheduling and OTP supervision trees.

Autonomic WunderOS gives the larger account of agents as long-lived, supervised processes. PlatypusDB describes the durable state that survives while an agent sleeps. Model Minimalism explains why immutable model resources belong below individual agent contexts.

A note on method

Written in conversation with OpenAI Codex as structured interlocutor, measurement assistant, and prose editor. The ideas, claims, priorities, and architectural commitments are mine.

Kendall Clark · k@pentad.ai
Great Falls, Virginia
14 September 2026