Your agent's memory doesn't live in the sandbox

The first thing you notice when you move an agent into a disposable sandbox is how much you were relying on the filesystem to remember things.

Docker Sandboxes is the latest release of the same promise: spin up an isolated environment, let the agent work, tear it down, nothing persists. For isolation, that's great. For everything else, it's a problem you only discover after the second run.

I run agents that do multi-step work. They read a codebase, form a plan, write code, run it, iterate. In my old setup, the agent's state lived in the environment — a scratch directory, a few JSON files, a log of what it had already tried. The agent could look at its own history and decide what to do next. Sloppy, but it worked.

Move that into a sandbox and the first thing to vanish is continuity. The agent wakes up in a clean environment with no memory of what it did yesterday. Every tool call is a fresh start. It can't check "did I already try this fix?" because the answer lived in a file that no longer exists.

So you externalize the state. You build a state store, or push checkpoints to object storage, or make the agent write its own history to an API. The agent's memory becomes a database instead of a local read. And that's where the real engineering starts.

The sandbox solved the isolation problem and created a state problem. Every agent I've built since has the same shape: the sandbox is the body, and the memory is a separate service that lives outside it. The agent is stateless by design, and everything it needs to remember is fetched, not remembered.

That's not a bad thing. Stateless agents are easier to reason about, easier to scale, easier to kill and restart. But it changes what you build. You stop designing the agent and start designing the state.

The interesting work is all in the state layer:

• Checkpointing. The agent's plan, its decisions, its progress — written out at every step, not just at the end. If the sandbox dies mid-task, you need to resume, not restart.
• A history service. The agent can ask "what did I already try?" and get a real answer. This is what actually kills the retry loop — not a circuit breaker, but the agent knowing it already tried that exact thing.
• A decision log. Not just what the agent did, but why. When the agent goes wrong, the log is the only thing that tells you where the reasoning broke.
• Idempotent tools. The agent's actions need to be safe to repeat, because with a disposable sandbox, you will repeat them. The same call, twice, should produce the same result — or the second one should be a no-op.

The last one is the one that bites. In a persistent environment, an agent could check "is this record already updated?" before updating it. In a sandbox, that check is a network call to a state service that might be slow or down, and the agent might just fire the update anyway. Idempotency is the difference between a retry and a duplicate.

I've watched an agent delete a stale record, then get restarted in a fresh sandbox and try to delete it again. The sandbox held perfectly. The database didn't. The record was already gone, and the agent spent three tool calls figuring out why.

So when you evaluate Docker Sandboxes, don't just ask "can the agent escape?" Ask "what does the agent remember?" If the answer is "nothing," you've got a state problem to solve before you've got an agent problem.

The sandbox gives you the shell. It takes away the memory. The whole game is building the memory back — outside the sandbox, where it can survive.

I'd still use it. I'd just build the state layer first. The sandbox is the easy part. The memory is the hard part.