Factory AI

It best fits an engineering lead standardizing repeatable work across developers or a platform team that needs organization-wide controls. A solo developer whose Claude Code, Codex or Cursor workflow already works has less reason to switch: Factory's case is coordinating the work, not public proof that it writes better code.

What Is Factory AI?

Factory supplies the agent and the surrounding workflow, rather than a new programming language or a model you train. A pull request is the reviewable package of changes you merge into your codebase. You can work with Droid in a terminal, an integrated development environment (IDE), the Factory desktop app, or web and mobile surfaces. Factory's Droids product page describes planning, implementation, testing and pull-request creation.

As of November 6, 2026, Factory's public pages describe both individual coding sessions and an organization-wide platform: Automations for recurring work, Missions and Workstreams for orchestration, Agent Readiness for repository preparedness, and Agent Effectiveness for usage and work attribution. The evaluation here verifies public pages and docs; it includes no signed-in tests or coding benchmark.

Who Should Use Factory, and Who Should Keep Their Current Agent?

Factory fits an engineering lead who wants a consistent delegation process across developers who use different editors, or who wants to change model providers without rebuilding every workflow. It is less compelling for a founder whose existing agent already handles the repository, tests and review process with little supervision.

The shortlist is Anthropic Claude Code, a development agent; OpenAI Codex, a coding agent with local and cloud workflows; and Cursor, an editor and agent platform. The useful comparison is the operating change each purchase makes.

These are buying judgments based on the linked maker documentation, not performance rankings. Factory does not win merely by offering remote agents, parallel work or multiple interfaces.

Factory AI vs Claude Code

Factory is worth considering when you want Claude models to be one option inside a broader workflow. Claude Code is the simpler choice when your organization already has useful instructions, integrations and review practices around it. Running a Claude model inside Droid does not reproduce Claude Code: the surrounding tools, context selection and execution behavior belong to the agent product.

For example, a lead with backend developers in JetBrains and frontend developers in Cursor could introduce Factory for one shared maintenance queue. That is a coherent reason to add it. Asking everyone to switch because a different model produced an impressive demo is not.

Skip Factory for now if your main problem is vague requirements, unreliable tests or a pull-request queue nobody reviews. Those problems also constrain Droids. Keep Claude Code, Codex or Cursor while you make work easier to verify. The Codex vs Claude Code comparison covers that narrower choice; the AI coding-agent shortlist covers the broader field.

Factory AI vs Codex and Cursor Cloud Agents

Factory has the stronger fit when the requirement is a shared workflow across model providers, with the same policy and intake process across editors. That is an architectural reason to evaluate it, not evidence of higher task success. The Codex Cloud guide covers the alternative when reusable remote environments and reviewable changes already solve the problem.

Cursor's cloud agents also run in parallel, work across repositories, and build and test inside their own virtual machines. Factory therefore needs to win on your required model policy, integration behavior or deployment contract. Cursor already documents self-hosted machines, so private-network access alone is not an exclusive Factory advantage; our Cursor self-hosted agents guide covers that route. For an established Claude workflow, the Claude Code review is the closer comparison.

Factory's clearest potential team advantage is one operating layer around different models and engineering tools. Its weakest sales argument is that adding another agent automatically improves code quality. The public pages do not establish that claim.

The buying decision turns on four criteria: context quality, control over execution, continuity between interfaces, and the cost of getting a change accepted.

Factory AI Droid: Keep Your Editor, Make the Work Explicit

Factory Droid can work inside an existing editor, which makes a small pilot possible without an editor migration. In VS Code, Cursor and Windsurf, the integration supplies the active file, selected text, open files and diagnostics, the editor's error and warning messages. It also supports native diff viewing. Run droid in the integrated terminal, then use /ide to inspect the connection. Factory's IDE documentation explains the setup.

Imagine a backend lead changing how an application validates account permissions. The useful task is not “refactor auth.” It is: identify every call site, preserve the existing behavior for current users, propose the migration sequence, and identify the tests that would catch an accidental privilege change.

That description gives the agent a boundary and gives the reviewer something to reject. A large diff alone cannot show that the migration is correct.

What Does Factory AI Do With a Spec?

