Project Lunchbox: Freeze It. Fork It. Let It Run.

Like every company in existence, when we undertake big scale initiatives, we give them fun, often silly internal code names. Sometimes those names are too good to be kept in the corner… so today I’m excited to share with you details about Project Lunchbox. Why lunchbox, I honestly don’t know, but we enjoyed calling the PM of the project our Lunch Lady. 

You can think of Project Lunchbox as our latest capability set that gives AI agents their own ultra-secure, hyper-efficient digital test tracks (think sandboxes) running within your company’s existing cloud setup. When these AI agents run code, browse the web, or try out different actions, they are more than capable of breaking things, getting compromised via malicious prompt injection attempts, or worse, they end up hogging a massive amount of your cloud compute memory. Keep in mind, production-fleet agent deployments regularly need to spin-up 1000s of agent sessions at one single time, which understandably leads to increased memory utilisation - racking up a significant bill. 

Project Lunchbox simply turns Edera into a system built specifically to host these AI agents safely and cheaply, using tools engineers already use like Kubernetes. The metaphor we use for "packing the lunchbox" just means adding a few key product enhancements and design preparation steps to ensure the underlying engineering work our team is already doing correctly aligns with your agentic pain points the industry is feeling. To understand what Edera is actually building with respect to Project Lunchbox, think of of our offering through 3 main superpowers:

Unbreakable Isolation: A Private Kernel for Every AI Agent

Instead of running your AI agents in a shared space where a potentially rogue agent could steal data or infect the rest of the company's servers, Edera wraps every single agent in its own isolated microVM with its own private Linux kernel. If a coding agent attempts to generate untrusted code or attempts to access data it really shouldn’t, it’s now trapped inside its own box and cannot touch anything else. Imagine your coding assistant has access to the company's source code and is tricked by a malicious prompt into trying to upload that code somewhere? That would be scary! With Edera, access to the outside world can be controlled below the guest, at the runtime and hypervisor layer. The agent can't simply decide to grant itself additional network access. But isolation isn't just about security.

Snapshotting: Freeze and Restore AI Agent State on Demand

Like pausing a video game mid-level, Edera lets developers freeze a running AI agent, save its exact state, and put it to sleep so it stops consuming idle resources. Later, you can wake it up right where it left off. This is particularly valuable for long-running interactive agents waiting on human input. There's no reason to keep paying for all of the compute and memory while the agent is waiting. Snapshotting also eliminates repetitive setup overhead. Instead of installing heavy packages, toolchains, and environment dependencies every time an agent spins up, you perform the setup once, snapshot the warm state, and instantly restore from that known-good starting point. This provides a fast, repeatable building block for both production agent fleets and reinforcement learning eval environments.

Live Forking: Cloning Running Agents with Copy-on-Write

Now things get really interesting. Imagine an AI agent reaches a tricky decision and wants to test 10 different paths at once. Instead of starting 10 new environments from scratch, Edera can take the exact live state of the agent and clone it 10 times. Thanks to smart memory sharing through Copy-On-Write (COW), all 10 clones initially share the same underlying memory. Only when 1 of them changes a page does Edera actually need to now create a private copy. Think of it this way, although the base memory is shared; the diverging memories cannot access each other, which is important from a data security and privacy standpoint.

For Reinforcement Learning (RL) workloads, isolation is also about correctness. If one rollout can accidentally leak state into another rollout, you can contaminate your training data and ultimately poison the learning process. Hard isolation gives every environment a clean, independent execution boundary that ensures RL workloads are running consistently.

The goal is to expose these new-found superpowers as primitives that teams can use to build their own AI agent and reinforcement learning infrastructure on Kubernetes, running on clusters YOU control. We want these capabilities to feel like normal developer primitives rather than low-level virtualisation magic dust. For example, you and your team could interact with an Edera sandbox through a simple Python SDK:

from edera_runtime import Sandbox

sandbox = Sandbox.create()
sandbox.commands.run("train.py &")

sandbox.suspend()
sid = sandbox.sandbox_id

# After some time...
resumed = Sandbox.resume(sid)
resumed.commands.run("cat /home/sandbox/output.txt")

