Factory

Factory is a software-development platform built around Droid, an AI agent that can inspect a codebase, plan changes, edit files and run development commands. Developers work with it through the Factory App, an interactive terminal interface or a headless execution mode for automation. A task can begin with a request such as tracing a failing test, implementing a bounded feature or reviewing a change, then progress through a plan, a diff and relevant validation.

The platform also includes reusable project instructions, skills, connections to external tools, repository-readiness reports and orchestration for larger efforts. The current Factory website and documentation describe these surfaces. Its broader Software Factory automation system has a distinct preview-access status, so a team should separate the coding-agent workflow it needs today from a larger rollout it wants to explore.

Droid for codebase questions and reviewable changes

Droid works with the files and tools available in its environment. The CLI quickstart begins with opening a project, starting a session and asking the agent to map the architecture before making a change. That is a practical starting point for an unfamiliar repository: locate entry points, understand the testing commands and identify established conventions before requesting an implementation.

A developer can then specify a small outcome, such as replacing inconsistent logging in one module. A useful request names the relevant boundary, expected behavior and verification step. Review the resulting diff as a normal code change. Check whether it follows existing abstractions, preserves error handling and avoids unrelated edits. An agent's explanation helps navigate the change, but the code and executed checks provide the evidence for accepting it.

The same interface can support investigation rather than editing. Ask where a particular API response is built or which tests exercise a parser. This can help a developer prepare their own change without delegating its implementation. The distinction matters for onboarding and debugging: sometimes the useful outcome is a reliable map of the system, with file references and a proposed next step.

Factory offers desktop, web and terminal surfaces, with environment and account setup differing by surface. Choose the one that fits where the repository and dependencies live. A cloud session and a local checkout may not have identical access to internal services, build tooling or configuration, even when the requested code change is the same.

Planning modes and autonomy are separate controls

Factory documents Normal, Spec and Mission modes. Normal Mode supports direct work with the enabled tools. Spec Mode investigates and develops a plan before implementation. Mission Mode coordinates a larger effort. Separately, an autonomy setting determines which actions can proceed without another approval. The interaction-mode guide explains this distinction.

That gives teams two questions to answer. First, does the task need a plan before editing? Second, which operations should the agent be able to perform while carrying it out? A design discussion about replacing a storage layer may belong in Spec Mode even if small file edits would normally be allowed. A well-defined documentation correction may need little planning while still staying within a narrow permission boundary.

Approval of a plan should be specific enough to review. It should identify the affected components, compatibility requirements and intended checks. If the implementation uncovers a missing migration requirement or a broader dependency change, revisit the plan rather than treating the original approval as unlimited scope.

Organizations can apply additional controls, and command policy can impose stops beyond a session's autonomy setting. Evaluate the effective behavior in your repository. A setting that permits more actions is an operational choice, not a statement that every proposed action is appropriate.

Project instructions and reusable skills

Factory supports an AGENTS.md project briefing for durable repository guidance. It can describe installation, development and test commands, code layout, conventions and boundaries. This lets a team put recurring context beside the source code instead of restating it in every conversation.

The most useful instructions are concrete. Identify which package contains the application, which generated files should be regenerated rather than edited, and which command validates a change in that package. Keep the guide current when the build system changes. An outdated test command can mislead an agent as easily as it can confuse a new teammate.

Skills package a repeatable procedure in a directory with a SKILL.md entry point and optional supporting materials. They are appropriate for a task with a recognizable trigger and completion criteria, such as reviewing a public API change against a team's compatibility checklist. They serve a different purpose from the general project briefing: a skill carries a particular workflow rather than every rule for every session.

For example, a team might maintain a release-note skill that inspects an approved diff, identifies user-visible changes and produces a consistent draft. The procedure can require links to the relevant change and a clear separation between resolved issues and remaining limitations. Keep private credentials and customer data out of reusable instruction files. A workflow should point to an authorized source when it needs information, not contain copies of unrelated sensitive material.

Connectors and MCP extend the available tools

Factory's connectors provide guided access to supported third-party applications. The documentation names systems such as Linear, Jira, Notion, Slack, Sentry and Google Workspace. A connected tool can help Droid understand an issue, inspect an error report or update an authorized work item. Authentication and organization availability affect what a session can use.

MCP support provides another path for custom tools, self-hosted services and direct control over server configuration. Factory documents local and remote transports and an interface for managing connected servers. A custom internal documentation service or a specialized test tool can therefore fit a workflow without being part of the managed connector catalog.

Choose tools according to the task. A bug investigation may need read access to a ticket and error logs but no ability to post messages or change production configuration. A release workflow may require a different set of actions and approvals. Connecting an application should be a deliberate grant of access, with the destination, account and intended operations understood.

External context also needs interpretation. A ticket can be incomplete, an old document can contradict the current implementation and an error sample can omit the conditions that triggered it. Ask Droid to relate the external material to the repository and preserve references. This makes the eventual change easier for a reviewer to assess.

Headless execution for recurring engineering work

