Where Does an Agent Actually Live, If Not Inside Its Sandbox?

Watch the full conversation: How We Brought Sandboxes Into JoyStream

Previous in this series: Four Things That Don't Live in Your Agent's Sandbox (And Why That's the Point)

Next in this series: Agent Sandboxes Don't Solve the Problem That Actually Matters

Every Agent Gets Frozen Before It Ever Runs

Every agent gets frozen before it ever runs.

The moment you deploy one on JoyStream, we break it into discrete steps and freeze that specification — not as a formality, but because what you actually want out of an agent is repeatable behavior, not room for hallucination. Each step gets a determination made at that point, not later: does this step need a sandbox? Does it need to call an external tool? All of it gets written down before the agent executes for the first time. That frozen definition stays inspectable afterward — you can simulate it, exercise it, poke at it — the same way you'd review a plan before committing to it.

Freezing the plan first is what makes everything that happens later boring, in the good sense.

The Sandbox Attaches to the Run, Not the Step

The sandbox attaches to the run, not the step.

Booting one up is fast these days, but it isn't free — there's real latency in spinning up an isolated environment, and paying that cost once per step would waste it over and over for no reason. So a sandbox spins up the moment the first step that actually needs one kicks off, then stays alive for the rest of that run's lifecycle. One boot cost, not many. Picture it running unattended — 5 a.m. on a Monday morning, some scheduled job firing with nobody watching — and a sandbox simply appears for whichever step needs it, then disappears when the run is done.

The Agent Itself Never Lives Inside the Sandbox

The agent itself never lives inside the sandbox.

What actually constitutes "the agent" — its skills, its schedule, its logic — is a persisted definition sitting in JoyStream's system, not a process running inside some isolated box. A dispatch loop orchestrates everything around it: sometimes a step needs a sandbox, sometimes it needs network access, sometimes it needs an external tool, and all of that choreography happens outside the sandbox entirely. When a step finishes, its results and logs come back to the loop, and only then does the sandbox holding it get garbage collected.

The sandbox is where a step gets executed. It was never where the agent lived.

Why Destroy It Every Single Time

Why destroy it every single time, instead of keeping a warm pool around?

Three separate reasons, not one. A sandbox left running becomes a footprint the next agent might stumble into — leftover files, stale state, side effects nobody asked for. An idle sandbox still burns CPU and memory whether anything's happening inside it or not, and that's money spent on nothing. And repeatability demands a clean slate every time, the same inputs producing the same outputs regardless of what happened in some previous run. Put simply: kill the whole thing, and start fresh next time you need it.

Agents need file access and the ability to run scripts, and that alone would justify isolating them. But security was never the only reason to build it this way. Repeatability mattered just as much.