PATTERN Cited by 1 source

Per-session ephemeral sandbox

Pattern

In a multi-user agent system, spin up a fresh isolated sandbox (micro-VM, container, isolate) for each user session on first filesystem/shell access. The sandbox is torn down when the session ends, leaving no persistent footprint. This provides user-to-user isolation without the cost of dedicated long-running infrastructure.

Mechanism

1. User opens a session with the agent.
2. On first command that needs filesystem or shell (not just chat), the harness provisions a fresh sandbox.
3. Project source trees and required CLIs are uploaded/installed in the sandbox.
4. All subsequent shell commands for that session run in this sandbox.
5. When the session ends (or goes idle long enough), the sandbox is destroyed.

Cost model

• Idle sandboxes transition from warm → cold, costing near-zero.
• Reviving a stale session provisions a new sandbox — acceptable because ephemeral sessions shouldn't leave state behind.

Contrast with per-task persistent sandbox

The same substrate can support opposite lifecycle policies: - Per-session ephemeral (SpriteDoc): fresh sandbox each session, torn down after. - Per-task persistent (Hermes Agent): one sandbox per task, resumed across sessions so installed tooling persists.

Both provide the same isolation guarantee; the disposal policy is a single configuration choice.

Seen in

• SpriteDoc (Fly.io internal troubleshooting agent): every user session gets its own Sprite; Sprite is destroyed when session ends (Source: sources/2026-06-08-flyio-building-agents-that-dont-break-themselves)
• Hermes Agent (Nous Research): opposite lifecycle — per-task persistent — on the same Fly Sprite substrate (Source: sources/2026-06-08-flyio-building-agents-that-dont-break-themselves)