From Code Interpreter to Agent Computer: Why Agents Need Stateful Sandboxes

Agents need stateful sandboxes when a task requires persistent files, installed dependencies, browser or preview access, long-running commands, and repeatable review of outputs beyond a single code execution. A code interpreter is still useful for bounded calculations, charts, and one-shot scripts. The moment an agent has to edit a repo, retry a failing test, keep generated artifacts, inspect a web UI, or hand work back to a human, it needs something closer to a workspace or agent computer.

What changed from code interpreter to agent computer?

Early “code interpreter” features solved a narrow but important problem: let a model write and run code, usually Python, against files attached to a conversation. That is enough for many data tasks. A user can upload a CSV, ask for a transformation, get a chart, and download the output.

Agent work has a larger surface area. A coding agent may need to clone a project, install dependencies, edit files, run tests, inspect logs, start a dev server, open a preview, fix the result, and preserve the state long enough for a reviewer to verify what changed. A browser agent may need cookies, downloaded files, screenshots, DOM state, and a way to replay a failed step. A research or evaluation agent may need hundreds of isolated workers that keep artifacts and logs for later inspection.

That is why the vocabulary is shifting:

• Code interpreter means a managed execution tool for short scripts and generated outputs.
• Sandbox means an isolated environment where untrusted or agent-generated work can run away from the host system.
• Workspace means a file-backed environment where task state can accumulate across steps.
• Agent computer means a fuller runtime with files, commands, packages, browser or UI access, logs, previews, artifacts, lifecycle controls, and reset or snapshot options.

These terms overlap. The useful distinction is not branding; it is how much state and review surface the agent needs.

What do the core terms mean?

Concept	Primary job	Typical state model	Best fit
Code interpreter	Run generated code and return outputs	Short-lived session state	Calculations, file transformations, charts, small scripts
Sandbox	Isolate execution from the host and other sessions	Ephemeral or persistent	Running untrusted code, command execution, browser automation
Workspace	Keep files and environment context together	Persistent filesystem or restorable image	Coding agents, data projects, task handoff, repeatable review
Agent computer	Give an agent a task environment with tools and lifecycle controls	Stateful runtime with logs, artifacts, previews, and reset/snapshot paths	Multi-step software tasks, browser agents, evaluations, long-running workflows

The same product can cover more than one box. A stateful sandbox can behave like a workspace. A workspace with terminal, browser, artifacts, and lifecycle management starts to feel like an agent computer. The evaluation question is what the agent can do, what state survives, and how reliably humans can inspect or reset the result.

When is ephemeral code execution enough?

Ephemeral execution is still the right default when the task is small, bounded, and easy to verify from the final output.

Use a short-lived code interpreter style environment when:

• The input files are provided up front.
• The task can finish in one or a few script runs.
• The output is a chart, table, transformed file, or calculation.
• No package installation beyond the managed environment is required.
• The user does not need to inspect a running app, browser state, or long command log.
• The session can be discarded once the answer is delivered.

For example, a support analyst asking an assistant to group tickets by category does not need a persistent workspace. A data analyst asking for a one-off visualization may not need browser access or snapshots. Adding more infrastructure than the job needs can make lifecycle, cost, and security review harder.

When do agents need a stateful sandbox?

Stateful sandboxes become important when the agent is not just computing an answer but operating through a workflow.

Files must survive multiple steps

Agents often create intermediate files: downloaded source data, generated code, test fixtures, build artifacts, screenshots, reports, and logs. If each execution starts from a clean slate, the agent has to repeatedly reconstruct context or squeeze too much state into the model prompt.

A stateful filesystem gives the agent a working memory outside the context window. It also gives humans something concrete to inspect.

Dependencies need to be installed or reused

Many real tasks depend on packages that are not present in a default runtime. A coding agent may need npm ci, pip install, a Playwright browser, a compiler, or a project-specific binary. A data agent may need a library version that matches production.

If those dependencies disappear after every command, the agent wastes time and creates more failure points. Templates and snapshots help teams start from a known environment instead of rebuilding it on every run.

Commands can run longer than one model turn

Builds, tests, crawlers, migrations, training jobs, and evaluation harnesses may run longer than a single response cycle. Agents need to start a command, watch output, recover from partial failure, and capture logs.

That requires process state. It also requires timeout controls, cancellation, and a way to retrieve results after the model has moved to the next step.

Browser and preview access become part of the task

Many agent workflows are visual or web-facing:

• A coding agent starts a local web app and checks the rendered page.
• A browser agent navigates a site, downloads files, fills forms, or captures screenshots.
• A review agent verifies that a chart, report, or demo page actually renders.

For those jobs, the environment needs more than stdout. It needs ports, preview URLs, browser automation, screenshots, or some other artifact path that lets the agent and reviewer see the result.

Human review needs repeatable evidence

An agent can say “tests passed” or “the app looks correct,” but production teams need repeatable evidence. A good runtime keeps logs, generated files, screenshots, and preview links long enough for another person or process to review them.

This is where stateful sandboxes change the collaboration model. The sandbox is not only a tool for the model; it is also a review artifact.

What should a stateful agent sandbox preserve?

State is useful only when it is intentional. A stateful sandbox should make it clear what survives, what resets, and what can be turned into a reusable starting point.

Filesystem state

The filesystem is the basic unit of agent work. It should hold source files, generated outputs, test artifacts, logs, screenshots, and downloaded inputs. It should also be easy to list, read, write, upload, and download files through an SDK, CLI, or UI.

Runtime and package state