Factory's Spec Mode separates investigation and planning from implementation. It reads relevant context and proposes a plan before asking for approval; in the CLI, Shift+Tab switches between Normal and Spec modes. Autonomy level is a separate setting that determines which actions can proceed without another confirmation. The mode documentation makes this distinction explicit.

For the permissions migration, start in Spec Mode and require the plan to name affected files, compatibility assumptions and verification steps. Reject a plan that proposes changing access rules without explaining how existing behavior will be preserved. Approve implementation only after those decisions are clear.

A practical sequence is:

1. Ask Droid to locate the authorization entry points and relevant tests.
2. Request a plan that preserves current behavior and identifies any uncertain requirements.
3. Review the plan, then choose an autonomy level suited to the permitted work.
4. Inspect the diff and test evidence before opening or accepting the pull request.

The benefit is a review checkpoint before the agent creates a large amount of code. The limitation is that a plausible plan can still be wrong. Your acceptance criteria must include behavior, not just the presence of tests.

There is also an editor-specific catch: Factory documents that its JetBrains integration does not automatically share open files, selections, diagnostics or native Droid diffs. A mixed-editor rollout must account for that difference rather than assuming the VS Code experience applies everywhere.

Model Choice Without Rebuilding the Workflow

Factory lets you choose among model families while keeping the Droid interface and task structure. That is useful when a team wants a consistent way to delegate work but does not want every workflow tied to one model provider.

The live Factory model catalog lists, among others:

• Anthropic Claude Fable 5.1, Claude Opus 5.5 and Claude Sonnet 5.5.
• OpenAI GPT-6.1 Sol and GPT-6 Astra.
• Google Gemini 3.1 Pro and xAI Grok 4.7.
• Open models including Mistral Large 4, Kimi K3 and DeepSeek V4.1 Flash.

This is a sample of supported models, not a quality ranking or a promise that every account's policy permits every model. The Fable entries require an organization admin to opt in to Anthropic's data-retention policy; model choice still has a data-handling boundary.

Consider a queue of dependency updates. Give each candidate the same dependency change, test instructions and definition of done. Record whether it completes the update, whether checks pass, and how much reviewer intervention it needs. A model that needs less supervision may justify higher consumption; a cheaper model that repeatedly leaves broken tests may not.

The comparison should hold the task and environment constant. Changing the model, repository instructions and autonomy setting together makes the result impossible to interpret. Factory's catalog includes different usage multipliers and reasoning settings, so “the same number of prompts” is not a reliable consumption comparison.

Bring your own key (BYOK) means configuring your own model-provider credentials or compatible endpoint. Factory supports personal custom models, including local configurations, but its BYOK documentation places an important limit on portability: those personal models are available in the CLI and desktop app, not the hosted web or mobile interfaces.

The buying implication is specific. Factory can reduce the effort of changing models inside a workflow, but you still need to check that the intended model is available on the interface where the work will run. A local-model pilot does not automatically prove the web delegation path.

Desktop and Web Make Delegated Work Reviewable

Factory's desktop app is useful when the output needs visual inspection alongside the conversation. Its product page lists code diffs, documents, presentations, spreadsheets, PDFs and live websites as previewable outputs, plus comments attached to code lines or selected elements. It is available for macOS and Windows. Factory Desktop also describes session continuity across desktop, web, mobile and CLI.

For a technical founder changing an account settings page, the workflow is straightforward: describe the behavior, inspect the rendered result, attach feedback to the relevant element, and review the code changes before release. Visual feedback helps localize a request such as “this error belongs beside the email field.” It does not establish that the server rejects an invalid update or that another user's settings remain inaccessible.

That distinction matters for delegation. The person approving the interface and the person checking application behavior may be different. Ask for both the visible change and the evidence that the underlying behavior works. A convincing preview should not be the only completion criterion.

Factory connects engineering context in different ways, and the distinction matters when you buy it for a team:

• GitHub and GitLab: repository access uses Factory's Git integration, not the app connector catalog. The connector documentation makes that separation explicit. For self-hosted GitHub Enterprise Server or GitLab, the self-managed source-control guide requires Enterprise and says the configured host must resolve to a public IP. That integration is not a promise of access to a private-only server.
• Jira: assign an issue to Factory or mention @Factory to start remote work and receive progress in the issue. The Jira delegation guide specifies Jira Cloud and requires app installation and linking the site; a personal connector alone does not enable delegation.
• Linear: assign an issue or mention @Factory in a comment. The Linear delegation guide separates that agent installation from a personal connector used inside a Droid session.
• Slack: mention @Factory in a channel or send a direct message. The Slack delegation guide says channel work uses the organization's shared agent profile and service account, while direct messages use personal identity and connectors.

