The three layers of agent persistence
A few months ago I wrote that my agents die when I close my laptop. The fix I wanted was simple: put the agent on a machine that stays on. Since then I've been building around exactly that, and I've learned the annoying thing about simple fixes, which is that they reveal the next problem. Keeping the agent alive turned out to be the easy part. Keeping everything it needs alive is the real one.
Here's the shape of it. When people say "persistent agent," they're actually talking about three different things surviving, and they usually only mean one of them. I want to name the three, show how they depend on each other, and then talk about what's happening at the infrastructure level, because the tools for this have gotten genuinely interesting in the last year.
The three things that have to survive
First, the agent's own state. What task is it on, what has it tried, what did it learn, what's the plan. The transcript, basically, plus whatever memory it's built up. If this survives, the agent can pick up where it left off instead of re-reading the ticket from scratch. Most agent frameworks now have some version of this. Save the conversation, reload it later. Not hard.
Second, the computer's state. The files it downloaded. The browser tabs it has open. The spreadsheet that's half edited. The process it kicked off that's still running. The stuff in memory. This is the workspace, and it's a totally separate thing from the transcript. An agent can remember "I was halfway through reconciling 200 invoices" and still be completely stuck if the computer it was doing that on is gone, because now it has to find the invoices again, reopen the spreadsheet, get back to the right page, and hope nothing changed in between.
Third, the identity. Is it still logged into Salesforce? Is the VPN still connected? Did the Slack session expire? Did Google decide this looks suspicious and ask for a code from a phone that doesn't exist? This layer is the sneaky one. You can preserve the computer perfectly, every file and every tab, and still come back to a shell that can't do anything because every login timed out at 3am. The workspace is there. The permission to use it isn't.
Play out the failure cases and you see why these aren't really independent features. Agent state without computer state: it knows what it was doing but has lost the desk. Computer state without identity: the desk is intact but every drawer is locked. Identity without the other two: it can log back in, but it's a new hire on day one with a blank machine. The only version that actually feels like continuity is all three at once. So the thing we care about isn't "persistence" in the abstract. It's continuity of work, and work happens to span cognition, environment, and permission.
What the infrastructure people are building
The good news is the market noticed. A year ago the default sandbox for agents was "run once and die." You'd spin up a fresh environment, do the task, throw it away. That's fine for running a snippet of untrusted code. It's terrible for an agent that's supposed to work on something for a week.
Now the pitch from almost everyone selling agent infrastructure is persistence. Orgo sells a desktop that keeps running after you close the tab, and the disk and desktop session survive stops and restarts. Blaxel goes further: their sandboxes suspend when idle and resume in about 25 milliseconds with memory, filesystem, and running processes all intact, and they're pushing a runtime specifically for agents that pause and wake up over hours. E2B, Daytona, Modal, and Vercel Sandbox all have some flavor of snapshot you can restore from. The second layer, computer persistence, is rapidly becoming a checkbox on a pricing page.
To understand how they do it, and why some are faster than others, you need a little background on what a "computer" even is in this context. There are three answers, and each one persists differently.
VMs, containers, and the thing in between
A virtual machine is a fake computer running on a real one. It has its own kernel, its own memory, its own virtual disk. From the inside it looks like a normal Linux or Windows box. VMs are the most isolated option, because the guest can't see the host at all, and they're the most complete, because you can snapshot the whole thing, memory included, and get back exactly the state you left. The cost is weight. A traditional VM takes seconds to boot and uses a chunk of RAM just existing.
A container is not a fake computer. It's a regular process on the host that's been fenced off so it can only see its own files and its own process tree. Docker made this famous. Containers start in milliseconds and are cheap because they share the host's kernel. The downside is exactly that sharing: it's a weaker wall, which matters when the thing inside is an AI agent running code you didn't write. And out of the box, containers don't snapshot memory. Stop the container and any running process is gone. You can save the filesystem, but not "the state of the program that was running."
Firecracker is the thing in between, and it's why this whole space got interesting. Amazon built it to run Lambda. It's a stripped-down VM, a "microVM," that boots in around a hundred milliseconds and uses very little memory, while still giving you a real kernel boundary. So you get container-like speed with VM-like isolation. E2B runs on it. A lot of the newer sandbox companies do too. When someone says "we spin up a sandbox in 150ms," they almost certainly mean a Firecracker microVM restored from a snapshot.
The snapshot part is what makes persistence fast. Firecracker can write out the full memory and device state of a running microVM to a file. Restoring it doesn't copy the whole memory back in. It maps the file and pulls in pages only when the guest touches them, and any page the guest writes gets a private copy. This is called copy-on-write, and it's the trick behind the "resume in 25ms" numbers. You aren't loading gigabytes. You're loading a page table and letting the guest fault the rest in as it goes.
If copy-on-write sounds abstract, here's the version I use in my head. Imagine a shared textbook in a library. Ten students "check it out" at once, but nobody photocopies the whole thing. Everyone reads the same physical pages. The moment one student wants to scribble a note, the library photocopies just that one page for them, and they write on the copy. Nine students still share the original, one has a private page 47. Ten copies of a 500-page book, and the total extra paper is one page. That's the entire trick, and it's why a "clone" of a machine with 8GB of memory can appear in milliseconds. Nothing is cloned until someone writes.
For containers there's a tool called CRIU, Checkpoint/Restore in Userspace, that does the equivalent: freeze a running process tree, dump its memory and open files and network state, and bring it back later. It works, and it's been around for years, but it's a heavier, synchronous save-everything-then-restore-everything operation. Fine for moving a workload between machines. Slow if you want to do it a hundred times an hour.
Persist is table stakes. Fork is the new thing.
Here's where I've landed after a few months of poking at this. Persistence, meaning "continue from where I stopped," is getting solved. If your whole product is "your agent's computer doesn't disappear," you're competing with a feature that every sandbox vendor ships. That's not a wedge, that's a floor.
The sharper question is: when is persistence not enough? When does an agent need to branch its state, not just resume it? Continue from state 42, sure. But continue from state 42 in three directions at once, and keep the one that works. That's a different operation, and it's the one people are actually starting to build for.
A concrete version. An agent spends twenty minutes cloning a big repo, installing dependencies, getting the database seeded, and running the test suite once to make sure everything is green. That's state 42. Now it has to do a gnarly migration and there are three plausible ways to do it. With resume, it picks one, tries it, and if it was wrong it has to undo everything and try the next, hoping the undo was clean. With fork, it makes three copies of state 42 in a few milliseconds, runs all three approaches at once, and throws away the two that fail. The twenty minutes of setup is paid once. That's the whole pitch.
The cases where fork beats resume are pretty specific. You've spent twenty minutes getting an environment to an expensive state and want to try three approaches from there without paying the twenty minutes three times. You're about to do something risky and want a throwaway copy to try it in first. You want ten parallel workers that all start from the identical setup. You're evaluating an agent and want to run the same task five ways from the same starting point. Or you screwed up and want to go back to a checkpoint from an hour ago, not just resume the mess you're currently in.
The infrastructure for this is arriving fast. Daytona and Modal both let you fork a sandbox from a snapshot into parallel branches. On the research side there's a paper from earlier this year called TClone that forks live GUI environments, meaning a whole desktop with windows open, into isolated branches using copy-on-write memory and layered filesystems, and it's roughly twice as fast as doing the same thing with a VM snapshot. Another one called DeltaBox gets checkpoint and rollback down to about 14 and 5 milliseconds by only saving what changed since the last checkpoint and restoring by literally calling fork() on a frozen template process, so the kernel duplicates page tables but no actual memory. That's the same copy-on-write idea applied at the process level, and it's fast enough that an agent could checkpoint before every risky action without noticing.
So computer-state forking is going from "research idea" to "API endpoint" right now. The interesting part is what that does to the other two layers.
Fork the work, not the credentials
Say you checkpoint an agent at state 42 and fork it into branches A, B, and C. What did you actually copy?
Agent state, yes. All three branches should know what the task is and what's been tried. Computer state, yes. That's the whole point of the fork, they all start from the same desk. But identity? If you naively clone the machine, you've just made three copies of every session cookie, every API token, every VPN credential. Three agents that all look like Sahil to Salesforce, all acting at once, possibly doing conflicting things. That is a security problem and an audit nightmare and, frankly, it's how you get your account locked.
Here's what that looks like on the invoice task. State 42 is "logged into Stripe and the accounting tool, 200 invoices loaded, 40 reconciled." Branch A gets read-only access and tries a matching strategy, reporting what it would change. Branch B gets a test account and actually applies its strategy so we can see the result. Branch C gets the real account, but every write pauses for a human to approve. All three know the task. All three see the same spreadsheet. Only one of them can hurt you, and that one has a person in the loop. Naively cloning the VM gives you three branch Cs with no person in the loop.
The right move, I think, is that the third layer shouldn't be cloned at all. Fork the thinking and the workspace. Then hand each branch its own scoped permission: branch A can read but not write, branch B can act on the test account, branch C gets the real one and a human has to approve. Fork the work, not the credentials. That's a much cleaner idea than "fork the VM," and it's not what any of the sandbox products do today, because they operate below the level where identity lives. They fork bytes. They don't know what a login is.
The hard part is keeping the layers honest
There's one more thing that fell out of this, and it might be the actual problem. The three layers can disagree with each other, and they drift apart over time even without any forking.
The agent thinks "I'm logged into Salesforce." The computer has a Chrome tab open on Salesforce. The identity layer knows the session expired twelve minutes ago. Three layers, three different beliefs about the same fact, and the agent is going to act on the wrong one until it clicks something and sees a login page. Or: the agent thinks "invoice submitted." The computer shows the confirmation page. The actual external system failed the submission five minutes later. Again the layers disagree, and the agent's internal state is now quietly false.
Persistence makes this worse, not better, because the longer things live the more chances they have to drift. A stateless agent that starts fresh every time is at least consistently ignorant. A persistent agent that's been running for a week is carrying a week of beliefs, some of which have gone stale. So the real engineering problem isn't "keep the state alive." It's "keep three kinds of state alive and in agreement," and nobody has a clean answer to that yet.
Where this leaves me
I started this year thinking the problem was that agents lose their state. That's mostly solved, or about to be, by people with more Firecracker expertise than I'll ever have. What's not solved is treating an agent's work as one thing, a unit that spans what it's thinking, where it's working, and what it's allowed to touch, and being able to checkpoint that whole unit, branch it, and keep the branches from lying to themselves.
A persistent agent isn't a process that doesn't die. It's a piece of work that doesn't lose its mind, its desk, or its keys. The infrastructure is very good at the desk right now. The other two are where I'm spending my time.