Direct answer: Isolation is necessary, but long-running agents also need persistent workspaces, scoped credentials, recoverable sessions and observable side effects.
Isolation is only the first requirement
When an agent can clone repositories, run code, open files or install dependencies, executing it in the same environment as trusted application code is an avoidable risk. Sandboxing provides the first boundary. But production agents also need to survive long tasks, reconnect safely, preserve the right files and access external systems without inheriting broad standing credentials.
1. Make the execution boundary explicit
A sandbox should define filesystem access, network policy, process limits, runtime duration and what survives after the run. Vercel’s Sandbox product uses isolated microVMs for untrusted code. OpenAI’s Agents API similarly lets developers choose a hosted sandbox, their own infrastructure or partner environments. The important architectural property is that agent execution is separated from trusted control-plane logic.
2. Treat persistence as scoped state, not as a shared machine
Long-running work benefits from a persistent workspace, but persistence should be tied to the session or task. The workspace may need source files, generated artifacts and checkpoints, while secrets and unrelated user data remain outside it. Persisting everything because it is convenient undermines the boundary the sandbox was meant to create.
3. Keep credentials outside the sandbox when possible
Long-lived provider secrets are especially dangerous inside code-execution environments. A stronger pattern is to resolve short-lived, task-scoped credentials through a trusted broker. Vercel Connect is one implementation of that idea. Even if an agent writes unsafe code inside the sandbox, the available credential should expose only the minimum service scope and expire quickly.
4. Record side effects outside the transcript
Agent logs are useful but insufficient as an audit system. Persist a structured record of tool calls, resource identifiers, approvals, external writes and produced artifacts. If a run fails halfway through, the product should be able to answer what actually changed without replaying prose from the conversation.
5. Design reconnection and cancellation
Long-running agents will be interrupted by deploys, network faults and user cancellations. The runtime should distinguish resumable work from abandoned work and ensure that retrying a task does not duplicate irreversible side effects. Idempotency keys, checkpoints and explicit commit boundaries matter more as agent sessions get longer.
The production standard
A production sandbox is not just “a container the model can use.” It is an execution contract: isolated compute, bounded persistence, scoped credentials, observable side effects, resumable state and predictable teardown. Those properties determine whether an agent can move from demo to dependable system.
Practical takeaways
- Separate untrusted agent execution from trusted control-plane code.
- Persist only task-scoped workspace state.
- Broker short-lived credentials instead of placing standing secrets in sandboxes.
- Store structured side-effect logs outside the conversational transcript.
- Make cancellation, retry and resume semantics explicit.
Related reading
- Your average latency is lying to you. Tail latency is where AI products break.
- Intent, permission, progress and recovery for agentic products.
- More Engineering coverage