For a maintenance queue, the practical gain is moving from a ticket or message to a remote task without copying the request into another chat. The setup still needs the right run identity, repository credentials and compute. Connecting a tracker does not make an ambiguous ticket precise.

Remote execution introduces a second distinction: the interface where you review work is not the computer running it. Factory-managed Droid Computers are persistent environments that retain files, installed packages, services and configuration across sessions. Factory documents a separate Remote Control option for a machine you already manage. Droid Computers documentation describes both.

Persistence is helpful when setup is expensive. It also means environment state needs an owner. Factory explicitly says that rebuilding an Environment does not update a Droid Computer previously created from its snapshot. A platform lead should therefore verify the machine's state before treating a successful run as reproducible elsewhere.

An AI Software Factory Starts With One Repeatable Job

Factory becomes more interesting when Droid handles a defined queue of work without a developer manually starting every conversation. Droid Exec is its headless mode: a noninteractive command that runs a task and returns output for a script or continuous integration (CI) system. It defaults to read-only behavior; edits and broader commands require explicit autonomy settings. The Exec documentation covers output formats, working directories and isolated Git worktrees.

A good first workflow is a repository analysis that produces evidence a maintainer can check. After installing and authenticating Droid, run this from a repository:

droid exec --output-format json \
  "Identify exported functions without direct test coverage. Return file paths, the evidence for each gap, and suggested test cases. Do not edit files."

This is an example invocation, not a run performed for this review. It does not prove coverage by itself: dynamic calls, integration tests and generated code can make a simple conclusion wrong. Its output is a candidate work list for the maintainer.

The next step is to let Droid implement an approved, bounded test change on a separate branch or worktree, then run the repository's checks. Keep the acceptance check outside the agent's own prose. Your CI result and reviewer decision should determine completion.

A subtle automation wall is easy to miss: an effective command-policy ask still requires approval at High autonomy, and a one-shot job cannot collect an interactive approval. Raising autonomy therefore does not necessarily make a blocked automation run. Factory documents droid rules check for previewing policy decisions before execution. This is a configuration problem to resolve deliberately, not a reason to disable every permission check.

For larger work, Mission Mode coordinates workers and validation. It requires High autonomy or the documented unsafe override, and individual-plan Missions can pause at rate limits. Start with ordinary scoped tasks before promising unattended completion of a large migration.

Factory also supplies a broader operating layer. Automations start Droid from schedules, Slack messages, GitHub events or webhooks; guided jobs include review, QA, incident response and AutoWiki documentation. Agent Effectiveness links sessions and spend to projects, issues and pull requests. That attribution covers the systems you connect; the dashboard is not independent proof that agents caused faster delivery.

Workstreams put an orchestrator in charge of parallel agents and collect the resulting pull requests in the Factory App. There is a material rollout limit: Workstreams is beta and currently available on Pro, Plus, Max and Teams, not Business or Enterprise. A larger contract therefore does not currently imply access to every orchestration feature.

The payoff is repeatability: the same intake, permission boundary and evidence package each time. The wall is operational ownership. Someone must maintain dependencies, credentials, task scope and failure handling. The software-factory platform comparison is the next decision if that operating layer matters more than the individual coding session.

Factory AI Pricing: Buy the Workflow You Need

Factory Teams is the straightforward small-team choice when centralized billing is the requirement. Business is the relevant conversation when you need shared contractual usage, identity management or administrative policy. Do not assume that moving from an individual plan to Teams buys those controls.

Price: Pro $20/month, Plus $100/month, Max $200/month; Teams $60/month per team plus $40/month per seat; Business and Enterprise by quote, according to Factory's pricing page.

The pricing page publishes no token allowances. Its usage multiples are not guaranteed task counts or accepted pull requests. The organization-plan docs confirm that Teams has Pro Rate Limits per seat; Business and Enterprise use shared contractual limits.

