Sandbox

When no pre-built tool fits, the agent writes code — JavaScript, SQL, shell — and runs it in the Sandbox, isolated from your real systems. The code is written for the task, executed, and the sandbox is destroyed after the run.

The agent writes code when no tool fits

Most work goes through provider tools — typed, named, gated. The Sandbox covers the rest: reshape a dataset no tool reshapes, run a one-off calculation, glue two outputs together. Inside a program, sandbox runs are ops like any other, with bindings in and out.

The sandbox is isolated

Sandbox code can't reach your connected systems, and its writes stay inside the sandbox. That's why sandbox runs don't need an approval gate — there's nothing consequential to gate. When results should touch a real system, that write goes through a gated tool like any other. Timeouts are enforced; when the run ends, the sandbox is destroyed.

Every run is recorded

The code the agent wrote, what it printed, what it returned — all of it lands in the job's trace like any tool call. You can read exactly what ran, not just what came back.

What's next

• Agents — when the agent reaches for the Sandbox.
• Programs — sandbox runs as program ops.
• Approvals — why sandbox runs don't gate, and real writes do.

Updated 2026-07-20