🔶 我们为自主 Agent 构建了沙箱基础设施

Agent 的能力上限取决于它能安全行动的环境。

为了自主工作，Agent 需要一种验证自身工作的方法。Agent 可以拥有丰富的行动空间和完美的奖励信号，但如果没有真实环境来执行，这些能力在很大程度上仅停留在理论层面。随着模型变得越来越强大，它们被托付给越来越重要的任务：修改数据库、运行任意代码、部署基础设施以及与生产环境 API 交互。有了完整的运行时工作区，Agent 就能验证自己的工作并迭代直至成功。

挑战在于构建一个既与开发者本地环境别无二致，又能安全隔离 Agent 每一个行动后果的工作区。沙箱提供了一个隔离的执行环境，Agent 可以在其中安全地运行代码、与服务交互并从失败中恢复。一个设计良好的沙箱为 Agent 提供真实的游乐场，同时确保每个行动都保持隔离、可复现且可处置。

一个优秀的执行环境应具备以下核心特性：

控制平面：以最小延迟保持执行就绪

供应必须几乎瞬时完成，使体验足够流畅，成为开发者日常工作流的一部分。

执行平面：真实的机器，而非一个 shell

环境应与开发者本地设置无异。Agent 需要真实的文件系统、Docker、客户仓库、数据库、开发服务、网络、工具以及与真实开发环境中相同的设置脚本。

安全与网络平面：隔离能力而不限制它

Agent 需要自由采取有意义的行动，但每个行动都应在强大的安全边界后隔离。目标不是限制 Agent 在工作区内能做什么，而是确保这些行动在明确定义的安全、访问和网络控制下安全执行。

数据平面：生产规模下的确定性状态

每次执行都应从一个已知状态开始，每个行动都应可恢复。相同的输入应产生相同的环境，使失败可调试、评估可重复、成功的轨迹可复用。

每一项设计决策最终都在这些核心原则的帕累托前沿上进行优化。

在本文中，我们将深入探讨支撑 Agent 执行、探索和从经验中学习的工作区的核心基础设施。我们将讨论如何供应具有真实环境相同能力的工作区，包括真实的文件系统、Docker、网络、代表性数据和生产工具，同时确保每次运行保持隔离、可复现且可处置。

01

概述

工作区的解剖

attachkeeps fullREQUESTCONTROL PLANESchedulerWARM POOLDaytonaVersioned snapshotsWORKSPACEinbound allowlistEXECUTION PLANEFilesystemCloned reposMCP serversDOCKERappdbcachenested servicesDATA PLANEPostgresRedisOLAPSECURITY & NETWORKCredential proxyattaches real key, never in the boxExternal APIsegressExecution tracepersisted outside the boundary

控制平面通过在需要之前使执行环境就绪来最小化延迟。执行平面提供真实开发者工作站的保真度，而非受限的运行时。安全平面在强隔离的同时不限制 Agent 的能力。最后，数据平面确保每个沙箱都从相同、可复现的状态开始。

02

控制平面：以最小延迟保持执行就绪

Agent 是交互系统，准备执行环境所花费的每一秒都是用户等待的一秒。启动 microVM、分配存储、克隆仓库、初始化服务、加载工具和执行健康检查很容易占据请求的关键路径。如果每次交互都需要从零创建沙箱，即使最强大的模型也会很快显得迟钝。

显而易见的解决方案是避免按需创建沙箱。

控制平面编排执行环境的生命周期，确保正确的沙箱以最低延迟完成供应、初始化并分配给 Agent。它还维护一个预供应的执行环境池，随时可以接受工作。调度器不按每次请求启动新沙箱，而是尝试将 Agent 附加到现有的预热沙箱。只有在预热池耗尽或工作负载需要尚不可用的资源或配置时，才会发生冷启动。Daytona 为预热沙箱池提供原生支持，使我们能够预供应执行环境，并以最低启动延迟将 Agent 附加到它们。

一个预热沙箱远不止是一个运行中的虚拟机。进入池中时，操作系统已启动，Docker 正在运行，仓库已克隆，依赖已安装，Agent 工具运行时已初始化，包括 MCP 服务器在内的支持服务也已就绪。从 Agent 的角度看，执行几乎立即开始，因为昂贵的初始化工作已经完成。