There is still a documentation conflict: the individual-plan docs put managed Droid Computers under Pro, while the commercial pricing page adds them under Plus. Use the maker's pricing page for budgeting and confirm the entitlement before depending on managed compute. No cost-per-pull-request estimate can be justified from those plan multiples.

The Limitations That Can Block a Rollout

Factory's most consequential limitations concern consistency across interfaces and plans. They can stop a rollout even when an individual coding session looks good.

Editor support is not feature parity. JetBrains lacks the automatic file, selection and diagnostic sharing described for VS Code-family editors. Zed's Agent Panel does not restore previous Factory Droid sessions. A team standardizing on Droids still needs editor-specific onboarding and a plan for restoring context.

Personal BYOK does not follow you into hosted web or mobile. A locally configured model may be central to your cost or data-handling decision. That configuration is not available on every Factory surface. Validate the intended remote path before buying on the strength of a local demo.

Usage multiples do not establish dependable capacity. The individual-plan docs describe independent 5-hour, 7-day and 30-day rolling windows. A larger subscription does not turn those windows into a published token allowance or a completion guarantee. If a customer deadline depends on unattended execution, discuss contractual capacity rather than extrapolating from a short pilot. Factory's individual usage rules also say Missions pause when a rate limit is reached.

The managed-compute entitlement needs confirmation. The Pro-versus-Plus discrepancy is material for a founder expecting work to run away from a laptop. The live pricing page is the basis for the plan inclusions above; the conflicting documentation is not evidence of a free upgrade. Also check compute terms separately from model usage instead of treating “cloud agents” as a complete infrastructure allowance.

Command approval and isolation are separate controls. Factory's autonomy documentation describes approvals, while its sandbox documentation describes OS-enforced filesystem and network policies when enabled. A permitted command is not automatically harmless. Check both the execution permissions and the actual sandbox configuration for the intended workload.

Deployment Options for Regulated Teams

Factory documents Factory Managed and Factory Private, with a separate Custom Deployment discussion when neither meets policy. The key distinction is where code executes, where session content is stored and where model requests go. Those are separate decisions.

The deployment guide describes Managed as a Factory-hosted control plane with local, CI and managed-compute execution. You can route model traffic through your own gateways. Its enterprise EU deployment keeps session content and inference in Europe, while user profiles, billing and organization pointer records remain in the global US deployment.

Private puts Droid sandboxes in your VPC through OpenCompute, but the control plane is Factory-hosted by default. Both Private and OpenCompute are in Private Preview. Your team operates that sandbox infrastructure; inference and session storage follow their own settings. Do not read “Private” as a promise that every component runs inside your network.

If policy forbids a hosted control plane or outbound internet access, discuss a Custom Deployment. The airgapped deployment guide describes a dedicated enterprise build with local identity, your model endpoints and your telemetry collector. It disables Factory-bound calls, but also loses cloud-dependent features including cross-device session sync, Slack integration, readiness reports and hosted analytics. It is not a public download or the connected product with every feature preserved.

For a regulated engineering team, Factory is worth shortlisting when these deployment choices match a concrete requirement. Have the platform owner check the full data path and feature availability before making a company-wide commitment.

These limits favor a narrow adoption path. Put Factory on a workflow where the environment, model, permissions and reviewer are known. Expanding across all repositories before those choices are settled creates coordination work that can erase the benefit of delegation.

Factory AI Review: The Decision Rule

Factory earns a place when it reduces the human work required to turn a defined task into an accepted change. Model choice, multiple interfaces and remote execution are useful only when they improve that result.

Add it beside your current agent when a shared maintenance queue, cross-editor workflow or deliberate model comparison has no satisfactory home today. Replace the incumbent for that task class only after comparable work shows less reviewer effort or lower total cost without weaker acceptance checks. Skip it when it duplicates a workflow that Claude Code, Codex or Cursor already handles well.

The Monday move is a small evaluation with a lead who owns the result:

Factory is a credible candidate for this evaluation. Its documentation supports a broad, configurable agent system. It does not establish that your engineers will ship better work simply by substituting Droid for the agent they already know.

FAQ

Get the AI Business Workflow Audit Checklist through the newsletter to map the task, permissions, review owner and operating cost before expanding an agent rollout.