Jake

they're all called sandboxes - for now - but that's only because the vocabulary hasn't caught up. but people are calling them that so why resist. the use cases couldn't be more different though: - if you want your agent running as a web service to run a piece of code ad-hoc, you probably care about how fast it starts and finishes mostly - but if you run your agent harness in it, you mostly care about security of your LLM API keys, long-running sessions, and the degree of control over provisioned resources from within feels like completely different products sharing the same name temporarily

Even 6 months ago, the market was generally skeptical of sandboxes as a primitive. For most workloads, you could just use code exec boxes as they're cheap and fast. But they were designed for code that behaved predictably with expected inputs/outputs, and were stateless by default. When autonomous agents arrived, they needed environments to write, preview, and run code + full computer access to browse and execute tasks. Each task required a persistent, isolated environment that could spin up in milliseconds and run for hours. Now multiply that by thousands of parallel agents serving millions of daily active users. With compute becoming infinitely forkable, sandboxes are now the substrate for the agentic economy.

agents (1) automating one off tasks vs (2) orchestrating 20 day processes across 5 people and 8 systems are fundamentally different systems design problem. imo the latter is far more interesting right now. single player // multi player

Introducing the Secure Exec SDK Secure Node.js execution without a sandbox ⚡ 17.9 ms coldstart, 3.4 MB mem, 56x cheaper 📦 Just a library – supports Node.js, Bun, & browsers 🔐 Powered by the same tech as Cloudflare Workers $ 𝚗𝚙𝚖 𝚒𝚗𝚜𝚝𝚊𝚕𝚕 𝚜𝚎𝚌𝚞𝚛𝚎-𝚎𝚡𝚎𝚌