The same primitives can be composed to build an agent that explores multiple possible futures:

from edera import Sandbox, Capability

sandbox = Sandbox.create(image="python:latest")
sandbox.commands.run("python agent.py &")

snapshot = sandbox.snapshot(name="agent-snap-0")

instance = snapshot.start()
instance.exec(command="agent.py --until-decision-point")

# Fork the live state into 10 divergent trajectories
snapshot, forks = instance.fork(count=10)

for fork in forks:
    fork.attach_capability(Capability("talk-to-github"))
    fork.exec(command="agent.py --explore-branch")

The important thing here isn't the Python API itself, but rather the primitives underneath it. You can create a sandbox. Freeze it. Restore it. Fork it. Go ahead and give it narrowly-scoped capabilities. Those are building blocks that your engineering team can compose into whatever agent platform they need.

How does this approach differ from Kubernetes' Agent-Sandbox?

Kubernetes has become the standard way for many orgs today to manage workloads at serious scale. However, there are some things it doesn't currently make particularly easy for you. As an example, Kubernetes doesn't have any native, dev-friendly abstraction for this specific problem:

“I want to freeze this running workload exactly where it is, save its state, and bring it back later.”

While there is a dedicated checkpoint functionality exposed through the CRI, it has historically been oriented more toward things like forensics rather than the checkpointing and restoration workflows that are increasingly adding value for AI workloads.  Kubernetes itself is also starting to address this problem. 

With Kubernetes 1.37, pod-level checkpoint and restore is available as an alpha capability, exposing this functionality through the Kubernetes runtime stack. The industry clearly sees the value of being able to capture and restore a running workload, but Kubernetes leaves the underlying implementation to the container runtime. That makes this an important building block, but it doesn't by itself provide the higher-level developer primitives needed for agent workloads.

And that's exactly where we differentiate ourselves. We're taking the virtualisation primitives we've already discussed above, such as Snapshotting, COW Forking, and Identity, before exposing them through straight forward interfaces that Kubernetes users can actually compose. The longer-term vision for Edera is to provide a very specific set of Kubernetes-native resources such that:

Sandboxes represent the isolated execution environment.

Snapshots represent a saved execution state of the sandbox.

Forks represent the COW clones of your running sandbox environment.

Capabilities represent the narrowly-scoped permissions that you grant to sandboxes.

You could then interact with those resources directly through Kubernetes or through a higher-level SDK. The complexity of talking to the runtime, managing snapshots, and eventually distributing and restoring workloads across nodes stays underneath the abstraction. By doing this you are building your own agent infrastructure. 

And this distinction about building your own agent infrastructure is really important to understand. Project Lunchbox is not about creating yet another managed AI sandbox cloud. There are already excellent managed services that make it incredibly easy to spin-up sandboxes and run agents. That's not the market we're trying to replicate. There is yet another group of teams, however, that can't or don't want to hand their agent execution to someone else's cloud. We have also heard from developers and infrastructure teams that those managed offerings, while making your life “easy”, also comes at a premium. With Edera, you can repurpose your existing Kubernetes cluster to keep costs down. You, the reader, might have sensitive customer data, proprietary training data, strict data residency requirements, regulatory requirements, or simply too many workloads at scale that running everything through a 3rd-party service no longer makes any economic or operational sense.

And your same teams likely already have Kubernetes clusters running.

In those cases, you’d preferably want to run the RL-style workloads on infrastructure you already own, but understandably you wouldn't necessarily want to build an entire execution platform from scratch. So Edera decided to solve this pain point. Instead of renting an agent platform, your team can use Edera as the execution substrate underneath the existing platform you’re already building out. The team who’s responsible for building a coding agent product gets their own isolated environments, snapshot & restore, as well as capabilities. The team building the RL platform, likewise, enjoys the benefits of blazing fast environment resets, best-in-class isolation, as well as COW forking. The team building the multi-tenant agent platform similarly enjoys those same primitives. Edera doesn't even need to dictate what the app should look like. We simply provide the execution primitives and let Kubernetes users compose them into whatever system they need.

But why MicroVMs for AI Agent Workloads?

