Breaking Serverless Stateless Limits: How AgentRun Solves Agent Sandbox Engineering Challenges

Early generative AI operated as a "Copilot" that only suggested code, but newer agents such as AutoGPT, BabyAGI, and OpenAI Code Interpreter require true code execution and multi‑step interactions. This shift introduces three core requirements for a sandbox: secure isolation of untrusted code, persistent context across requests, and millisecond‑level cold‑start performance.

Why Serverless (FC) Was Chosen

Strong Security Isolation: Function Compute runs each instance in an independent MicroVM using RunD secure containers, providing kernel‑level isolation that prevents malicious code from escaping.

Extreme Elasticity & Cold‑Start Optimization: FC can scale to thousands of instances within seconds, and RunD reduces startup time to the millisecond range, eliminating the latency of traditional VM boot.

Cost Efficiency: Pay‑as‑you‑go billing and automatic idle‑instance reclamation mean resources are only charged when an agent is active, dramatically lowering costs for sparse, bursty workloads.

No‑Ops: Developers are freed from OS patching, network configuration, and cluster maintenance.

Session Capability: FC’s session affinity routes all requests with the same SessionID to the same compute instance, preserving context for the duration of an agent interaction.

AgentRun Core Runtime Mechanism

Traditional serverless is stateless, which cannot satisfy the stateful needs of code interpreters. AgentRun builds a stateful, session‑level sandbox on top of FC by combining session affinity with RunD isolation.

1. Sandbox Request Affinity

When a developer creates a sandbox, AgentRun generates a unique SessionID.

All subsequent requests that include this SessionID are routed to the same underlying compute instance, ensuring variables such as df = pd.read_csv(...) remain in memory for later steps like df.plot().

The gateway also supports Model Context Protocol (MCP) via SSE and streamable HTTP, allowing seamless tool integration.

2. Multi‑Layer Security Isolation

Compute Isolation: Each sandbox runs in its own MicroVM with concurrency limited to 1, guaranteeing tenant‑level process and memory separation.

Network Isolation: Users can enable or disable public network access or attach the sandbox to a VPC, preventing malicious code from reaching internal services.

3. Flexible Lifecycle Control

Idle Timeout: Sandboxes automatically shut down after a configurable idle period (e.g., 5 minutes), stopping billing while preserving any persisted data in NAS.

Pause & Resume (upcoming): Long‑running tasks can snapshot memory and disk state, allowing fast restoration without re‑initializing the environment.

4. Session‑Granular Storage Isolation (upcoming)

Each sandbox can mount a dedicated sub‑directory (e.g., /workspace) that is invisible to other tenants, eliminating cross‑tenant data leakage.

Typical Workflow: From Request to Result

Template Creation: The agent decides to use Python and requests the creation of a Code Interpreter template via the AgentRun gateway.

Sandbox Creation: Using the template ID, the gateway calls FC’s CreateSession API, receiving a SessionID and returning a sandbox business ID to the user.

Task Execution:

Upload an Excel file via the sandbox’s file‑upload API (optionally persisted to NAS).

Run code import pandas as pd; df = pd.read_excel('data.xlsx') using the run_code endpoint.

Because the session is affinitized, the variable df stays in memory for the next request.

Execute df.plot() to generate a chart; the image is saved to NAS and a download link is returned.

Resource Cleanup: After the agent finishes, the sandbox detects inactivity, triggers the idle timeout, and FC automatically destroys the instance, leaving only persisted NAS data.

Design Principles

Configuration as Code: Sandbox definitions (env vars, resources, health checks) are versioned templates, enabling reproducible environments.

Session = Sandbox: Each session uniquely maps to a compute instance, providing on‑demand allocation with guaranteed state retention.

Programmable Lifecycle: Beyond create/delete, the platform supports pause, resume, and automatic timeout to balance cost and performance.

Standardized Network Access: All interactions use HTTP/WebSocket with optional SSE, abstracting underlying network changes.

Fine‑Grained Storage Isolation: Future support for per‑session dynamic NAS mounts ensures data is confined to its sandbox.

Pre‑Built Templates

Code Interpreter: Pre‑installed Python/Node.js/Java, supports file upload/download, data analysis, charting, and CLI commands.

Browser User: CDP‑over‑WebSocket environment compatible with Puppeteer/Playwright for safe web automation.

All‑In‑One: Combines code interpreter and browser capabilities for complex agent tasks.

These templates are engineered for high performance and security, and future releases will allow users to define custom images with private dependencies.

Conclusion

By integrating RunD secure virtualization, session affinity, and dynamic NAS mounting into Alibaba Cloud Function Compute, AgentRun delivers a sandbox that is secure, low‑cost, and capable of preserving state across multi‑turn AI agent interactions. The platform reduces total cost of ownership by up to 60 % and frees developers to focus on agent logic rather than infrastructure, positioning AgentRun Sandbox as a leading cloud‑native solution for production‑grade AI agents.