Droid Exec runs a task without an interactive conversation, producing output for scripts or CI workflows. Factory documents a read-only default and explicit autonomy options for mutations and commands. It also provides output formats suitable for processing results. This surface is useful when a job should run in a repeatable environment and hand its result to an existing pipeline.

A first automation could summarize the changes in a pull request or inspect a repository for documentation gaps. Keep the job's output as a report while measuring whether the findings are useful. An automated edit needs additional decisions: where it can write, how the diff is retained and who accepts it. A pipeline should not equate a readable agent response with an approved change.

Non-interactive jobs also need a clear failure path. A command requiring human approval cannot simply wait indefinitely in a CI runner. Document the expected exit behavior and preserve logs for investigation. Use a representative permission failure during evaluation, so the team understands whether the job stops before taking an unintended action.

Give an automation a defined input and output. For a review job, specify the revision or diff to inspect and the issues it should report. For a documentation job, specify the files it may modify and the checks that must pass. That makes repeated runs comparable and helps prevent an expanding task from becoming an unreviewed maintenance sweep.

Missions, readiness and repository documentation

Factory Missions introduces orchestration for work that spans features or milestones. The documented workflow begins with collaborative planning and success criteria, then coordinates workers and validation through Mission Control. It can suit a bounded effort with multiple meaningful parts, such as adding an import flow, its error states and the tests that exercise it.

The value of that structure depends on what can actually be checked. Factory's Missions documentation emphasizes the need for an automated way to exercise the application. If a repository requires undocumented manual setup or has no reliable user-flow checks, a mission has less evidence with which to validate its output. Define checkpoints that reflect the product's real behavior rather than only whether a build completes.

Agent Readiness evaluates repository foundations such as structure, documentation and validation. Teams can use reports to identify gaps before delegating larger tasks. Treat the result as a guide to preparation. A higher score does not certify that every feature request is safe or that generated code will be correct.

AutoWiki generates browsable repository documentation, including architecture and module information, and supports refresh workflows. It can help readers navigate a codebase, but generated explanations should still be checked against important implementation details. Review where wiki content is stored and synced, especially when a private repository includes information that should remain within a particular environment.

A concrete workflow for fixing an import bug

Suppose an application imports customer CSV files but mishandles an empty date column. Begin with a reproduction file that contains no personal information and a clear expected result: an empty date should remain empty, while a malformed nonempty date should produce the existing validation error.

1. Open the repository in the chosen Factory surface and ask Droid to locate the import parser, its callers and relevant tests.
2. Use a planning request to identify how the current implementation handles empty values and which change preserves the API contract.
3. Review the proposed scope. Keep unrelated formatting, dependency upgrades and other import behavior outside this task.
4. Implement the parser change and targeted regression cases using the repository's documented commands.
5. Inspect the diff and test results, then exercise a sample import through the application if that flow is available. Accept the change through the team's normal review process.

If this type of work recurs, a skill could encode the team's import-review procedure. If it becomes a CI automation, define permissions, the input revision and the report format explicitly. These are example uses of Factory's documented surfaces; the finished import fix still depends on the repository, model behavior and the team's validation.

A useful handoff includes what changed, why the empty-value case is now handled and which checks ran. It should also disclose any check that could not complete in the task environment. That information belongs in the engineering handoff so the next reviewer can make an informed decision.

Suitable users, pricing and product limits

Factory suits developers who want to delegate codebase work while keeping diffs and checks reviewable. Platform teams may also consider its reusable workflows and governance controls when introducing agents across repositories. Teams with clear build commands, maintained documentation and meaningful tests have a more concrete foundation for evaluating those workflows.

The pricing page lists paid individual tiers, a team option and custom business or enterprise arrangements. Usage limits and access to managed computers or organization controls vary. Check current billing terms and model usage before choosing a tier; a subscription should not be assumed to permit unlimited execution of every task.

The broader Software Factory system is documented as Private Preview, with access requested through Factory. Its view of lifecycle automation, integrations and coverage should therefore be evaluated separately from an ordinary Droid session. A preview feature appearing on the website does not mean it is enabled in every account.

Factory's practical limits include incomplete project context, unavailable dependencies, ambiguous requirements and unreliable validation. More autonomy does not resolve those problems. Assess deployment, data handling and organization controls for your environment, and retain normal code ownership and release decisions. Automated work is most useful when its results are visible and a failure has a defined response.

Frequently asked questions

Is Factory only a code editor?

No. Droid is available through several surfaces, including the Factory App, terminal sessions and headless automation. The platform also documents reusable workflows, integrations and orchestration.

Can Droid plan without editing?

Spec Mode is intended for investigation and planning before implementation. Choose permissions separately so the approved execution phase has the boundaries your task requires.

Can a team bring its own tools?

Factory supports MCP servers for custom tools and services, alongside managed connectors for supported applications. Review the tool's access, authentication and effective permissions before using it in an automated workflow.

What should a first trial establish?

Complete one small repository task with a clear expected result. Review the plan, diff, checks and failure behavior, then assess setup effort and usage before extending the workflow to more repositories or autonomous jobs.