Short-lived environments are useful for isolated tasks, but they fall apart once an agent needs to preserve installed tools, checked out repositories, generated artifacts, or intermediate reasoning state. Rebuilding all of that on every run adds latency and makes async workflows feel fragile.

The pattern we kept seeing across modern agent infrastructure is simple: developers want isolation without throwing away continuity. That means keeping the runtime boundary strict while still letting the sandbox remember enough state to be useful over time.

A persistent sandbox lets a team return to the same workspace with its filesystem, dependency graph, and task outputs already in place. That makes agent sessions resumable, Git-based handoffs more reliable, and debugging dramatically faster.

For Tennant, this maps directly to the control plane we are building: create a sandbox once, deploy from GitHub, execute commands through the dashboard, CLI, or SDK, and keep that runtime around for follow-up work instead of treating every action like a cold start.

Persistent does not mean shared or sloppy. It means the sandbox keeps its own state while still being isolated from every other workload. That is the line we care about: durable agent context, strict workspace boundaries, and an execution model that can be reasoned about by operators.

That is why Tennant Sandbox is leaning into both ephemeral and persistent runtimes. Teams need both modes. The trick is making them feel like one coherent product rather than two unrelated systems.