Factory AI makes reusable agent Environments generally available

Factory AI has made Environments generally available on every plan. The feature packages repositories, tools, and dependencies into reusable images that can launch fresh sandboxes for Droids, Factory’s coding agents.

Before a remote coding agent can change code, it often needs to clone repositories, install toolchains, locate configuration, and complete a successful build. Cold starts consume execution time and model tokens, while parallel agents may produce inconsistent runtimes if their setup steps diverge.

Build once, start many Droids

Factory separates an Environment definition from the runtime sandboxes created from it. The definition records the required source code and software; the resulting image serves as a prebuilt template for each sandbox.

1. A team selects the repositories, tools, and dependencies its Droids need.
2. Factory builds those components into a portable image before an agent starts work.
3. The platform validates the build and promotes it after validation succeeds.
4. Each Droid receives a fresh sandbox created from the latest validated image.

Factory rebuilds Environments every few hours to catch dependency drift. Failed refreshes never become the startup image, so new sandboxes continue to use a validated build while teams investigate the failure.

Cold starts leave the workflow

Prebuilt images support Factory’s scheduled and long-running workflows by giving each task a consistent starting point:

• Automations: Recurring jobs can run on a schedule or respond to Slack, GitHub, and webhook events. Each run starts in a fresh sandbox, allowing a CI-triage webhook to begin without reinstalling system packages.
• Missions: Factory’s multi-agent framework can distribute subtasks across several sandboxes, allowing independent work to proceed concurrently.
• Agent Readiness: Factory scores each repository from one to five based on its preparation for autonomous work. The company says most enterprise customers begin at level two, while Missions perform best at level four or higher.

One policy across the fleet

Organization-level controls govern every Droid launched through a managed Environment. Administrators can configure:

• Network hosts that a Droid may reach
• Shell commands that are allowed, denied, or require approval
• External service integrations, which Factory calls Connectors
• Packaged agent capabilities, which Factory calls Skills

When a Droid submits a blocked command, Factory’s harness stops it before execution. Central enforcement gives security teams a consistent control point for fleet-wide policies and regulated deployment requirements.

Where the model pays off

Environments offer the clearest operational benefit when setup costs recur across agents or tasks, including:

• Large codebases with many independent workstreams
• Scheduled dependency updates and security audits
• CI triage and other event-driven maintenance
• Parallel fixes intended to improve a repository’s Agent Readiness score

Small local projects may gain less because defining and maintaining an Environment can cost more time than a single agent’s setup. Teams should compare image maintenance against the frequency and duration of their agent runs.

Repository quality remains a separate constraint. Tests, build scripts, documentation, permissions, and task decomposition still influence whether an agent produces a correct patch. Teams starting near Factory’s typical level-two readiness baseline may need substantial repository work before multi-agent Missions perform reliably.

From settings to first sandbox

1. Open Settings and select Environments.
2. Define the required repositories, tools, and dependencies.
3. Allow Factory to build and validate the image.
4. Select the Environment for the relevant Droid workflow, Automation, or Mission.

Factory also plans to extend Droid execution to customer-owned hardware, private clouds, and existing engineering tools. The company has not announced delivery dates for those deployment options.