维护该池本质上是调度问题而非供应问题。保留太少的预热沙箱会增加冷启动延迟，而保留太多则会因空闲容量浪费计算资源。调度器持续预测需求，提前供应新沙箱，并通过 LRU 风格的淘汰策略回收未使用的容量。

SCHEDULERREQUESTSWARM POOLreadys0readys1readys2readys3s4s5s6s7steady state · warm sandboxes ready, scheduler at target

▶

一个较小规模预热池的实时模型。请求到达并即刻附加到预热沙箱，调度器在后台重新填充池，冷启动仅在池中没有就绪沙箱时发生。

最佳池大小取决于工作负载模式、仓库特征、依赖图、用户行为和资源需求。调度器成为一个预测系统：预测未来需求，提前准备资源，并在响应性和成本之间持续平衡。最大的延迟改进并非来自加速每个供应步骤，而是来自完全避免不必要的供应工作。

最具杠杆作用的优化之一来自意图预测。因为用户交互在请求提交之前就已开始，控制平面可以在用户仍在编写提示时就开始准备沙箱。通过将初始化与用户思考时间重叠，许多潜在的冷启动变为简单的附加操作，在不改变执行环境本身的情况下降低了感知延迟。

当没有预热沙箱可用时，回退路径仍然具有确定性。基础镜像从版本化快照恢复，分配特定于工作负载的 CPU、内存和存储资源，完成初始化、健康检查，然后交给 Agent。因此，快速路径和回退路径产生同等的执行环境，仅在请求到达前已完成多少工作上有所不同。

03

执行平面：真实的机器，而非一个 shell

沙箱中的低延迟只有在环境行为与 Agent 最终目标环境一致时才有价值。如果执行环境省略服务、简化文件系统或用模拟替代生产工具，可能供应更快，但它从根本上改变了 Agent 的行为，这并不实用。在人工环境中成功的轨迹在转移到真实基础设施时常常失败。

为此，我们的目标是保真度而非最小化。每个沙箱都旨在尽可能接近开发者工作站。Agent 在拥有可写文件系统、已克隆的仓库、项目配置、开发者工具、Docker、MCP 服务器以及在生产开发中会遇到的相同支持服务的完整环境中运行。目标很简单：如果一项任务在沙箱内成功，那么在客户的真实环境中执行时也应成功。

这一理念的结果之一是将容器化工作负载视为一等公民。现代软件开发很少只包含运行在主机上的单个进程。应用依赖于数据库、缓存、消息队列、后台工作者以及其他通常通过 Docker Compose 或类似工具编排的服务。支持这些工作流不仅需要 Docker CLI，还需要在沙箱内部运行一个能正常工作的 Docker 守护进程。与其推理某个变更是否可行，Agent 可以通过构建并运行其修改过的应用来直接验证行为。

提供这种级别的保真度不可避免地扩大了执行面。运行嵌套容器、暴露 Docker 守护进程以及支持任意开发者工具都带来了额外的安全考量。我们不限制这些能力，而是通过本文后面描述的安全架构将它们隔离起来。目标不是减少 Agent 的能力，而是确保这些能力保持安全的隔离和保护。

最终，执行平面的存在是为了消除评估与部署之间的差距。Agent 应该在软件最终运行的同类型环境中开发、测试和调试软件。沙箱越接近现实，Agent 就越可靠。

04

安全与网络平面：隔离能力而不限制它

执行平面有意赋予 Agent 广泛的能力。它们可以执行任意代码、与 Docker 交互、修改仓库、访问代表性数据以及与外部服务通信。这些能力正是 Agent 有用的原因，但也使得沙箱安全与传统应用安全截然不同。目标不是阻止执行，而是确保执行保持完全隔离。Daytona 通过支持内核级隔离和硬件级隔离，帮助我们改善不同沙箱之间的安全性。

没有任何单一安全边界是足够的。沙箱同时执行不可信、由模型生成的代码，同时与客户基础设施和凭据交互。防范权限提升、秘密泄露、横向移动和数据窃取需要多层独立的隔离，而非单一边界。

无秘密沙箱

最安全的秘密是 Agent 永远无法访问的秘密。

这一原则塑造了整个凭据架构。暴露给执行环境的任何凭据——无论是通过环境变量、挂载文件还是进程内存——如果攻击者通过提示注入或模型操纵控制了 Agent，最终都可能被窃取。短期凭据减少了暴露时间，但并未消除根本风险。如果 Agent 能读取秘密，它就能泄露秘密。

