Sandboxes
A runtime binds a recipe to Introspection’s execution environment. This page is about what happens when a task actually runs.
One task, one sandbox
Each task executes in its own isolated sandbox. A sandbox runs exactly one task: no sharing of files, memory, or processes between tasks, and no reuse of one task’s environment for another. When the task finishes, the sandbox is destroyed.
This is the foundation of the isolation model. A leaked credential, a runaway process, or a corrupted working directory is bounded to a single task. It also makes every run reproducible: a sandbox is a fresh environment built from a pinned recipe, not a long-lived machine that drifts over time.
The sandbox is disposable, the record is not. Everything worth keeping (the conversation, the files the agent produced, the judges’ verdicts) is saved before teardown.
What runs in the sandbox
When a task starts, your recipe is checked out at its pinned version so the run is exact and reproducible, and the runtime’s bindings (the endpoints and variables the agent needs) are resolved. Then the agent loop runs.
Tasks come in two shapes:
- Interactive tasks keep a live session open, accept follow-up prompts, and sit idle between turns.
- One-shot tasks run once from an initial prompt and complete when the agent finishes its turn.
As the agent thinks, calls tools, and produces messages, it generates the conversation: the replayable record of the run.
Files are saved durably
The sandbox’s working filesystem is not the system of record. Files you upload are pulled into the sandbox on demand, and files the agent writes are saved back as durable artifacts. When the sandbox disappears, the outputs survive: downloadable, shareable, and available as input to later work.
Judges run before teardown
When the task settles, the recipe’s judges grade the just-finished conversation against the exact recipe version and environment that produced it. The sandbox is torn down only after judges have run.
Isolation and credentials
A sandbox has scoped, egress-restricted access and holds only a short-lived, task-scoped credential for talking back to the platform. The API key that created the task is never passed into the sandbox, and your real provider credentials are never exposed to the agent (they are injected at the network boundary). See the Security model for details.
Related
- Tasks: the unit of execution that runs in a sandbox.
- Runtimes: what binds a recipe to the execution environment.
- Recipes: the versioned behavior a sandbox runs.
- Files & shares: how artifacts persist past teardown.
- Judges: the quality rubrics that run at teardown.
- Security model: sandbox isolation and how credentials are kept from the agent.