This is where our existing work at Edera becomes particularly relevant. MicroVMs give far more visibility about agent actions. Having per-agent VM visibility means we could more easily expose an audit trail of actions as well as measuring task success. Edera already provides an enterprise-grade microVM runtime for Kubernetes. Every workload already gets its own kernel and a strong hardware-backed isolation boundary, while still retaining the familiar Kubernetes experience. And this gives us a useful combination of MicroVM isolation with the benefits of Kubernetes orchestration, as well as the runtime-level state manipulation. The microVM becomes so much more than a simple security boundary in this case. Because we’re controlling the virtualisation layer, we can combine strong workload isolation with runtime-level control over the state of each environment. Every workload gets its own kernel and hardware-backed isolation boundary. This is something ordinary containers don't really provide. This gives us a foundation for capabilities such as checkpoint and restore, as well as the COW forking of a running environment, where the latter enables multiple divergent workloads to share their initial memory state without sharing their subsequent changes. That makes the microVM a particularly interesting execution environment for higher-density AI workloads.

Least-Privilege Capabilities: Controlling What an Agent Can Access

Process isolation tells us what an agent can't touch, whereas capabilities let us define what it can touch. So, instead of giving an agent broad access to a network or a collection of credentials, we alternatively choose to give it a narrowly-scoped capability like:

capability = Capability("talk-to-github")
fork.attach_capability(capability)

By combining microVM isolation with explicit, least-privilege capabilities, agents receive only the access required for a given task. Because agents will inevitably make mistakes or face compromise, Project Lunchbox ensures that a breach stays strictly contained within its sandbox rather than threatening the rest of your fleet.

How Copy-on-Write Forking Scales to Thousands of AI Agents

At scale, COW makes massive parallel execution remarkably cost-effective. Instead of booting thousands of duplicate environments for an RL workload, you spin up a single warm base state and fork it into thousands of trajectories. Each fork shares the initial memory and only pays for the pages it uniquely alters. While managing cross-node distribution and Kubernetes memory accounting for shared pages present complex engineering challenges, these primitives make high-density, multi-agent fan-out economically viable.

AI agents and RL workloads don't just need isolated containers, but rather they need environments that start fast, isolate hard, pause cleanly, clone cheaply, and scale massively. Project Lunchbox delivers these primitives as a Kubernetes-native execution substrate. Rather than asking teams to adopt a proprietary cloud or learn an entirely new platform, we’re packing Edera’s hypervisor-level virtualisation into familiar developer primitives. You get the flexibility to build your own agent infrastructure, on the Kubernetes clusters you already own.

That's Project Lunchbox. Are you hungry to try it out? Join our lunch table here. 

FAQ

What is Project Lunchbox?

Project Lunchbox is Edera's capability set that runs AI agents in their own isolated microVMs on Kubernetes clusters you already own. It exposes snapshotting, Copy-on-Write forking, and least-privilege capabilities as composable, Kubernetes-native primitives for building your own agent infrastructure.

How does Edera keep AI agents isolated from each other?

Edera wraps every agent in its own microVM with a private Linux kernel and a hardware-backed isolation boundary. Network and outside access is controlled below the guest, at the runtime and hypervisor layer, so an agent cannot grant itself more access, and a breach stays contained inside its own sandbox.

How does Copy-on-Write forking cut cost for RL workloads?

Instead of booting thousands of duplicate environments, Edera spins up one warm base state and forks it into many trajectories. Forks share initial memory through Copy-on-Write and only pay for the pages they uniquely change, making high-density, multi-agent fan-out economically viable at scale.

How is this different from Kubernetes pod checkpoint and restore?

Kubernetes 1.37 adds pod-level checkpoint and restore as an alpha feature but leaves the implementation to the container runtime and lacks higher-level agent primitives. Edera exposes snapshot, fork, and capability as composable Kubernetes-native resources you can build on directly or through an SDK.

Why does Edera use microVMs for AI agents?

MicroVMs give each agent its own kernel and a strong hardware-backed boundary while keeping the Kubernetes experience. Controlling the virtualization layer lets Edera combine hard isolation with runtime-level state control, enabling checkpoint and restore and COW forking, plus per-agent visibility for audit trails.