Technically, we were tackling one of the hardest problems in the database world: stateful computation keeping a system running continuously while performing complex stateful operations, sustaining high throughput, absorbing workload spikes, recovering in seconds from node failures, and maintaining consistency across all state. The system maintains a continuously correct, queryable state over streaming data. Aggregations, joins, materialized views every operator holds state, and every piece of state must be reliably managed.

After five years of refinement, RisingWave is running in production at thousands of companies. Production environments are unforgiving workload spikes, node failures, and storage hiccups happen constantly. What keeps things standing is the architectural direction we chose from day one: compute-storage separation, S3 as primary storage, fully stateless compute nodes.

On-Call and AI SRE

Streaming database users aren't running offline reports. They're running real-time fraud detection, payment settlement, and live monitoring alerts all on the critical path. One minute of downtime means one minute of transactions halted, fraud checks disabled, alerts missed. On-call isn't "fix it tomorrow" it's "fix it now." And distributed system failures don't respect working hours 3 AM alerts, cascading failures across dozens of nodes, a SQL query hitting an unseen corner case that stalls checkpointing. This is everyday life.

So we started building AI SRE. The most painful parts of incident response alert triage, log analysis, fault diagnosis are largely pattern-based. An experienced SRE sees a certain alert and automatically runs through a mental playbook. These playbooks can be encoded for AI agents.

But a useful AI SRE agent can't just be a chatbot that reads logs and gives advice. It has to take action connect to the meta node to check barrier status, run diagnostic scripts to scan shared buffer backlogs across compute nodes, replay problematic SQL in a staging environment to reproduce bugs, analyze crash dumps hundreds of megabytes large. These are heavy operations, some potentially destructive. You don't want an AI agent running diagnostic scripts directly on production machines.

So the agent needs an isolated execution environment a sandbox. Then we discovered: the existing sandbox solutions simply don't work.

The Fundamental Problem with Ephemeral Sandboxes

The AI agent sandbox market is already quite hot Firecracker microVMs, gVisor containers, V8 isolates isolation technologies are flourishing. But if you look closely at the architecture of these solutions, they're all fundamentally designed around ephemeral execution: a sandbox is created, code runs, and when it finishes or times out, the sandbox is reclaimed session limits range from tens of minutes to twenty-four hours, after which all state is destroyed. Some solutions aggressively reclaim idle sandboxes for resource efficiency, causing multi-second cold start delays.

For running a simple Python script, ephemeral sandboxes are fine. But AI agents work very differently.

When an AI SRE agent investigates an incident, it first spends several minutes setting up the environment installing diagnostic tools, pulling logs, configuring production-matching connection info. Then it runs analyses, generates intermediate files, starts auxiliary processes. The sandbox accumulates significant state. Then the agent pauses waiting for human approval, or simply because one round of LLM conversation has ended.

Under the ephemeral model, pause = state death. Next time, rebuild from scratch. This isn't just wasted time the intermediate state accumulated during the previous exploration often can't be reconstructed, because the reasoning chain that produced it is gone.

This problem isn't unique to AI SRE. Coding agents need to persist development environments across sessions. Browser agents need to maintain browser context. RL training needs snapshot and restore. Everyone seriously building AI agents eventually hits the same wall: sandboxes need state.

From an Isolation Problem to a State Management Problem

Most sandbox solutions focus their energy on isolation how to prevent untrusted code from escaping. This matters, but it's only half the problem. Once a sandbox needs to be stateful, you're no longer dealing with an isolation problem you're dealing with a state management problem.

Specifically: state can't live only on local disk that ties the sandbox to a single machine, and if the machine dies, the state is gone. Filesystem changes need to be persisted to object storage, with local disk serving only as cache.

Sandboxes need snapshots, and they must be incremental snapshotting an entire filesystem each time is unusable in production. Any snapshot should serve as a rollback point if the agent breaks the environment, revert to the last good state. From a snapshot, you should also be able to fork new instances, and forks must be copy-on-write so agents can explore multiple paths at low cost.

