Agent Activity Profiles and Their Infrastructure Cost Implications

An agent’s activity profile determines which infrastructure model makes it economical to run. Snapshot-restore scheduling saves an idle AI agent’s execution state to durable storage and stops compute until work returns, when it restores the agent, so there is no idle compute cost. The right configuration depends on both the time between bursts and the compute depth within them, with persistent state preserving the value of each wake.

Why the billing unit you choose determines whether agent economics work

Infrastructure first faces an economic mismatch. An agent that spends most of its time waiting still accumulates charges if it occupies a per-hour reserved slot. Even a low hourly price can lead to poor unit economics when the bill grows before the agent runs any useful business logic. Both the amount of compute an agent uses and the shape of that usage matter.

The inverse mismatch appears when intense, intermittent tasks run on a per-request serverless model. Cold starts and context reloads add a tax to each burst, making the effective cost of active work higher than the request price suggests. Infrastructure selection must account for both paid waiting and repeated initialization. Flat-rate per-agent pricing, such as Maritime’s model, offers an alternative to per-hour slots by matching the billing unit more closely to persistent agents with intermittent activity. That distinction makes workload structure the starting point for infrastructure selection.

The four activity profile types that cover nearly all production agents

Four profiles provide a practical working vocabulary for production agents. They describe two dimensions, which are the ratio of active time to idle time and the compute depth of active bursts. A system may change profile over time or run agents with different profiles concurrently.

Bursty-shallow agents do brief, lightweight work, with idle time between tasks. Bursty-deep agents also pause between tasks, but when they work, they do deeper planning, tool use, and context processing. Both expose the cost of keeping compute available while nothing happens. Their difference becomes important when the agent wakes and needs resources.

Sustained-active agents execute continuously or nearly continuously, as with a real-time monitoring agent or a pipeline worker processing a queue. Scheduled-batch agents run at known intervals, such as a data-extraction agent on a cron schedule, with hard idle periods between runs. The surface description of a task does not determine its profile because planning, acting, observing, and revising form a layered execution loop. An orchestrator can also trigger workers with different profiles, so the combined cost includes the top-level agent and every worker.

How idle time becomes the dominant cost driver for most agent deployments

Per-session harness pricing shows how those idle costs build up. An agent that waits for human approval takes up a slot even though it does no useful computation. The same can happen while it waits for a slow tool response or the next user interaction. If billing follows slot occupancy, every such pause extends the bill.

In a mostly idle fleet, those gaps make up most of the infrastructure bill. Each agent may appear inexpensive in isolation, but every reserved slot continues accumulating cost between interactions. A long wait need not involve any additional work to become expensive. That is why reducing active execution time alone does not resolve the economics of a bursty deployment.

Durable execution changes the treatment of a pause. When a task waits on a tool, a human gate, or a timer, its execution state can be snapshotted to durable storage and its process terminated. Compute cost then drops to zero during the wait, with execution restored when the trigger fires. Checkpointing is therefore more than a fault-tolerance mechanism.

Why burst intensity, not just burst frequency, changes the infrastructure requirement

Eliminating paid waiting solves only one dimension of the problem. A single tool call and a planning step followed by parallel tool calls, reflection, and summarization are structurally different compute events. Both may sit idle for the same length of time, but the second needs more resources when it runs. Planning, reflection, and multi-agent orchestration are therefore cost multipliers as well as architectural choices. Their resource demand must be pre-allocated or provisioned dynamically.

The internal work of a task can deepen a burst further. Retries and context maintenance extend tool-call chains, while mid-conversation summarization invalidates the KV cache and spikes latency. Memory demand also changes when an agent begins with a lightweight context and receives a large document mid-session. A fixed allocation either reserves memory that often goes unused or imposes a ceiling when the task becomes demanding.

Dynamic memory provisioning addresses this variability by letting an agent start small and expand as complexity grows. It requires isolated, elastically configurable resources rather than a shared container with fixed memory limits. Without that capacity, infrastructure suited to bursty-shallow work may truncate context or run out of memory on a bursty-deep task. Measuring only burst frequency would miss that risk.

What isolation level each profile actually requires from its compute environment

The isolation an agent needs depends on what it does when it runs as well as how often it runs. Bursty-deep and sustained-active agents may install packages, manage credentials, run browser sessions, and run untrusted code. Those operations call for a kernel boundary. A shallow interaction or scheduled run does not establish the same requirement by its timing alone. Its execution behavior still determines the boundary it needs.

The one-session/one-VM pattern gives a bursty-deep task its own micro-VM and kernel. That boundary keeps a session’s failures and resource spikes from affecting nearby sessions, while session teardown removes the temporary execution environment. With each agent in its own isolated micro-VM, as in Maritime’s model, burst intensity becomes a matter of allocating resources rather than competing inside a shared container or serverless slot. An agent can saturate its assigned compute without consuming a neighbor’s allocation.