The runtime should support the languages and package managers the task requires. For coding agents, that usually means shell commands, project-level dependencies, and the ability to reuse a prepared environment. For browser agents, it may include browser binaries and automation frameworks.

Network and web access

Network access needs careful policy, not vague openness. Some agents need outbound package downloads, API calls, or web browsing. Others should run with tighter egress rules. Teams should evaluate whether the runtime lets them decide what the sandbox can reach and how those choices are logged.

Preview and artifact capture

Agent output often includes more than text. Look for support for files, screenshots, browser sessions, exposed ports, web previews, and command logs. These artifacts are how reviewers move from trusting the agent’s claim to checking the actual result.

Lifecycle controls

Stateful does not mean permanent. The runtime should support creation, timeout, pause or resume where available, termination, and cleanup. It should also support templates or snapshots so a prepared environment can be reused without preserving every session forever.

Reset and snapshot paths

Agents make mistakes. A practical agent computer needs a clean reset path and a way to capture a good state before risky work. Snapshots are useful after setup, after dependency installation, or before a long evaluation run.

How should teams evaluate an agent runtime?

Evaluation criteria should be separated from vendor claims. The right runtime depends on the workflow, risk profile, and review process.

Criterion	What to ask	Why it matters
Lifecycle	How are environments created, paused, resumed, timed out, and deleted?	Prevents abandoned sessions and uncontrolled cost
Filesystem	Can the agent and reviewer inspect files and artifacts?	Makes multi-step work reviewable
Package installation	Can dependencies be installed, cached, templated, or snapshotted?	Reduces setup repetition and drift
Command execution	Are logs, exit codes, timeouts, and background jobs accessible?	Makes failures debuggable
Browser or preview access	Can the agent inspect rendered output or automate a browser?	Supports web apps, UI tasks, and visual review
Network policy	What outbound access is allowed and how is it controlled?	Reduces risk from package fetches, web browsing, and external calls
Isolation	What boundary separates sandboxes from each other and the host?	Determines what kind of code and data the runtime is suitable for
Templates and snapshots	Can teams reuse known-good environments?	Improves reproducibility
Human handoff	Can a reviewer see the same files, logs, screenshots, or preview?	Turns the runtime into a reviewable artifact
Cost model	Is billing tied to session time, CPU, memory, storage, or concurrency?	Avoids surprise costs when agents run in parallel

Security-sensitive questions deserve exact documentation and product review. Avoid treating any sandbox as magic protection. Isolation, network access, secrets handling, and logs all need explicit design choices.

Where does Novita Agent Sandbox fit?

Novita Agent Sandbox is designed for agent workflows that need isolated, stateful execution environments. The Agent Sandbox overview describes sandboxes as environments where agents can run commands, read and write files, install dependencies, and use browser-based workflows. It also defines templates for prepared starting environments and snapshots for saving configured sandbox state.

That makes Novita a fit to evaluate when your agent workload needs:

• code execution inside an isolated environment;
• file access across multiple steps;
• dependency installation and reusable prepared environments;
• browser-oriented workflows;
• generated artifacts that humans can inspect;
• lifecycle controls through SDK or CLI;
• a platform direction that combines model APIs and agent sandbox infrastructure.

This does not mean every agent needs a stateful sandbox. If your application only needs one-off Python execution over a user-uploaded file, a code interpreter pattern may be simpler. If your team already has an internal runtime with strict egress, secret handling, audit, and review flows, the question is whether an external sandbox improves developer speed without weakening those controls.

Use Novita Agent Sandbox as part of an architecture decision, not as a blanket replacement for every execution path.

A practical decision rule

Ask one question before choosing the runtime:

Could a second person or agent resume, inspect, or reproduce this work from the environment after the first model turn is over?

If the answer is no and the output is still useful, ephemeral execution is probably enough. If the answer needs to be yes, the task is moving toward a stateful sandbox or agent computer.

For production agent systems, this often becomes the default pattern:

1. Start from a clean template or snapshot.
2. Let the agent work inside an isolated runtime.
3. Capture files, logs, screenshots, previews, and command results.
4. Preserve the environment long enough for review.
5. Reset, delete, or snapshot based on the outcome.

That workflow gives the model room to act while keeping the result inspectable.

Recommended articles

• Building a Coding Agent with Novita’s Agent Sandbox
• Host Clawdbot with Novita Sandbox Template
• Which Inference Provider Is Right for AI Agents

FAQ

Is a code interpreter the same as an agent sandbox?

No. A code interpreter usually focuses on running generated code and returning outputs inside a managed session. An agent sandbox is a broader isolated environment for commands, files, dependencies, browser workflows, lifecycle control, and reviewable artifacts.

Do all AI agents need stateful sandboxes?

No. Simple data transformations, calculations, and one-shot scripts can work well in ephemeral execution. Agents need stateful sandboxes when the workflow depends on persistent files, installed packages, long-running processes, browser or preview access, or human review of artifacts.

What is an agent computer?

An agent computer is a task environment that gives an AI agent computer-like tools: filesystem, shell, packages, browser or UI access, logs, artifacts, lifecycle controls, and reset or snapshot options. It is a useful concept for long-running and reviewable agent work.

Why do snapshots matter for agent workflows?

Snapshots let teams save a configured environment and reuse it later. They reduce repeated setup work, improve reproducibility, and provide a clean point to return to before the agent performs risky or experimental actions.

How should teams think about sandbox security?

Treat sandbox security as an architecture decision. Review the isolation model, network access, secrets handling, logs, lifecycle cleanup, and human review process before running sensitive workloads or untrusted code.