相反，凭据必须完全位于沙箱之外。需要认证的请求通过一个凭据注入代理进行路由，该代理在转发请求前附加相应的凭据。Agent 发出普通的网络请求而从未观察到底层秘密，代理则成为唯一负责凭据管理的组件。秘密永远不会成为执行环境的一部分，从而消除了一整类窃取攻击。

SECRETS NEVER ENTER THE SANDBOX

SANDBOXAgentno secrets insideEGRESS ALLOWLISTPROXYsecrets live hereExternal API

The agent never saw the secret.

▶

请求离开沙箱时无凭据，并在代理处（隔离边界之外）获得凭据，因此内部从不存任何秘密。此外，针对未批准主机的提示注入请求永远无法通过我们严格的出口允许列表。

网络隔离

保护沙箱需要控制双向流量。

入站流量通过允许列表进行限制，该列表限定哪些系统被允许与运行中的沙箱通信。这保护了控制平面并防止对活跃执行环境的未授权访问。

出站流量同样重要。默认情况下，Agent 只能与明确批准的目标通信。限制出口可防止任意数据窃取，并确保认证请求通过凭据注入代理而不是直接绕过它。两种控制都是必要的。入站过滤防止对沙箱的未授权访问；出站过滤防止未授权数据离开沙箱。

05

数据平面：可复现性而不牺牲保真度

一个忠实的执行环境只有在其中的数据同样具有代表性时才有用。真实应用依赖于数据库、缓存、分析存储和应用状态，而这些无法每次执行都从零重建。同时，每次 Agent 运行必须从相同的起点开始，这样实验才能可复现且相互独立。数据平面的存在正是为了同时满足这两个要求。

每个沙箱在 Agent 开始执行之前都配备了代表性数据集。根据工作负载的不同，这可能包括事务型 PostgreSQL 数据库、用于应用状态的 Redis，以及分析存储如 DuckDB 或通过受限网络策略访问的外部托管 OLAP 系统。与其要求 Agent 构建自己的环境，它到达的系统已经类似于 o

An agent is only as capable as the environment it can safely act in.

To work autonomously, agents need a way to verify their own work. The agent can have a rich action space and a perfect reward signal, but without a real environment to execute in, those capabilities remain largely theoretical. As models become more capable, they're trusted with increasingly consequential work: modifying databases, running arbitrary code, deploying infrastructure, and interacting with production APIs. With a full runtime workspace, agents can verify their own work and iterate until success.

The challenge is to build a workspace that is indistinguishable from a developer's local environment while safely isolating the consequences of everything an agent does. A sandbox provides an isolated execution environment where an agent can safely run code, interact with services, and recover from failure. A well-designed sandbox gives an agent a real playground while ensuring every action remains isolated, reproducible, and disposable.

A great execution environment should have the following core properties:

Control plane: keeping execution ready with minimum latency

Provisioning must feel almost instantaneous, making the experience responsive enough to become part of a developer's everyday workflow.

Execution plane: a real machine, not a shell

The environment should feel indistinguishable from a developer's local setup. Agents need a real filesystem, Docker, customer repositories, databases, development services, networking, tools, and the same setup scripts they would execute in a real development environment.

Security and Network plane: isolating capability without restricting it

Agents need the freedom to take meaningful actions, but every action should be isolated behind strong security boundaries. The goal is not to restrict what the agent can do inside its workspace, it's to ensure those actions execute safely within well-defined security, access, and network controls.

Data plane: deterministic state at production scale

Every execution should begin from a known state, and every action should be recoverable. Identical inputs should produce identical environments, making failures debuggable, evaluations repeatable, and successful trajectories reusable.

Every design decision ultimately optimizes for the Pareto frontier across these core principles.

In this post, we walk through the core infrastructure powering the workspaces where agents execute, explore, and learn from experience. We talk about how we provision the workspace with the same capabilities as a real environment, including a real filesystem, Docker, networking, representative data, and production tooling, while ensuring every run remains isolated, reproducible, and disposable.

01

Overview

THE ANATOMY OF A WORKSPACE

attachkeeps fullREQUESTCONTROL PLANESchedulerWARM POOLDaytonaVersioned snapshotsWORKSPACEinbound allowlistEXECUTION PLANEFilesystemCloned reposMCP serversDOCKERappdbcachenested servicesDATA PLANEPostgresRedisOLAPSECURITY & NETWORKCredential proxyattaches real key, never in the boxExternal APIsegressExecution tracepersisted outside the boundary

