Factory launches OpenCompute to run agent sandboxes on customer infrastructure

From one machine to a fleet

According to Factory, the move from chat-window agents to agents that investigate alerts, answer asynchronous requests, run scheduled Automations and pick up issues throughout the day turns the problem into on-demand compute. In its words, teams no longer just need somewhere to run an agent, they need a compute fleet that can keep up with the work.

Factory says OpenCompute brings on-demand provisioning and lifecycle management to customer-controlled infrastructure. The company frames it around one conviction: adopting autonomous software development should not require handing someone else the keys to your infrastructure.

The product builds on Remote Control and Droid Computers. Factory introduced Droid Computers in April 2026 as persistent machines for orchestrating Droids. Customers could create one in Factory's cloud or register their own machine through Remote Control. Because the agent execution loop runs on that machine, Droid can reach private repositories, package registries and internal services without those systems being exposed publicly.

Factory says enterprise customers still had a gap: they needed to manage fleets, not single computers. An alert should be able to trigger an investigation without someone first provisioning a VM, and a finished task should not leave idle resources running. Self-hosted machines lacked the native provisioning, suspension and resumption that Factory's managed offering already had, so customers were left operating the fleet themselves.

A layer above the compute provider

Factory observed wide variation in its customers' infrastructure. Some wanted agents on existing Kubernetes clusters, some on specialized hardware, and some on an internal platform their developers already used. The company points to third-party sandbox platforms such as E2B, Daytona and Modal, and to projects including Kubernetes Agent Sandbox, Google's Agent Substrate and AWS Lambda MicroVMs, as evidence of demand for bring-your-own-cloud and bring-your-own-infrastructure approaches.

Rather than pick one backend, Factory built a layer above the compute infrastructure. OpenCompute owns the common lifecycle: request a computer, bring it into the desired state, track its activity, and suspend or terminate it according to policy and provider capabilities. The provider owns the infrastructure mechanisms behind those operations.

The per-provider integration is called a driver. Factory says it developed and evaluated integrations across AWS Lambda MicroVMs, Kubernetes, EC2, Agent Sandbox, Agent Substrate and other experimental providers. It adds that these were not identical implementations or equally mature backends, and that the architecture was meant to accommodate those differences.

Factory also says the work was agent-native from the start. Engineers defined boundaries, behavior and conformance tests, and Droids handled the rest under human direction. A task like implementing a contract and satisfying conformance tests gives an agent a bounded problem with a verifiable result, the company argues.

Architecture and the first deployment

OpenCompute runs in the customer's environment and opens an outbound, TLS-secured WebSocket connection to Factory, which sends authorized compute requests over it. According to Factory, no public OpenCompute endpoint and no inbound firewall port are required. On enrollment, the deployment registers a public key with Factory and proves possession of the private key by signing a fresh challenge. The private key stays under the customer's control and can live in a supported cloud KMS.

Each sandbox opens its own outbound connection to Factory, as remotely controlled computers do today. Factory notes that compute placement is separate from inference routing and session storage, so keeping session data fully local depends on the inference and sync configuration.

For lifecycle handling, Factory describes a declarative model. A Go control plane records desired and observed computer state in a Postgres database running in the customer's environment, and a reconciler works to bring the two together. The company says this is meant to cope with dropped connections, provider throttling and restarts that happen after a request succeeds but before the response arrives.

The first customer deployment was a bespoke on-premises environment with an in-house provider interface. Factory says it started a Mission to build the initial driver just before boarding a flight to meet the customer, and the driver was built by the time it landed. After two days on-site, the customer provisioned its first sandbox through OpenCompute, running in its own data center. Factory puts the time from early prototype to that deployment at six weeks, and says persistence, recovery, deployment tooling and operational hardening continued afterward.

What it means for customers

For organizations that cannot or will not run agents on a vendor's cloud, OpenCompute is meant to offer managed-style provisioning on their own runtime. Factory says the experience looks like creating a managed Droid Computer, even though the sandbox runs in the customer's data center. Access is currently limited to a private preview, and the source gives no details on pricing or general availability.