Compute-storage separation means idle sandboxes can release compute resources while retaining disk state, and be restored when needed. At scale, this directly determines cost.

Isolation still can't be compromised. AI agents execute untrusted code each sandbox should be a micro-VM running its own Linux kernel with hardware-level isolation. Not container namespace isolation breaking out requires a hypervisor exploit, not a kernel exploit.

If you've built any kind of long-running stateful system databases, stream processing, distributed storage you've seen all of these challenges before. They're universal state management problems, just in a different context.

State Management: From Stream Processing to Sandbox

We spent five years solving stateful computation's state management challenges in RisingWave. When we started thinking about how to build a stateful sandbox, we found that many of the core challenges are shared.

Persistence: S3 as source of truth. RisingWave chose S3-as-primary-storage from day one. Our custom storage engine Hummock writes all state as immutable SSTables to S3, organized by table ID and epoch, never doing in-place updates. This makes compute nodes truly stateless if one dies, spin up a new one, pull state from S3, recover in seconds.

For sandboxes, the same principle applies: filesystem state needs to be persisted to object storage, with local disk serving only as cache. But the shape of sandbox state is different from a database it's not KV pairs, but an entire filesystem (OS, packages, user files, intermediate data from running processes). How to efficiently sync filesystem changes to S3 is one of the core problems we're currently exploring.

Checkpointing: must be incremental. RisingWave implements epoch-based asynchronous checkpointing: the meta node injects a barrier into the data stream every second, operators asynchronously dump local state to a shared buffer upon receiving the barrier, which then uploads to S3 in the background checkpointing doesn't block data processing. The key is that checkpoints are incremental, only persisting changed data.