The control plane minimizes latency by ensuring execution environments are ready before they're needed. The execution plane provides the fidelity of a real developer workstation rather than a constrained runtime. The security plane enforces strong isolation without limiting what an agent is capable of doing. Finally, the data plane guarantees every sandbox begins from an identical, reproducible state.

02

Control plane: keeping execution ready with minimum latency

Agents are interactive systems, and every second spent preparing an execution environment is a second the user spends waiting. Booting a microVM, provisioning storage, cloning repositories, initializing services, loading tools, and performing health checks can easily dominate the critical path of a request. If every interaction requires creating a sandbox from scratch, even the most capable model quickly feels sluggish.

The obvious solution is to avoid creating sandboxes on demand.

The control plane orchestrates the lifecycle of execution environments, ensuring the right sandbox is provisioned, initialized, and assigned to an agent with minimal latency. It also maintains a pool of pre-provisioned execution environments that are ready to accept work immediately. Instead of booting a new sandbox for every request, the scheduler attempts to attach an agent to an existing warm sandbox. Cold starts occur only when the warm pool is exhausted or when a workload requires resources or configuration that are not already available. Daytona provides native support for warm sandbox pools, allowing us to pre-provision execution environments and attach agents to them with minimal startup latency.

A warm sandbox is much more than just a running virtual machine. By the time it enters the pool, the operating system has booted, Docker is running, repositories have been cloned, dependencies installed, the agent harness runtime initialized, and supporting services, including MCP servers, are already available. From the agent's perspective, execution begins almost immediately because the expensive initialization work has already been completed.

Maintaining that pool is fundamentally a scheduling problem rather than a provisioning problem. Holding too few warm sandboxes increases cold-start latency, while holding too many wastes compute on idle capacity. The scheduler continuously predicts demand, provisions new sandboxes ahead of time, and reclaims unused capacity through an LRU-style eviction policy.

SCHEDULERREQUESTSWARM POOLreadys0readys1readys2readys3s4s5s6s7steady state · warm sandboxes ready, scheduler at target

▶

A live model of a smaller scale warm pool. Requests arrive and attach to warm sandboxes instantly, the scheduler refills the pool in the background, and a cold boot happens only when the pool has no ready sandboxes.

The optimal pool size depends on workload patterns, repository characteristics, dependency graphs, user behavior, and resource requirements. The scheduler becomes a prediction system: anticipating future demand, preparing resources ahead of time, and continuously balancing responsiveness against cost. The biggest latency improvements do not come from making every provisioning step faster. They come from avoiding unnecessary provisioning work entirely.

One of the highest-leverage optimizations comes from intent prediction. Because user interaction begins before a request is submitted, the control plane can start preparing a sandbox while the user is still composing their prompt. By overlapping initialization with user think time, many potential cold starts become simple attachments, reducing perceived latency without changing the execution environment itself.

When a warm sandbox is unavailable, the fallback path remains deterministic. Base images are restored from versioned snapshots, provisioned with workload-specific CPU, memory, and storage allocations, initialized, health-checked, and then handed off to the agent. The fast path and the fallback path therefore produce equivalent execution environments, differing only in how much work has already been completed before the request arrives.

03

Execution plane: a real machine, not a shell

Low latency in sandboxes is only valuable if the environment behaves like the one the agent is ultimately targeting. An execution environment that omits services, simplifies the filesystem, or replaces production tooling with mocks may be faster to provision, but it fundamentally changes the agent's behavior which isn't useful. Successful trajectories in an artificial environment often fail when transferred to real infrastructure.

For that reason, our goal is fidelity rather than minimalism. Each sandbox is designed to resemble a developer workstation as closely as possible. Agents operate inside a complete environment with a writable filesystem, cloned repositories, project configuration, developer tooling, Docker, MCP servers, and the same supporting services they would encounter during production development. The objective is straightforward: if a task succeeds inside the sandbox, it should succeed when executed against the customer's actual environment.

One consequence of this philosophy is treating containerized workloads as first-class citizens. Modern software development rarely consists of a single process running on a host machine. Applications depend on databases, caches, message queues, background workers, and other services that are typically orchestrated through Docker Compose or similar tooling. Supporting these workflows requires more than the Docker CLI, it requires a functioning Docker daemon running inside the sandbox itself. Rather than reasoning about whether a change should work, the agent can directly verify its behavior by building and running the application it has modified.

