Factory makes reusable cloud agent environments generally available

• Factory Environments is generally available for cloud Droids, according to FactoryAI's announcement.
• Repositories, tools and dependencies are prebuilt into portable sandbox images, as FactoryAI described.
• Missions can distribute tasks across multiple sandboxes with consistent starting configurations, while FactoryAI also describes Environments as the foundation for recurring Automations.

Factory's best addition is the validated rebuild loop: images refresh every few hours, and only successful builds become baselines. The Environment docs distinguish independent instances from persistent Droid Computers, while the Automations page still labels webhook triggers private preview.

Factory's October 12 launch post announces availability across all plans. Environments succeed Cloud Templates, according to the documentation.

An Environment saves the preparation work required to clone repositories, install toolchains and configure dependencies. Factory builds that definition into an image before a Droid arrives.

Instances have separate working files. A Droid's changes do not alter the saved baseline or another instance; updating that baseline requires a rebuild, the docs explain.

Factory describes three steps in the refresh loop:

1. Rebuild Environments every few hours.
2. Validate each new build.
3. Promote only successful builds.

Missions, Factory's long-running multi-agent framework, can assign workers separate Environment instances. Factory connects that fan-out to fixing the issues that hold repositories back on its Agent Readiness scale:

• Maximum score: five, indicating full readiness for agents.
• Typical enterprise starting point: level two, according to Factory.
• Best fit for Missions: level four or above, according to Factory.

Previously, parallel remediation required several Droid Computers or multiple local repository clones.

An Environment-backed Automation starts each run in a fresh sandbox from the last validated build. Runs act as a user or service account and inherit the same policy as other Droids, according to the launch post.

The Automations product page lists four trigger types:

• Schedules.
• Slack messages.
• GitHub events.
• Webhooks, currently in private preview.

Administrators centrally manage Environments, and existing Enterprise Controls apply to cloud Droids. The launch post identifies the policy boundaries:

• Hosts a Droid can reach.
• Shell commands it can run.
• Commands requiring approval or prohibited entirely.
• Connectors and Skills it can use.

When a Droid attempts a prohibited command, the harness stops it before execution.

Factory's compute documentation separates three execution options:

| Option | What persists or gets reused |
| --- | --- |
| Environment | A prepared snapshot used to start independent cloud instances. |
| Droid Computer | A Factory-managed computer whose files and configuration survive across sessions. |
| Remote Control | Access to an existing workstation, cloud VM or on-premises machine. |

A Ready Environment can also seed a persistent Droid Computer. Remote Control connects an existing computer without building an Environment.

Despite the all-plan launch announcement, the docs qualify availability by organization rollout and compute settings. Configuration lives under Settings → Environments.

In a separate hands-on report using Boat VMs, kevinkern said always-on agents were competing for CPU and RAM on his Mac. One browser test hung locally for over an hour but completed on Boat in nine minutes for roughly two cents.

He reported an 8 GB default and a 16 GB ceiling restricted to Pro. macOS packaging and native-app tests still ran on his Macs.