Perplexity shipped SPACE on July 15, 2026 — Sandboxed Platform for Agentic Code Execution — and the interesting part isn't that an AI company built a sandbox. It's which problems they decided the sandbox should solve. SPACE treats the agent's execution environment as a product, not plumbing, and the three things it prioritizes — strong isolation, durability, and secret safety — are a good map of what "running agent code in production" actually requires.
What SPACE does#
Every agent task runs in its own AWS Firecracker microVM. That's the load-bearing choice. A microVM gives each task a hardware-virtualized guest kernel, so untrusted code the agent generates is isolated at the virtualization boundary — not merely inside a container sharing the host kernel. Firecracker (the same technology under AWS Lambda) buys you that boundary while still starting in tens of milliseconds, which is why it, and not a full VM, is the default for this job.
On top of that isolation, SPACE adds two things that matter more than they sound:
- Durability. A session can be paused, branched, and resumed. Perplexity's framing: walk away mid-task, come back a week later, and the agent continues where it left off. Branching lets one session fork into multiple sandboxes to explore alternatives in parallel.
- Secret safety. Keys and passwords are never stored in the sandbox. They stay under the user's own key management, so the isolated environment never directly holds the credentials — which shrinks the blast radius when a task goes wrong.
The performance numbers back the "it's a product" claim: median sandbox creation dropped from 185ms to 60ms, p90 latency from 447ms to 89ms — roughly 3–5× faster than the prior system — across 1.25M+ sandbox creations and 11.9M reconnects in a single week.
The runtime an agent executes in is no longer an implementation detail. Durable, resumable, secret-isolated execution is becoming the floor, not the ceiling.
Why a founder should care#
If you run agents that execute code — and increasingly every serious agent does — SPACE is a spec sheet for what "good" looks like, whether you buy a sandbox or build one.
Isolation is not optional. Your container is not a sandbox: a shared-kernel container is fine for code you trust and wrong for code an LLM just wrote. The boundary options run from plain containers (fast, weak) through gVisor and Firecracker microVMs (strong, still fast) to full VMs (strongest, slowest) — we lay out the tradeoffs in Firecracker vs gVisor vs Kata.
Durability is a feature, not a nicety. Long-running agent tasks get interrupted — by the user, by a rate limit, by a crash. If your runtime can't checkpoint and resume, every interruption is lost work. Pause/resume turns a fragile long task into a durable one, and branching turns "which approach works?" into a parallel experiment instead of a serial gamble.
Keep secrets out of the box. The moment an agent's sandbox holds live credentials, a prompt-injection or a runaway tool call can exfiltrate them. SPACE's answer — credentials never enter the sandbox — is the pattern to copy regardless of vendor.
The bigger move#
SPACE lands in a market that's consolidating fast. Google Cloud Run entered the agent-sandbox space last week; the independents — E2B, Modal, Daytona — have been here longer. The signal across all of them is the same: the agent runtime has become a distinct layer of the stack with its own competition, its own benchmarks, and its own buy-vs-build decision.
So add one line to your architecture review, right next to "which model": where does the agent's code actually run, can it survive an interruption, and does it ever touch our secrets? This week, Perplexity made the reference answer public. (The other ownership move this week was a model you can fine-tune and keep — Thinking Machines' Inkling.)