Providing this level of fidelity inevitably expands the execution surface. Running nested containers, exposing a Docker daemon, and supporting arbitrary developer tooling all introduce additional security considerations. Rather than restricting these capabilities, we isolate them through the security architecture described later in this post. The goal is not to reduce the agent's capabilities, but to ensure those capabilities remain safely secured and isolated.

Ultimately, the execution plane exists to eliminate the gap between evaluation and deployment. Agents should develop, test, and debug software inside the same kind of environment where that software will eventually run. The closer the sandbox mirrors reality, the more reliable the agent becomes.

04

Security and Network plane: isolating capability without restricting it

The execution plane intentionally gives agents broad capabilities. They can execute arbitrary code, interact with Docker, modify repositories, access representative data, and communicate with external services. Those capabilities are what make agents useful, but they also make sandbox security fundamentally different from traditional application security. The goal is not to prevent execution. It is to ensure that execution remains fully isolated. Daytona helps us improve security between different sandboxes by supporting both kernel level isolation and hardware level isolation.

No single security boundary is sufficient. A sandbox simultaneously executes untrusted, model-generated code while interacting with customer infrastructure and credentials. Protecting against privilege escalation, secret exposure, lateral movement, and data exfiltration requires multiple independent layers of isolation rather than a single perimeter.

Secretless sandboxes

The safest secret is one the agent can never access.

This principle shapes the entire credential architecture. Any credential exposed to the execution environment, whether through environment variables, mounted files, or process memory, can ultimately be exfiltrated if an attacker gains control of the agent through prompt injection or model manipulation. Short-lived credentials reduce exposure but do not eliminate the underlying risk. If the agent can read a secret, it can leak it.

Instead, credentials must be outside the sandbox entirely. Requests requiring authentication are routed through a credential-injecting proxy that attaches the appropriate credentials immediately before forwarding the request. The agent issues an ordinary network request without ever observing the underlying secret, while the proxy becomes the only component responsible for credential management. Secrets never become part of the execution environment, eliminating an entire class of exfiltration attacks.

SECRETS NEVER ENTER THE SANDBOX

SANDBOXAgentno secrets insideEGRESS ALLOWLISTPROXYsecrets live hereExternal API

The agent never saw the secret.

▶

Requests leave the sandbox with no credentials and pick them up at the proxy, outside the isolation boundary, so no secret ever exists inside. Additionally, prompt-injected request aimed at an unapproved host never gets past our strict egress allowlist.

Network Isolation

Protecting the sandbox requires controlling traffic in both directions.

Inbound traffic is restricted through an allowlist that limits which systems are permitted to communicate with running sandboxes. This protects the control plane and prevents unauthorized access to active execution environments.

Outbound traffic is equally important. By default, agents may communicate only with explicitly approved destinations. Restricting egress prevents arbitrary data exfiltration and ensures authenticated requests pass through the credential-injecting proxy rather than bypassing it directly. Both controls are necessary. Inbound filtering prevents unauthorized access into the sandbox; outbound filtering prevents unauthorized data from leaving it.

05

Data plane: reproducibility without sacrificing fidelity

A faithful execution environment is only useful if the data inside it is equally representative. Real applications depend on databases, caches, analytics stores, and application state that cannot realistically be recreated from scratch for every execution. At the same time, every agent run must begin from an identical starting point so experiments remain reproducible and independent of one another. The data plane exists to satisfy both requirements simultaneously.

Each sandbox is provisioned with representative datasets before an agent ever begins execution. Depending on the workload, this may include a transactional PostgreSQL database, Redis for application state, and analytical stores such as DuckDB or externally hosted OLAP systems accessed through a restricted network policy. Rather than asking the agent to construct its own environment, it arrives in a system that already resembles the one it is expected to operate on.

Naively restoring these datasets for every execution quickly becomes prohibitively expensive. Even moderately sized databases require seconds, or minutes, to reload from backups, placing that work directly on the critical path of every request. The latency is particularly wasteful because the overwhelming majority of data remains unchanged across executions.

Instead, every sandbox begins from a shared reference snapshot. Rather than physically copying the underlying database, the data plane creates a database branch for each execution. The branch initially shares all storage with the reference dataset, allocating new storage only for pages modified during the run. From the agent's perspective, the database is a completely independent, fully writable instance. Underneath, only the differences consume additional storage.

