Package Installation and Runtime Customization in Agent VMs

Package installation and runtime customization in agent VMs require an environment that can change safely while an agent works. Firecracker micro-VM isolation for AI agents provides each agent with its own guest kernel through Linux KVM, rather than sharing the host kernel as application containers do. That isolation must work with persistent storage, controlled network access, and fast snapshot-restore so agents can install what their tasks need without keeping idle compute running.

Why agent VMs require a different mental model than application containers

Application containers encode a software stack at build time. A frozen dependency graph is useful for a web service whose libraries and processes are known before deployment. A coding agent may discover that it needs a specific linter, a browser driver, or a system-level library that the developer had no reason to include in the original image.

The range of possible environments also changes with the work. A lightweight data-analysis agent may need little beyond Python and minimal memory, while a coding agent may require Git, background processes, exposed ports, and a full Linux environment. These environments must accommodate requirements that were unknown when the image was built. For agents, that capacity is fundamentally a runtime property.

What real runtime mutability actually requires from the underlying VM

Runtime mutability requires privileges inside a boundary that the agent does not control. Root access belongs inside the VM, so package installation and system changes remain confined to the agent’s environment. A persistent disk preserves installed packages between sessions. A real guest kernel lets the agent use packages with kernel modules, system libraries, and low-level binaries, giving it more than a narrow set of application dependencies.

The environment also needs controlled access to the outside world. Package managers must reach dependency sources, but host-level controls must decide which destinations are reachable. With background processes, exposed ports, and Docker execution inside the VM, the environment can do more than a command runner. These are ordinary requirements for substantial development work. An agent can complete a task when the required operations are available, but must stop when it encounters an unsupported operation.

Isolation must therefore be built to handle arbitrary code execution. Shared-kernel containers generally provide an insufficient boundary for hostile or user-supplied code because guest workloads still depend on the host kernel. Stronger options include microVMs and hardened user-space kernels, with different approaches to separating workloads from that kernel. For a VM intended to support unrestricted package installation and low-level operations, the guest kernel is a defining requirement. The architecture choice is both a security choice and a performance choice.

The two design patterns for handling package installation in agent VMs

Template-and-clone sets up an environment for a broad range of work before an agent starts. The sylvinus/agent-vm project builds a Debian 13 VM with development tools, Docker, Chromium, and agents, then stops it and retains it as a base template. Running an agent in a directory clones that template into a persistent VM keyed to the path and mounts the working directory. Runtime scripts apply user-level customization before project-level customization. This reduces repeated setup, but coverage has a cost. A richer template produces a larger snapshot and a slower first clone, while a smaller one leaves more installation work for runtime.

The ag2ai AgentVM project uses bake_actions.sh to pre-install actions, Python packages, and other dependencies into Ubuntu.actions.qcow2. Each action is an independent module with dependencies in a separate Python venv, and actions can be added as MCPs. With known action sets, the environments behave as expected and start fast. But changing those sets takes another bake step, so this pattern is less suited to ad hoc or user-driven installation.

Both patterns still need conventional installation work at some point in the lifecycle. The agentOS package system offers a distinct alternative within its own ecosystem, where installation needs only a path to an .aospkg file, without tar extraction, filesystem writes, or scripts. As of October 2026, its software has moved from npm to the agentOS registry. That removes the filesystem-write bottleneck for supported packages. Outside that registry, conventional installation paths remain necessary, so dependency predictability still determines how much preparation can replace runtime work.

Why snapshot-restore is becoming an agent reasoning primitive, not just an ops convenience

Fast checkpoint-restore changes how agents explore possible solutions. An agent can preserve an environment, attempt a change, and return to the earlier state before taking another branch. At millisecond scale, this becomes part of how the agent reasons as well as how it recovers. DeltaBox, from Shanghai Jiao Tong University, frames checkpoint-restore this way for exploration-heavy workloads such as MCTS on a software engineering benchmark. Its paper, arXiv:2605.22781, was submitted in May 2026.

DeltaBox separates filesystem changes from process-state changes. DeltaFS organizes file states into layers, freezes the writable layer during a checkpoint, and inserts a new one so subsequent file updates use copy-on-write. Rollback becomes a layer switch. DeltaCR uses incremental process-state dumps and accelerates rollback by calling fork() directly from a frozen template process.

The performance claim depends on what changes between checkpoints. Small differences favor incremental work. Large-file changes and high memory churn may not. The paper’s abstract does not provide delta sizes, change ratios, or memory churn statistics to establish that assumption, although that limitation should not be mistaken for an absence of measurements in the paper’s body. Millisecond checkpointing is therefore a workload-dependent engineering claim. The delta-box/deltabox-lite project exposes similar diff/commit/abort semantics using FUSE on Linux and APFS clones and FSEvents on macOS, illustrating how the exploration model can extend beyond one implementation.

The economics of idle compute and why snapshot-and-delete is the right default for agent fleets

Agent workloads often alternate short bursts of work with waits for a user or a model. Keeping a VM warm throughout those waits makes elapsed time, rather than useful computation, the basis of its compute cost. At fleet scale, that distinction becomes expensive. An environment can spend most of its billed lifetime ready to work rather than working, even when its actual tasks are brief.