Firecracker has KVM-based hardware isolation, sub-125ms boot times, and very little per-VM memory overhead, so this boundary works well even for short sessions. Its GPU constraint remains significant because it has no PCI bus or VFIO device assignment mechanism and does not support device passthrough. GPU-intensive agents need that constraint reflected in infrastructure selection. Network egress controls are also required because VM isolation alone does not prevent access to internal metadata services or unauthorized external APIs.

How do you stop paying for compute while AI agents sit idle

Snapshot-restore scheduling replaces a running but inactive VM with a durable record of its state. Memory, disk, and pending continuations are saved, the process terminates, and only storage resources remain in use until the next task. The scheduling rule is snapshot on idle and restore on demand. For bursty-shallow and bursty-deep agents, this directly targets the intervals that reserved-slot billing makes expensive.

The cost shifts from reserved compute for the whole fleet to storage for each agent and compute only while it is active. Thousands of isolated agents become viable because most do not need running compute at the same moment. Their idle periods carry a near-zero storage cost. Storage is not literally free, but sleeping no longer requires a live process.

Maritime implements this through a snapshot-restore scheduler that parks idle guests on disk and restores them when work returns. Its customers pay for flat plans instead of switching between metered storage and compute charges, so the savings let it offer predictable per-agent pricing. State continuity is integral to that mechanism. Keeping installed packages, credentials, browser session state, and conversation memory lets the restored agent pick up where it left off without rebuilding the environment it had before suspension.

Matching each activity profile to its cost-optimal infrastructure configuration

For bursty-shallow agents, the appropriate configuration is a per-user persistent VM with aggressive snapshot scheduling. The VM should wake in under a second, handle the interaction, and return to snapshot immediately, including after short active periods. A warm-pool reserved slot is the wrong fit when it keeps the process running between interactions.

For bursty-deep agents, snapshot-restore must be paired with dynamic memory allocation. The VM should begin with a baseline memory footprint and expand as task complexity requires, then snapshot and release compute resources when the burst ends. Human-in-the-loop tasks also need suspension at approval gates. Waiting for a decision should not reserve the resources needed to execute it.

For sustained-active agents, reserved compute makes sense. There is little idle time to recover, so frequent snapshotting would add resume latency without enough savings. The main task is right-sizing compute to actual intensity. For continuously running multi-agent pipelines, orchestration efficiency is the stronger cost lever.

For scheduled-batch agents, pre-warmed VM pools should come up just before the scheduled burst and snapshot immediately afterward. Knowing when the next burst will start allows pre-boot while the pool stays off for the rest of the gap. These long, known idle periods are the clearest case for storage-only billing between bursts.

Why persistent state is not optional for bursty agents, and what it costs to skip it

The matching framework assumes that suspension preserves the agent. With Snapshot-restore but no persistent state, an agent has to rebuild installed packages, credentials, conversation history, and mid-task context every time it wakes. A fast VM restore helps little if the application then has to do its initialization work again. The compute charge has moved from the idle interval into the next burst.

Disk continuity is therefore an architectural requirement. Each agent needs a persistent block device whose state survives snapshot and restore. A temporary session VM and a long-lived agent also have different lifecycle needs.

Long-lived agents have two distinct memory layers, which are session state and cross-session memory. Session state holds the current task’s working buffer, tool outputs, and reasoning steps, while cross-session memory holds user preferences, past outcomes, and domain knowledge. Losing session state forces a task restart. Losing cross-session memory stops an agent from personalizing its work or learning from past failures, which limits what it can do even if it does not crash.

How activity profile analysis changes the economics of deploying agents at per-user scale

Giving every user a persistent, isolated agent requires a different cost model from giving every user an always-on process. Without profile-aware scheduling, a mostly idle fleet incurs the compute cost of an equally large active fleet. With it, the compute requirement follows active agents, while sleeping agents retain their state in storage. The economic change is from cost per agent per hour to cost per active minute plus a small ongoing storage cost.

That distinction also separates the resource model from the customer’s bill. A provider can use snapshot scheduling to cut idle costs and offer flat per-agent plans instead of charging for each switch between resources. Persistent disks, isolated micro-VMs, and idle-aware scheduling are the architectural features that support this arrangement. None substitutes for understanding how the agents actually behave.

Accurate profiling requires VM-level observability of per-agent active time, burst frequency, burst depth, and idle duration. Fleet averages obscure the power-law distribution of activity across users and encourage over-provisioning for the median user. Before choosing infrastructure, measure the active-to-idle ratio across a representative sample of sessions and the compute depth of their active bursts. Use those measurements to select the billing and compute model, rather than treating general benchmarks or vendor pricing sheets as substitutes for the workload.