REFERENCE SNAPSHOTPostgreSQL · full dataset · shared, read-onlyRUN Atiny deltaonly touched pages privateRUN Btiny deltaonly touched pages privateRUN Ctiny deltaonly touched pages privateSTORAGEbase + deltasSHARED BASEdelta not to scalenaive restore: a full database copy per run · slowdatabase branch: shared pages + tiny private deltas · instant

One mechanism delivers reproducibility, isolation, and low latency.

▶

Every run starts from the same reference database, instantly. Instead of copying it, each run gets its own branch that shares the original data and stores only the pieces it actually changes. So every run behaves like a full, private database, the extra storage stays tiny, and cleanup is just deleting the branch.

This approach changes the economics of reproducibility. Fresh databases are no longer something that must be restored, they are effectively created instantaneously. Every execution begins from the same reference state, agents are free to modify their local copy without affecting other runs, and cleanup becomes as simple as discarding the branch when execution completes. Reproducibility, isolation, and low startup latency all emerge from the same underlying mechanism rather than requiring separate systems.

Before a sandbox is handed to an agent, the data plane performs a final readiness check across every required service. A virtual machine that has successfully booted but whose supporting databases are still initializing is functionally no different from a failed environment. Verifying service health before execution ensures failures occur deterministically during provisioning rather than unpredictably halfway through an agent trajectory.

06

Pareto frontier between control, execution, security and data planes

PUSHING THE PARETO FRONTIER

EXECUTIONfidelityCONTROLspeedSECURITYisolationhardware isolation + secrets proxywarm poolsdev laptopbare shell

A Pareto frontier across the planes

▶

conventional frontier

workspace frontier

A normal sandbox is stuck on the inner frontier, so making it more realistic means giving up isolation or speed. The mechanisms in this post push the frontier outward, letting the workspace be realistic, isolated, and fast all at once. Database branching then means every run still starts from the same point.

Every design decision in this post trades between these four planes, and the tension is sharpest between fidelity and isolation. Giving agents access to container tooling dramatically improves fidelity. Agents can build images, launch services, and test changes against realistic infrastructure. But the same capabilities expand the security boundary. Docker daemons, nested workloads, and privileged operations introduce attack surfaces that require careful isolation and continuous hardening.

A conventional sandbox settles this tension by giving something up. It trades realism for safety, or speed for determinism. We built the workspace to refuse that trade. Kernel-level isolation contains the Docker daemon without shrinking what it can do, warm pools remove the latency cost of strong isolation, and database branching makes determinism effectively free. Each mechanism pushes the frontier outward rather than picking a compromised point along it. The challenge is preserving developer-level capability without ever allowing that capability to escape the sandbox boundary.

07

Building reliable agent infrastructure

A typical execution begins when the control plane receives a request and selects an execution environment. If a compatible warm sandbox is available, the agent attaches immediately. Otherwise, the control plane provisions a new sandbox from a versioned snapshot, initializes its services, performs health checks, and hands the environment off once it reaches a ready state.

From that point forward, execution occurs entirely inside the sandbox. The agent interacts with the filesystem, launches containers through Docker, queries reference databases, invokes MCP servers, and executes arbitrary code exactly as it would on a developer workstation. Throughout the run, outputs (including model responses, tool invocations, and execution events) are streamed back to the client while simultaneously being persisted as a complete execution trace.

That trace serves two purposes. Operationally, it provides the live stream that powers the interactive developer experience. Architecturally, it becomes a durable artifact of the run, enabling replay, debugging, auditing, and offline evaluation long after the sandbox itself has been destroyed.

This distinction matters because reproducibility requires more than recreating an environment. A deterministic starting state tells us where execution began; an execution trace tells us what happened afterward. Reliable agent infrastructure requires both: the ability to recreate the conditions of a run and the ability to understand the trajectory that emerged.

A sandbox run is therefore not simply a place where an agent executes. It is a controlled experiment with a known starting state, observable actions, and measurable outcomes.

This separation of responsibilities is intentional. The control plane manages the lifecycle, the execution plane provides a faithful runtime, the security plane enforces isolation and the data plane guarantees reproducibility. Each system remains narrowly focused, but together they produce an execution environment that is fast, scalable, realistic, reproducible, and safe.

The future of reliable agents will not come from limiting what they can do. It will come from building environments where they can do more safely.