Long-running AI agents expose a deployment problem that serverless functions and containers don’t solve well. An agent refactoring a codebase might run for six hours. Another might wait days for human approval before resuming. Traditional sandboxes either time out (Lambda’s 15-minute limit), leak state across tenants (shared Docker hosts), or burn money on idle VMs.
Superserve uses Firecracker microVMs (the same tech behind AWS Lambda and Fargate) to give each agent its own kernel-isolated computer that can pause indefinitely, snapshot mid-execution, and resume exactly where it stopped. This is infrastructure purpose-built for workloads that need mutable filesystems, arbitrary package installs, and multi-hour execution windows.
The Isolation Problem
Containers share a kernel. If an agent installs a malicious npm package or spawns a crypto miner, you’re trusting cgroups and namespaces to contain the blast radius. That works for short-lived functions but gets risky when agents run bash scripts, install system dependencies, or execute LLM-generated code for hours.
Firecracker gives each agent a dedicated kernel. No shared memory, no cross-tenant syscall surface. The hypervisor enforces isolation at the hardware level. Boot time is ~125ms with ~5MB overhead per VM, so you can spin up hundreds of isolated environments without the cost profile of EC2 instances.
Key boundaries:
- Each agent gets its own Linux kernel and root filesystem
- Network egress goes through a credentials broker (agents never hold API keys directly)
- Filesystem writes persist to snapshots, not the host
- No shared /tmp, /proc, or kernel modules across tenants
State Persistence Model
The core primitive is snapshot-pause-resume. When an agent hits a breakpoint (waiting for user input, long-running build step, rate limit), the platform snapshots the entire VM state (memory, disk, network stack) and deallocates the compute. Resume is instant because you’re loading a memory image, not cold-booting a container.
Workflow example:
- Agent starts in a fresh microVM, installs dependencies, begins refactoring
- Hits a point where it needs human review of proposed changes
- Platform snapshots VM state (filesystem + memory) to object storage
- VM is paused, compute resources freed
- Human approves changes three days later
- Platform restores snapshot, agent resumes from exact same instruction pointer
This is different from checkpointing a process. You’re freezing the entire kernel, so open file handles, network sockets, and in-memory state all survive the pause. The agent doesn’t know it was suspended.
Architecture: Harness Outside, Execution Inside
Superserve separates orchestration from execution. Your agent harness (the loop that calls the LLM, parses tool calls, decides next steps) runs outside the microVM. Tool execution and code generation happen inside.
// Harness runs in your infrastructure
import { Sandbox } from "@superserve/sdk"
const sbx = await Sandbox.create({
name: "refactor-agent",
template: "node-20-python-3.11"
})
// Agent decides it needs to run tests
await sbx.commands.run("npm test")
// Agent generates a Python script
await sbx.files.write("/tmp/analyze.py", llmGeneratedCode)
await sbx.commands.run("python /tmp/analyze.py")
// Pause before expensive operation
await sbx.pause()
// Resume hours later when budget allows
await sbx.resume()
const result = await sbx.commands.run("npm run build")The SDK talks to the Firecracker control plane over gRPC. Commands execute inside the VM via a guest agent. Stdout/stderr stream back to the harness in real time.
Why this split matters:
- Harness can be stateless (just decision logic)
- Execution environment is fully mutable (agent can
apt install, modify system files) - You can swap harnesses without losing agent state
- Observability stays outside the sandbox (no agent code can tamper with logs)
Resource Limits and Cost Control
Each microVM gets CPU and memory quotas enforced by the hypervisor. Unlike containers where a runaway process can steal CPU from neighbors, Firecracker hard-limits each VM. If an agent spawns a fork bomb, it only kills its own kernel.
| Resource | Limit Mechanism | Failure Mode |
|---|---|---|
| CPU | vCPU allocation (1-8 cores typical) | Agent slows down, doesn’t affect other VMs |
| Memory | Hard cap at VM creation (512MB-16GB) | OOM kills the VM, snapshot preserved |
| Disk | Overlay filesystem with quota | Write fails, agent sees ENOSPC |
| Network | Rate limit + egress filtering | Connection refused, no credential leak |
| Time | Pause after idle threshold | Compute stops, state persists to S3 |
Paused VMs cost only storage (pennies per GB-month). Active VMs bill by vCPU-second. This makes long-running agents economically viable because you’re not paying for idle time between LLM calls or human approvals.
Network and Credential Isolation
Agents should never possess credentials. Superserve’s broker sits between the VM and external APIs. When an agent needs to call GitHub or Stripe, it makes a request to the broker with a scoped intent (“clone this repo”, “create this invoice”). The broker validates the request, injects the real credential, and proxies the call.
Broker flow:
- Agent inside VM calls
http://broker.internal/github/clone?repo=user/project - Broker checks agent’s permission scope (defined at VM creation)
- Broker injects GitHub token, makes real API call
- Response streams back to agent, token never enters the VM
This prevents credential exfiltration even if the agent is compromised. The VM’s network stack can’t reach the internet directly. All egress goes through the broker, which logs every call for audit.
Observability Extraction
Logs and traces must leave the VM without giving the agent a side channel to leak data. Superserve runs a read-only agent inside each VM that tails stdout, stderr, and structured logs, then ships them to the control plane over a unidirectional gRPC stream.
The agent inside the VM can’t write to this stream (it’s mounted read-only). It can’t see other VMs’ logs. The control plane aggregates logs by tenant and exposes them via the SDK or a web UI.
Trace data includes:
- Command execution timeline (start, end, exit code)
- File writes (path, size, checksum)
- Network calls (destination, status, latency)
- Snapshot events (when, size, restore time)
This gives you full visibility into what the agent did without trusting the agent to report honestly.
Cold Start vs. Resume Performance
Firecracker boots a minimal kernel in ~125ms. If you’re starting from a template (pre-installed packages, cached dependencies), total time to first command execution is under 500ms. That’s fast enough for interactive agent loops.
Resume from snapshot is faster because you’re loading a memory image, not booting a kernel. Typical resume time is 50-200ms depending on snapshot size. A 2GB memory snapshot on S3 takes ~150ms to restore and decompress.
Performance comparison:
| Operation | Latency | Use Case |
|---|---|---|
| Cold boot from template | 300-500ms | New agent session |
| Resume from snapshot | 50-200ms | Continue paused agent |
| Snapshot creation | 100-300ms | Checkpoint before risky operation |
| Fork (snapshot + new VM) | 400-700ms | Parallel exploration |
Cold starts are acceptable for agent workloads because the agent’s thinking time (LLM inference) is usually 2-10 seconds. The 500ms boot penalty is noise. For latency-sensitive tool calls, keep the VM warm or use resume.
Failure Modes and Recovery
VM crashes: If the kernel panics or the agent OOMs, the last snapshot survives. You can inspect the snapshot, debug the failure, and restart from a known-good state.
Host failures: Firecracker VMs are ephemeral. If the host dies, the control plane detects the loss and restarts the VM from the last snapshot on a different host. The agent loses in-flight work since the last snapshot but doesn’t lose the entire session.
Snapshot corruption: Snapshots are checksummed. If S3 returns corrupted data, the restore fails fast. You fall back to an earlier snapshot or restart from the template.
Credential broker outage: Agents can’t make external API calls. They can still execute local commands and write to the filesystem. When the broker recovers, queued requests resume.
Runaway costs: Set a max runtime or max cost per VM. When the limit hits, the platform snapshots and pauses the VM. You review the agent’s progress before deciding to resume or terminate.
When to Use Firecracker for Agents
Good fit:
- Agents that run for hours (code refactoring, data pipelines, research tasks)
- Workloads that need arbitrary package installs or system-level access
- Multi-tenant platforms where isolation is a hard requirement
- Agents that pause for human input or rate limits
- Parallel exploration (fork a VM, run 10 variants, pick the best)
Wrong tool:
- Sub-second tool calls (use containers or in-process sandboxes)
- Agents that never pause (just use a long-running VM)
- Workloads that fit in a stateless function (Lambda is simpler)
- Teams without ops capacity to manage snapshots and quotas
Technical Verdict
Firecracker microVMs solve the state persistence and isolation problems for long-running agents that containers and serverless functions can’t handle. The snapshot-pause-resume model makes multi-hour or multi-day agent sessions economically viable. The credential broker prevents exfiltration even if the agent is compromised.
Use this when your agents need mutable environments, arbitrary execution time, and kernel-level isolation. Avoid it if your workloads are stateless or latency-sensitive enough that 500ms cold starts matter. The operational complexity (managing snapshots, quotas, and broker policies) is justified only if you’re running agents that would otherwise require dedicated VMs or risky container sharing.
The open-source model (self-hostable) matters if you’re in a regulated industry or need to audit every line of the isolation stack. For most teams, the hosted version trades control for operational simplicity.