Pattern 1: Agent in Sandbox
The agent runs inside an isolated container. Your application communicates with it over the network. This is what Tensorlake’s@function() does. When you deploy a function, your agent code runs inside an isolated container with its own filesystem, dependencies, and resource limits. The agent has direct access to its environment — it can read and write files, install packages, and execute code, all within the container boundary.
- The agent and execution environment are tightly coupled
- The agent needs persistent filesystem access across tool calls
- You want production to mirror local development — same code, same environment
- API keys must live inside the container for the agent to make inference calls
- Updating agent logic requires redeploying the function
Pattern 2: Sandbox as Tool
The agent runs in a Tensorlake function and gets sandboxes as tools it can use for code execution. When the agent needs to run untrusted or LLM-generated code, it creates a sandbox on demand, executes code there, and reads the results back. Tensorlake’s Sandbox API provides this pattern. Your agent logic runs in a@function(), and when it needs to execute code, it creates a sandbox with the Sandbox SDK and uses it as a tool.
- You need to execute untrusted or LLM-generated code
- API keys should stay outside the code execution environment
- You want to spin up multiple sandboxes in parallel for concurrent code execution
- The agent needs to create, inspect, and tear down environments dynamically
- Network latency on each execution call
- Two layers of containers (agent function + sandbox)
Learn More
Sandboxes Overview
Install Tensorlake and create your first sandbox.
Lifecycle
Sandbox states, resources, timeouts, and lifecycle operations.
Networking
Control internet access and blocked destinations.