Sandbox snapshots face the same constraint full snapshots of an entire filesystem are too slow and too expensive. A natural approach is to leverage copy-on-write disk formats (such as QCOW2's overlay mechanism): each snapshot freezes the current layer and creates a new overlay that only records subsequent writes. This way, snapshot cost scales with the amount of change, not the total filesystem size.

Rollback and Fork. When a RisingWave node fails, it loads the latest checkpoint from S3, replays the last few seconds of data, and recovers in seconds. For sandboxes, if each snapshot is an overlay layer, rollback means discarding overlays after the target point; fork means creating multiple independent overlay chains from the same snapshot.

The agent can fork a branch at snap-2 to try plan B while the original sandbox continues with plan A, keeping whichever result is better. If neither works, roll back to snap-1 and start over. Each fork shares all previous overlay data only new writes consume additional space.

Compute-storage separation and elasticity. RisingWave's compute nodes are stateless scaling means adding or removing compute nodes without migrating data. LSM-tree compaction is offloaded to dedicated compactor nodes, avoiding resource contention with computation. For sandboxes, compute-storage separation means idle sandboxes can pause releasing CPU and memory while disk state stays in the persistence layer and cold-start back when needed. In large-scale agent deployments, a large number of sandboxes are idle at any given moment, making this a direct cost driver.

Isolation. This is a dimension unique to sandboxes. Stream processing operators run in a trusted environment and don't need strong isolation. But AI agents execute untrusted code each sandbox should be a micro-VM running its own Linux kernel, with hardware-level isolation via KVM or Hypervisor.framework. Not container namespace isolation breaking out requires a hypervisor exploit, not a kernel exploit. BoxLite implements this layer using libkrun a lightweight KVM-based VMM library that provides near-container startup speed and resource overhead, but with VM-level isolation strength.

Side by side:

Sandboxes Should Be Embedded

Everything above is about cloud-level architecture. But I believe sandboxes should first be embedded.

Look at the database world. The hottest databases of recent years aren't the most feature-rich cloud databases they're SQLite and DuckDB because they're embedded, just import and use. This doesn't mean cloud doesn't matter. It means that trying an idea or validating a scenario on your own machine is always the most natural, fastest way. Get it working locally, understand it, then decide whether to move to the cloud.

BoxLite applies this philosophy to sandboxes. pip install boxlite, three lines of code to spin up a hardware-isolated micro-VM locally. No daemon, no root, no complex deployment. When a sandbox becomes a library you can import, every AI agent developer can use it directly start locally, connect to cloud-based S3 persistence and elastic scaling when needed. Local-first, cloud-ready.

The Future of Agent Infra

BoxLite was started by my friend Dorian Zheng in mid-2025. When I began exploring the possibilities of sandboxes with him late last year, we increasingly realized two things: first, stateful sandboxes are a severely underestimated developer pain point; second, the cloud-native stateful system experience we accumulated at RisingWave is almost directly transferable to this domain. This alignment wasn't planned it emerged from doing the work.

Agentic AI is just getting started. Today, attention is still focused on model capabilities smarter reasoning, longer context, better tool use. But when agents truly start running at scale, the bottleneck will inevitably shift from the model layer to the infrastructure layer. Agents need reliable execution environments, state management, and secure isolation. These problems don't have good answers yet.

This is the best time to build agent infrastructure.

BoxLite is open source on GitHub: github.com/boxlite-ai/boxlite

If you're not familiar with sandbox technology, you can think of it simply as a virtual machine. Funny enough, nearly 15 years ago when I was interning at EMC, I was working on something closely related to today's sandboxes - Xen. Over the last two decades, we built sandboxes for humans. Now, we're building sandboxes for AI. That feels pretty surreal. But if virtualization has been around for decades, why is everyone suddenly revisiting what seems like an extremely mature technology? Well, because the requirements are completely different now.

In this post, we'll start from real-world sandbox use cases, explore the underlying technology, and discuss what the future of sandboxes looks like.

Starting with Manus

One of the biggest stories in AI in 2025 was Meta's acquisition of AI startup Manus for over $2 billion. The name Manus comes from the Latin motto "Mens et Manus" "mind and hand" embodying the belief that knowledge must be put into action to make an impact. From 2022 to 2024, everyone was using ChatGPT to chat. Manus showed the world that AI can do more than just provide information it can actually get things done. Once AI can do work, it's no longer just a chatbot. It's an agent. So here's the question: what does an agent have to do with a sandbox? Can't the agent just use the user's computer or a regular server?

Let's take Manus as an example. Manus built its agents in the cloud. Suppose Manus is serving 1,000 concurrent users (in reality, far more!). Each user's request spawns an agent, meaning 1,000 agents need to run simultaneously. Now imagine all 1,000 agents on a single server. What happens? Each agent wants to install its own packages, configure its own environment, have its own filesystem, and claim its own CPU resources. So what do you do? Obviously, each agent needs its own office to work in. That office is the sandbox.

Under the hood, Manus used microVM-based sandbox technology to solve exactly this problem. Each agent runs in an isolated sandbox with its own browser, terminal, and filesystem, capable of running Python, JavaScript, Bash, and more in isolation. By the time of its acquisition, Manus had created over 80 million virtual computers each one a standalone sandbox.

Of course, there's only one Manus. But do we, as individual developers, still need sandboxes in our daily work with agents? Absolutely. If you're a programmer, chances are you've used Claude Code. Claude Code is a coding agent that downloads packages, runs scripts, and reads/writes files on your local machine. We trust Anthropic's engineering and credibility, so we're comfortable letting their agent operate on our computers. Claude Code also promises to mostly stay within a user-specified directory, which gives a sense of security. But when we use something more powerful, more permission-hungry like OpenClaw (well, congrats Peter for joining OpenAI!), or some brand-new no-name product would you still dare run it directly on your local machine? I doubt.

OpenClaw is a great example. This open-source AI agent can run shell commands directly on your OS, control browsers, manage local files, can talk with you via Telegram. It's so powerful that people call it "a real-life Jarvis." But power comes with risk the security teams have found a couple of third-party OpenClaw skills performing data exfiltration and prompt injection without user awareness. This is where sandboxes become a necessity.

Sandbox Technologies

Broadly speaking, a sandbox is just an isolated environment. An EC2 instance can be a sandbox. A Docker container can be a sandbox. A microVM can be a sandbox. But they behave very differently when it comes to AI agent workloads. Let's start with a high-level comparison:

Technology Comparison

Let's walk through each one.

EC2 / Traditional VMs

EC2 is too heavy. Slow to start (minutes), expensive, and lacking good auto-scaling. If you need to instantly spin up a fleet of agents for parallel deep research, EC2 simply can't deliver. In short, EC2 was designed for long-running services, not for fast-start, disposable agent sandboxes.

K8s + Containers

K8s solves the elasticity problem but introduces operational complexity. And its default container isolation shares the host kernel if AI-generated code triggers a kernel vulnerability, it could escape the container. Google recently open-sourced the Agent Sandbox project (using gVisor), which is K8s's formal response to the sandbox use case.

Docker Containers

Fast to start, mature ecosystem, developer-friendly. Docker has even launched a dedicated Docker Sandboxes product for AI agents. But the core problem remains: containers share the host kernel, so isolation isn't strong enough.

gVisor

A user-space kernel developed by Google. Its core component, Sentry, reimplements a large number of Linux syscalls in Go, intercepting and handling them in user space. This dramatically reduces the attack surface. More secure than containers, lighter than microVMs, but with compatibility trade-offs not all syscalls are perfectly emulated. I/O-heavy workloads can see 10-30% overhead.

MicroVM

The current best answer for sandbox isolation. AWS's open-source Firecracker gives each microVM its own dedicated kernel with hardware-level isolation via KVM. Extremely lean: <5MB memory overhead, <125ms startup, up to 150 microVMs per second on a single host. Most sandbox platforms on the market (such as E2B, Daytona, etc.) are built on Firecracker or similar microVM technology.

Takeaway: From an isolation standpoint, microVMs have provided a great answer security approaching traditional VMs, performance approaching containers. But choosing the right isolation technology is only step one. When you actually start using sandboxes, you'll find a deeper set of questions to answer.

Beyond Isolation: What Actually Matters

The isolation question is largely settled microVMs win. But the differences between sandbox solutions today are no longer about how they isolate. They're about everything else: how you integrate them, whether they keep state, and what primitives they expose. Four questions separate a great sandbox from a merely functional one:

Embeddable: A library, not a service

Most sandbox solutions assume you're running a separate service. Cloud solutions require calling a remote API, signing up for an account, and managing API keys. Docker requires a background daemon and typically root privileges. K8s, well, don't even get me started.

For a use case as simple as "I just want to safely run a piece of AI-generated code in my Python script," these are all way too heavy.

This reminds me of an analogy from the database world. Before SQLite, if you wanted to use a database in your application, you had to install MySQL or PostgreSQL, configure connections, and manage a separate database process. SQLite's revolution was this: it's an embedded database no separate process, no network configuration, just a library linked into your application. This made databases ubiquitous from mobile apps to browsers to embedded devices.

The sandbox space needs the same "SQLite moment." The ideal sandbox should be a library you embed into your application not a service you deploy alongside it.

Stateful: More than disposable

Most sandbox solutions today lean toward transient design. Disposable sandboxes are great for one-shot tasks: a user sends a request, the agent spins up a sandbox, executes, and destroys it. Clean and simple.

But as agents grow more capable, more and more use cases demand stateful sandboxes. Imagine a long-running coding agent: yesterday it installed a bunch of dependencies, configured the dev environment, and got the tests passing. You come back today to continue working of course you want all of that state to still be there. Rebuilding from scratch every time is a terrible experience.

A truly great sandbox should support persistent sessions: assign a sandbox an ID, pause it today, resume it tomorrow, all state intact. Just like closing your laptop lid and opening it the next day everything is still there.

Snapshots: Version control for runtime environments

This is where things get really interesting.

A Docker image is a filesystem snapshot it records what's installed. But a VM snapshot captures a running VM's full state disk, running processes, open network connections, everything. When you restore a snapshot, you're not cold-starting an environment; you're resuming a live one. The browser is already open. The server is already listening. The dev environment is already warm.

This single primitive capturing and restoring live VM state unlocks a surprising number of capabilities:

Templates Not just "Python is installed," but "Python is running, the browser is open, the MCP server is listening." Users restore a template and are instantly in a working state, skipping all startup overhead.

Fork / Branch From a single snapshot, fork multiple sandboxes to explore different directions in parallel. A deep research agent hits a decision point? Snapshot, fork into two sandboxes, try both paths simultaneously. An eval harness? Fork 100 sandboxes from the same checkpoint, run 100 strategies.

Rollback Agent broke something? Instantly revert to a previous checkpoint. Like git checkout, but for the entire running environment.

Migration Move a running sandbox between machines. From your desktop to your laptop, or from local to cloud for a burst of heavy computation.

Crash recovery Long-running agents periodically snapshot. If they crash, they don't restart from zero they resume from the last checkpoint.

Docker images can't do any of this. They're static filesystem layers. A live VM snapshot is fundamentally more powerful it's version control for runtime environments.

Hardware isolation: The baseline

This one is table stakes. Every sandbox needs it, but it's not what differentiates products anymore.

Docker containers share the host kernel a kernel vulnerability can lead to container escape. You have no control over what code an AI agent generates. An innocent-looking script could trigger a kernel bug and break out of the container.

A microVM gives each sandbox its own kernel. The boundary is hardware virtualization, not namespaces. Even if the code inside exploits a kernel bug, it's exploiting the guest kernel, not yours. The blast radius is contained.

This is a necessary foundation but most serious sandbox providers already deliver it. The real differentiation lies in the three properties above.

Comparing Existing Solutions

Let's stack these four properties against the current landscape:

As you can see, no existing solution checks all four boxes. That's a gap waiting to be filled.

BoxLite: The SQLite for Sandboxes

This brings me to work on a project I think fills this gap: BoxLite.

BoxLite's positioning is clear be the SQLite of sandboxes. It's an embeddable micro-VM runtime written in Rust:

Here's what the core features look like in practice:

Embeddable. No daemon, no root, no Docker, no cloud account. pip install boxlite, write three lines of code, and you have a hardware-isolated sandbox running inside your application. It runs on your machine no network latency, works offline, no usage fees.

import boxlite

async with boxlite.SimpleBox(image="python:slim") as box:
    result = await box.exec("python", "-c", "print('Hello from sandbox!')")
    print(result.stdout)

Stateful. Assign a session_id to a sandbox, resume it later with the same ID. All files, installed packages, and environment configurations are exactly as you left them. Since sandboxes run on your own machine, pausing them costs nothing no cloud bills for idle time, no 24-hour expiration clocks.

Snapshots. Capture a running Box's full state and restore it instantly. Build a template where the browser, dev server, and MCP tools are already running; fork a sandbox at a decision point to explore two paths in parallel; rollback when an agent breaks something; migrate a running environment between machines. This is version control for runtime environments something Docker images fundamentally cannot do.

Hardware isolation. Every Box is a microVM with its own dedicated kernel hardware-level virtualization via KVM on Linux and Hypervisor.framework on macOS. Fully OCI-compatible, so any Docker Hub image works out of the box. Would you let a random AI agent run rm -rf / on your machine? With BoxLite, you can it'll only destroy the sandbox.

The BoxLite team has also built some higher-level projects: ClaudeBox uses BoxLite to isolate Claude Code execution, and boxlite-mcp provides an MCP server that integrates directly with Claude Desktop, letting AI agents operate browsers and run commands in an isolated desktop environment.

Conclusion

Back to the question we started with: why is a technology that's been around for decades suddenly being revisited in the age of AI?

The requirements have changed, but the core need "provide an isolated, secure space for computation" has never changed.

The way I see it, the future of sandboxes will be layered. Cloud-based managed sandboxes will serve SaaS products and high-concurrency scenarios. But for the broader developer community those writing code locally, running agents locally, building applications locally sandboxes need to be as lightweight, embeddable, and local-first as SQLite. BoxLite is doing exactly that.

Giving every developer and every agent an isolated, secure environment at their fingertips that's probably the most important thing happening in the sandbox space right now.