Factory AI is the company behind Droids, autonomous software engineering agents designed to take work from a natural-language task through planning, code changes, tests, and a pull request. A Droid is available interactively through Factory Desktop and the Droid CLI, asynchronously through Factory cloud and persistent Droid Computers, and programmatically through droid exec, the SDK, CI, and integrations. Factory also sells Missions for coordinated multi-agent work and enterprise controls for model access, audit, deployment, and data policy. The category is closer to an agent platform than an autocomplete editor.
- Factory is the platform. Droid is the agent that reads context, edits files, runs tools, and returns engineering work.
- Droids run locally and remotely. The same product spans a desktop app, terminal, browser, IDE, chat integrations, CI, and persistent computers.
- Specification Mode creates a review gate. Droid investigates and writes a plan before any source edit, then waits for approval.
- Missions coordinate several Droids for work that needs decomposition, specialist workers, validation, and a longer execution horizon.
- Factory is model independent. Teams can select models, use routing, connect enterprise gateways, or apply provider policy centrally.
- The enterprise purchase is governance plus execution. SSO, provisioning, audit, zero data retention, dedicated compute, and deployment options sit above the individual plans.
The short definition
Factory AI, usually styled Factory, builds autonomous software engineering agents called Droids. Give a Droid a bounded engineering task and access to a repository, and it can inspect the codebase, form a plan, edit files, run commands, execute tests, examine failures, revise its work, and prepare a pull request. The agent loop is the product core. The surrounding Factory platform supplies interfaces, model access, long-lived compute, organizational context, permissions, telemetry, and administration.
That places Factory in the delegated engineering category. An autocomplete product predicts code near a cursor. A Droid owns a task across many tool calls and hands back a result. Factory describes the path as one prompt to PR. In practice, reliable work still depends on task scope, environment quality, tests, permissions, and review. The product can carry the execution interval; a team still owns the specification and acceptance decision.
| Term | Meaning inside Factory |
|---|---|
| Factory | The company and platform: agent runtime, interfaces, model routing, context, compute, administration, and enterprise deployment |
| Droid | The software engineering agent that plans and executes work |
| Droid CLI | The droid terminal interface, including interactive and headless modes |
| Factory Desktop | The native local application for Droid sessions and computer control |
| Droid Computer | A persistent machine, managed by Factory or supplied by the customer, that a Droid can revisit across sessions |
| Mission | A longer multi-agent workflow with decomposition, workers, milestones, and validation |
| Droid Core | A separate pool of selected open-weight models available after standard plan limits are exhausted |
What a Droid actually does
A Droid is an agent harness around one or more language models. The harness decides what context reaches the model, exposes tools, records state, interprets tool calls, applies permission policy, and continues the loop. Factory supports model selection across providers, so the word Droid refers to the operating system around the model as much as the model itself.
Receive a goal
The input may be a terminal prompt, a ticket, a specification, a pull request comment, a Slack message, a scheduled automation, or a Mission milestone. Strong tasks name the desired outcome, constraints, relevant paths, and acceptance checks.
Assemble context
Droid reads repository files and configuration, searches code, inspects version control, and can use approved integrations or MCP servers for tickets, documents, and services. Organization and repository settings can add durable instructions.
Plan and act
The agent chooses tools, edits files, starts processes, runs commands, and updates its plan. Specification Mode separates investigation from source changes so the proposed path can be reviewed first.
Observe and revise
Command output, test failures, compiler errors, and diffs become new observations. The loop continues until the task succeeds, reaches a limit, requires permission, or cannot make justified progress.
Return evidence
The useful result is a reviewable change with tests, a written explanation, and often a branch or pull request. The quality of that evidence matters more than the fluency of the transcript.
Factory has published benchmark results showing that its harness can extract different performance from the same underlying models than another agent harness. Those results support a real technical point: tool design, planning, environment discovery, timeouts, and context management affect completion rates. They do not guarantee that a Droid will outperform another agent on a particular private repository. The practical test is a controlled pilot on your own tasks.
Where Droids run
Factory separates the agent from the interface. The interactive Droid CLI is the direct local surface. Factory Desktop adds a native session UI. The browser can start sessions against a repository or a Droid Computer. IDE, Slack, Jira, Linear, GitHub, GitLab, and CI integrations place assignments where engineering work already enters the system. The SDK and droid exec expose the same agent to scripts.
| Surface | Best fit | Execution shape |
|---|---|---|
| Droid CLI | Active pairing, repository exploration, local fixes | Runs from the current terminal and working directory |
| Factory Desktop | Local sessions with a graphical control surface | Uses local context and can expose the machine for remote access |
| Factory web app | Asynchronous delegation and remote monitoring | Targets cloud or registered computers |
| Droid Computer | Long jobs and durable development environments | Persistent managed or customer-owned machine |
droid exec | CI, scripts, scheduled jobs, structured output | Single non-interactive run with flags and exit codes |
| Missions | Large work with parallel specialists and validation | Coordinated multi-agent execution across milestones |
| SCM review workflow | Pull request review and automated feedback | Runs inside GitHub Actions or GitLab CI with scoped permissions |
Local and cloud are execution choices rather than separate agents. A local session can reach files, tools, credentials, and services available on the developer machine. A remote session can continue after the laptop closes and can use a stable prepared environment. Each choice moves the trust boundary. Local execution inherits the machine account unless policy restricts it. Managed execution moves code and tool traffic through the vendor environment under the selected retention and enterprise controls.
Droid Computers: persistent local and cloud environments
Droid Computers are persistent execution targets. Factory offers managed cloud computers and Bring Your Own Machine registration. A customer-owned target can be a workstation, VPS, cloud VM, or on-premises server running Linux, macOS, or Windows. The machine connects outbound through Factory relay when remote access is enabled, so the documented setup does not require an inbound port.
Persistence is the important design choice. Packages, files, services, configuration, and machine state remain available across sessions. A prepared monorepo or integration environment therefore avoids a fresh bootstrap for every task. This helps long work and reduces setup tokens, while also making hygiene more important. Old credentials, mutated databases, stale branches, and background services survive unless the operating procedure resets them.
- Managed Computers are provisioned by Factory and, according to current documentation, use a 4 CPU, 8 GB RAM environment with persistent state and idle pause or resume behavior.
- Bring Your Own Machine keeps the execution host under customer control while registering it as a remote target through the Factory relay.
- Plus and Max plans include access to Factory-managed Droid Computers. Current Pro includes local and cloud background agents, while the managed computer entitlement begins higher in the individual ladder.
- Enterprise deployment extends beyond one registered machine to hybrid, on-premises, dedicated, and data-residency configurations described in Factory enterprise documentation.
From specification to pull request
Factory’s Specification Mode is the clearest expression of its human review model. The user activates the mode in the CLI, gives Droid a feature description, and lets it investigate without changing source. Droid produces acceptance criteria, an implementation plan, a file-level outline, tests, and relevant security or operational considerations. The user can refine the proposal or approve it with an autonomy level.
After approval, Droid leaves the read-only planning phase and begins implementation. The approval menu can preserve manual execution checks or grant Low, Medium, or High autonomy. Low covers file edits and low-risk commands. Higher levels allow broader reversible or high-risk commands under policy. Approved specifications can be saved as Markdown under a project or user .factory/docs location, giving the plan a durable artifact.
| Stage | Droid responsibility | Human responsibility |
|---|---|---|
| Brief | Interpret the requested outcome and gather context | State boundaries, constraints, examples, and acceptance tests |
| Specification | Research the repository and produce a detailed plan | Correct assumptions and approve the path |
| Implementation | Edit, run tools, test, and revise | Set autonomy and respond to material decisions |
| Review | Present diff, checks, limitations, and PR material | Read the change and verify risk-sensitive behavior |
| Merge | May prepare or open the pull request under granted access | Own final acceptance and production authority |
“One prompt to PR” is therefore a workflow promise, not a claim that a single model completion contains a production change. The prompt starts an agent trajectory that may include hundreds of reads, edits, commands, and model calls. The specification gate, test environment, permission policy, and final review decide whether the trajectory is dependable.
Missions and multi-agent work
A normal Droid session has one primary trajectory. Missions add orchestration for work that benefits from decomposition and parallel execution. Factory documentation describes a Mission as a workflow that plans a larger goal, spawns specialist worker agents, validates milestones, and continues across a longer horizon. Worker and validator models can be configured separately, and Missions can run headlessly.
This shape suits migrations, broad refactors, generated coverage, documentation programs, or repeated changes across many packages. It also increases the review surface. Parallel workers can make locally coherent decisions that conflict at integration time, duplicate work, or converge on the same shared file. A validator is useful only when its checks reflect the acceptance criteria and the execution environment can reproduce them.
- Start with a decomposable goal. The work should have boundaries that can be assigned and validated independently.
- Define milestones and integration rules. File ownership, branch strategy, shared interfaces, and sequencing need explicit treatment.
- Choose worker and validator models deliberately. Expensive reasoning may belong at architecture and integration points, while mechanical workers can use lower-cost models.
- Set a spend and autonomy policy. Missions draw from the same rolling limits as regular sessions and require Extra Usage enabled. A rate-limit hit pauses the Mission.
- Review the integrated result. Passing worker checks does not prove that the combined change preserves product intent or operational safety.
Pricing and usage limits in one paragraph
As of August 2026, Factory’s public individual plans are Pro at $20 per month, Plus at $100, and Max at $200. Pro includes Desktop, CLI, SDK, cloud and local background agents, usage tracking, and the agent-readiness dashboard. Plus advertises roughly five times Pro usage and adds Droid Computers. Max advertises roughly ten times Pro usage and early feature access. Teams and Enterprise are sales-priced.
Individual usage is controlled through rolling 5-hour, weekly, and monthly windows. Standard Usage is consumed first. When it is exhausted, a user can select a separate Droid Core pool of open-weight models at no additional charge or enable prepaid Extra Usage for other models. Extra Usage has a $10 minimum and does not expire. Missions use the same rolling limits and require Extra Usage to be enabled, so an exhausted window can pause a long run.
Who Factory is for
Factory has two credible entry points. An individual developer can use Droid as a model-independent coding agent from the terminal or desktop. An organization can adopt a governed agent platform across repositories, workflows, compute, models, and interfaces. The second entry point explains the product’s emphasis on SSO, SAML and SCIM, audit trails, zero data retention, model controls, on-premises options, data residency, dedicated support, and an agent-readiness program.
| Choose Factory when | Evaluate another shape when |
|---|---|
| You want one governed Droid runtime across the SDLC | You primarily want autocomplete inside one editor |
| Model choice and centralized model policy matter | One first-party CLI already fits the team and its plan is already paid |
| Persistent managed or customer-owned computers are valuable | Every run must begin from an ephemeral, reproducible environment |
| Missions and organization-wide automation are part of the plan | The team is still learning how to review one agent session safely |
| Enterprise deployment and contractual controls drive the purchase | The need is a lightweight personal agent with minimal administration |
The fairest evaluation gives Factory the kind of work it is designed to own: a multi-file change with clear acceptance tests, a realistic environment, and enough autonomy to complete the loop. Compare it with the same task through Claude Code or another terminal agent. Measure accepted output, interventions, elapsed time, review time, limit consumption, and recovery from failure. A benchmark score and a polished demo cannot answer those repository-specific questions.
Before expanding the pilot, test the unglamorous paths. Revoke a credential during a run. Start from a dirty checkout. Break a dependency mirror. Exhaust a usage window. Reject a proposed command. Resume after the computer has been idle. Ask a second reviewer to reconstruct the change from the saved evidence. These cases show whether the platform fails in a way the team can diagnose and control. They also reveal the operational owner Factory adoption needs. A developer-tools team may own configuration and upgrades, a security team may own policy and audit, and application teams still own acceptance. Write that split down before hundreds of autonomous sessions create a shared queue with no shared operator.
Questions people ask
Factory AI is the company and platform behind Droids, autonomous software engineering agents. Droids can inspect repositories, plan work, edit code, run tools and tests, and prepare pull requests through local, cloud, interactive, and headless interfaces.
A Droid is Factory’s software engineering agent. The term covers the agent harness that manages context, model calls, tools, plans, permissions, and execution state. It can use different underlying models rather than being tied to one model provider.
Factory integrates with IDEs and ships a desktop app, yet its category is broader than an IDE. The same Droid runs through the terminal, browser, Slack, tickets, CI, an SDK, and remote computers. The agent and platform are the center of the product.
Yes. Droid CLI and Factory Desktop can work against a local repository and local tools. Factory also supports cloud sessions, managed persistent Droid Computers, and customer-owned machines registered through Bring Your Own Machine.
That is a core workflow. Specification Mode investigates and produces a plan before source changes, waits for approval, then Droid implements, tests, and can prepare the change for pull request review under the access it has been granted.
Missions are coordinated multi-agent workflows for larger goals. A Mission decomposes work, uses specialist workers, validates milestones, and can run headlessly across a longer horizon than one interactive session.
Factory is model independent. Its documentation describes models from Anthropic, OpenAI, Google, open-weight selections in Droid Core, enterprise gateways, cloud providers such as Bedrock, Vertex and Azure OpenAI, and approved on-premises endpoints.
The current public pricing page does not list a free plan. Individual plans begin with Pro at $20 per month. When Standard Usage is exhausted, Droid Core provides a separate included pool, while Extra Usage is prepaid.
Sources
Every figure above was read from these pages on August 2026. Vendors reprice without notice; if you find a stale number, tell us.