Snapshot-and-delete separates continuity from running compute. Once state is captured, the VM can be destroyed and the host capacity freed, with the environment recreated in well under a second when the next request arrives. No idle VM remains to incur compute charges. Storage still has a cost, but preserving state no longer requires keeping its execution environment alive.

The self-hosting arithmetic shows why this is the right default for intermittently active fleets. On the same server, keeping every agent warm instead of snapshotting all but the active fraction can produce an order-of-magnitude difference in per-user cost. A two-gigabyte memory snapshot in object storage costs a negligible amount per month compared with the compute cost of leaving the corresponding VM idle over that period. The benefit depends on cheap, fast restoration. Without it, a platform remains tied to always-on capacity or imposes a restart delay that interrupts the user’s workflow.

What runtime isolation must handle when running untrusted AI agents in production

Arbitrary package installation turns dependency code into part of the threat model. An unvetted package may execute with root privileges inside the environment, so the design must assume that code could be hostile. Firecracker runs in user space and uses Linux KVM to create microVMs, each with its own guest kernel. Its one-VMM-per-microVM design makes the microVM the isolation unit. Compromising a guest kernel is not the same as compromising the shared host kernel, although hardware-backed isolation does not replace controls on network access or host-facing files.

The agent-vm project illustrates those additional controls. By default, a VM cannot reach the internet, host machine, or local network, and internet access requires --allow-internet-egress. The host-side network stack enforces this restriction, beyond the authority of root inside the VM. A global allowlist in ~/.agent-vm/network opens specific addresses, ports, or domains. Domain entries allow internet access only to the named hosts and their subdomains.

Host execution hooks create a separate route across the boundary. Files such as .envrc, .vscode/tasks.json, and .pre-commit-config.yaml can cause host-side tools to execute agent-written code. The project guards writes to these files with a confirmation dialog and refuses the write when confirmation cannot be shown. Microsoft MXC, launched at Build 2026, illustrates a policy-as-code approach instead. Its declarative JSON ContainerRequest specifies permitted files, network directions, and UI capabilities before execution, while SDK 1.0.1, current as of October 2026, supports backends ranging from process sandboxes to full VMs selected by threat model.

What the developer tooling layer must provide for runtime-mutable agents

Developers need to use these capabilities without having to manage every change to the environment by hand. The tooling layer must expose lifecycle operations, customization hooks, and deployment in a form that fits an agent workflow. Installation footprint is one practical constraint. SDK language, runtime dependencies, and the amount of infrastructure exposed to the developer determine how readily a team can adopt the underlying architecture.

The Sandbox Agent SDK takes a lightweight approach. It is a static binary with no runtime dependencies and can be installed wherever a Linux binary can execute. MXC’s SDK makes a different tradeoff by bundling native runtime assets for each platform, exceeding 100 MB unpacked. Its Node SDK requires Node.js 24 or later, while Rust and.NET SDKs are also available. The heavier installation supports a unified cross-platform policy interface rather than minimizing the tooling’s own dependency footprint.

Google Cloud’s Agent Runtime uses managed infrastructure to take on more of the work. It supports build-time system-dependency scripts and deployment from a container image or Dockerfile, with an Agents CLI, pre-built templates, Cloud Build pipelines, and observability through Cloud Trace and Cloud Logging. Managed templates support LangChain, LangGraph, AG2, LlamaIndex, and ADK, while CrewAI and custom frameworks use a runtime contract. By contrast, agent-vm exposes six customization hooks, comprising two environment files and four shell scripts scoped globally or to individual projects. Those hooks compose user and project environments without rebuilding the base template.

These approaches expose different levels of control and responsibility. A managed build-and-deploy interface, a cross-platform policy layer, and local customization hooks address different parts of the workflow. Tooling can simplify the architecture, but it cannot substitute for it. The right choice depends on what the team needs from isolation and the lifecycle, including where mutation takes place and how state is kept through suspension.

Putting it together — the infrastructure properties that make a VM genuinely agent-native

An agent-native VM joins capabilities that are incomplete in isolation. Its own kernel and root privileges let an agent install, break, and rebuild software without granting authority over the host. Persistent disk state preserves packages, files, credentials, and intermediate work across sleep and redeploy. Fast restoration lets that state carry over while compute capacity is freed. Explicit network allowlists and filesystem guards constrain the paths through which a mutable environment can affect systems outside it.

Persistence does not require an always-running machine. With snapshot-restore under one second, a suspended agent can retain its working environment while its idle cost shifts from compute to storage. Millisecond checkpointing can additionally support branching exploration where the workload’s change patterns permit it. These serve related but distinct purposes.

For persistent agent products, this leads to one VM per user. Each user gets an isolated space that keeps installed software and state across sessions, without tying up dedicated compute through every pause. Purpose-built infrastructure around Firecracker micro-VMs and snapshot-restore scheduling addresses that combination directly. Teams building agent-native products need all of these pieces together, beyond what a static application environment with broader permissions can offer.