A sandbox that holds a whole environment

A sandbox for agents is usually a place to run generated code, but an agent that works in an environment needs more than that. It needs a place that holds the whole environment, including its services, its database, and its state, for as long as the task takes. That is true for an evaluation, for a reinforcement learning (RL) environment in training, or for any long-running job.

With the new Tensorlake provider, AgentEnv can run these environments inside Tensorlake microVMs, using the same Docker-based workflows it already supports.

We tested the integration with PortSimEnv, a port scheduling RL environment with several versions covering different operational challenges. For our demo, we ran a week-long weather scenario from v4 on Tensorlake.

01 · How AgentEnv works

Scale AI's AgentEnv is an open-source framework for building and evaluating agent environments. An environment can include MCP servers, databases, websites, or other services that an agent interacts with.

Tasks define the workflow: start the environment, deploy an agent, give it instructions, and evaluate the result. AgentEnv also records runs and manages the associated artifacts.

The framework already supports several sandbox backends, including local Docker, Modal, and E2B. Tensorlake is now another option.

For VM providers, AgentEnv runs the environment's Docker Compose stack inside a VM. Agents can run in separate containers or sandboxes and communicate with the environment through a gateway.

This separation lets the environment keep running while the agent works through a task.

02 · Tensorlake as a sandbox provider

The Tensorlake integration follows AgentEnv's existing VM provider interface.

Each sandbox starts from a Docker-capable host image, agentenv-dind-host-v1, based on tensorlake/ubuntu-systemd. The image includes Docker Engine and the Compose plugin. We registered it as a public image in Tensorlake Cloud so any Tensorlake user can pull it.

Once the VM is ready, AgentEnv uses its existing Docker workflows to deploy the environment and agent containers.

The provider also handles the details needed to run these workloads remotely:

• Resources and lifecycle: CPU, memory, and disk requests are validated before creation. Failed or cancelled starts are cleaned up.
• Networking: Exposed ports get public HTTPS URLs. Tasks can also configure egress allowlists, enforced outside the VM and across its containers.
• Image loading and file transfer: The provider supports Docker image loading and chunked file uploads with SHA-256 verification.
• Reconnect and cleanup: AgentEnv can reconnect to an existing sandbox by ID, recover its exposed ports and network policy, and terminate it.

The provider README has the full configuration and implementation details.

03 · Try it

Install AgentEnv with the Tensorlake extra:

pip install 'agentenv-framework[tensorlake]'

Export your Tensorlake API key:

export TENSORLAKE_API_KEY=...

Then add this to .agentenv/config.toml:

[sandbox]
default       = "tensorlake"
agent_default = "tensorlake"
 
[sandbox.providers.tensorlake.config]
api_key = "env:TENSORLAKE_API_KEY"

This uses Tensorlake for both environments and agents. The API key is read from the environment rather than stored directly in the config file.

To check that everything works, run the bundled hello task:

agent-env run hello --sandbox tensorlake

It creates a sandbox, uploads a file, and verifies the result. No model is needed.

04 · Demo: a week of wind at Barcelona's port

We tested the integration with PortSim, an AgentEnv plugin built on Adithya S. Kolavi's PortSimEnv, a port scheduling RL environment with several versions covering different operational challenges.

For this demo, we picked one week-long scenario from v4, which focuses on weather conditions.

The agent manages berth scheduling at a quay in the Port of Barcelona, deciding when ships should arrive, where they should berth, and how to allocate resources. As the simulated week progresses, Port Control sends updated wind forecasts, and the agent has to adjust its plans.

There are restrictions on ship movement:

• Above 25 knots, ships 300 m or longer cannot berth or leave.
• Above 30 knots, all ship movement stops.

The agent needs to adjust its schedule as new information arrives. Its final score is calculated using the observed weather, rather than the forecasts it received.

The week runs on a virtual clock. It starts on Monday at 00:00, and time advances only when the agent calls advance. There are six watches in the week.

We ran it with GLM-5.3 (zai-org/GLM-5.3, served by Together). It took about 30 minutes of real time, with 29 agent turns and 27 tool calls. And it achieved a perfect score of 1.0 at the end.

What ran on Tensorlake

The setup used two Tensorlake microVMs.

The first VM hosted the port environment. It ran Docker Compose with five containers: the AgentEnv gateway, the PortSim MCP server, PostgreSQL, a database web UI, and a database MCP server.

The second VM ran the agent.

The agent communicated with the environment through the gateway's public HTTPS URL. The environment, including its services and database, stayed running for the entire task.

AgentEnv handled the task steps, delivered notices as the virtual clock advanced, and ran the verifier at the end.

Here's the demo video:

05 · Docs and source

• AgentEnv Framework
• Tensorlake Provider README
• Tensorlake Sandboxes
• PortSim AgentEnv Plugin