Factory AI Guide: Droid, Missions, Skills, and Custom Agents

Factory launched Droid into a crowded market. Claude Code, Codex, Cursor, Amp, and a dozen other agents could already read a repository, edit files, run tests, and open a pull request.

Its pitch was a droid army. Give the repetitive parts of software development to specialized agents and spend your time directing the work.

That pitch has become more literal. Droid is now the main coding agent. Custom droids handle specialized jobs. Missions coordinate several agents across a larger project. Skills package repeatable knowledge. Worktrees let agents operate in parallel without trampling over each other’s changes.

This guide explains how the current version of Factory works, how to set it up, and where it earns a place in an already crowded AI coding stack.

If you want the short answer, Factory is most interesting when the unit of work is larger than a code edit. A single bug fix looks similar in every competent coding agent. A migration with a planner, several workers, validation, shared company context, and a review trail is where Factory starts to feel different.

Updated for August 2026: I rewrote this guide around Factory’s current Droid CLI. The original departmental Droid lineup has given way to a more flexible system built around Spec Mode, Missions, custom droids, skills, plugins, native worktrees, and droid exec.

What Is Factory Droid?

Factory is an AI software development platform. Droid is the agent you run in your terminal, IDE, web browser, or team workflows.

At the simplest level, Droid behaves like the other coding agents I’ve covered. You give it a task. It searches the repository, reads the relevant code, makes changes, runs commands, and iterates on the result.

The difference is the operating system around that loop.

Factory gives the agent several ways to scale beyond one chat:

Spec Mode investigates a task and produces an implementation plan before changing code.
Custom droids are specialist subagents with their own instructions, models, and tool permissions.
Missions break a large project into milestones, send work to multiple agents, and validate the results.
Skills and plugins package repeatable workflows and load extra capabilities when they are needed.
Worktree sessions isolate concurrent changes in separate Git worktrees.
Droid Exec runs the agent non-interactively in scripts, CI jobs, and scheduled workflows.

The underlying model still matters, obviously. Factory supports multiple models and lets you select a model for a session or use separate planning and worker models. The larger advantage comes from how Factory supplies context, divides work, controls tools, and keeps the execution legible.

That distinction matters because the frontier models are available in several coding products. The harness around the model is increasingly responsible for the difference you feel.

Installing Factory Droid

For macOS, Linux, and WSL, Factory’s current installer is:

curl -fsSL https://app.factory.ai/cli | sh

Open a project and start Droid:

cd /path/to/your-project
droid

The first run opens a browser so you can sign in. Once authenticated, you land in the terminal interface.

If you have used Claude Code or Codex, resist the urge to begin with a giant feature request. Give Droid ten minutes to learn the repository first.

Analyze this repository and explain:

1. The application architecture
2. How to run the app and its tests
3. The conventions used for API routes and database access
4. The areas that look risky or poorly documented

Do not change any files.

This is useful for you, and it gives you a quick test of the agent’s retrieval. If its explanation misses an important service or invents a command, fix the project’s instructions before handing it implementation work.

You can also press ! on an empty prompt to enter Bash mode and run shell commands directly. Press Escape to return to the agent. It sounds minor, but it prevents a lot of silly back-and-forth when you only want git status or a test command.

A Good First Task

Pick a real task with a crisp success condition. A small bug with an existing test suite is ideal.

The password reset endpoint returns 500 when the token has expired.

Reproduce the failure, identify the cause, and propose a fix. Add a regression
test before changing the implementation. Run the focused test and the API test
suite when you are done.

Watch what Droid searches, which assumptions it makes, and whether it proves the fix. The quality of the final diff matters. The path it takes tells you whether you should trust it with a larger surface area.

Spec Mode: The Feature Worth Using

Spec Mode is still one of Factory’s best ideas.

When a coding agent receives a large task, it has two obvious failure modes. It can start coding too early, or it can produce a generic plan based on a shallow reading of the repository. Spec Mode forces a research phase before implementation and gives you an approval point between them.

Give it a request with the user outcome, constraints, and places worth investigating:

Add self-service account deletion.

Users should be able to request deletion from Settings, re-authenticate, and
receive a confirmation email. Deletion must be delayed for seven days and can
be cancelled during that period. Preserve records required for billing and
fraud prevention.

Inspect the existing auth, billing, background-job, and email patterns before
proposing an implementation. Do not write code until I approve the spec.

Droid explores the codebase and turns that into acceptance criteria, a technical design, expected file changes, a testing strategy, and implementation steps. You can challenge the plan while changes are still cheap.

The review is the valuable part. I usually ask questions like:

Which assumptions came from the code and which came from the prompt?
What happens if the background job runs twice?
Which data must remain for legal or accounting reasons?
How will we roll this back?
What tests prove the cancellation window works at its boundaries?

Factory can save approved specs as Markdown. I recommend enabling that for meaningful features. The spec becomes a durable record of what the team intended, and future agents can use it when the code alone does not explain a decision.

Spec Mode will not rescue a vague product decision. It gives ambiguity a nice document if you never resolve it. Treat the output as a draft from a fast engineer who has read a lot of your repository, then review it like one.

Context: Where Factory Actually Competes

Every coding agent looks brilliant in a tidy demo repository. Real repositories contain private package conventions, undocumented deployment rules, odd test commands, abandoned migrations, and six years of decisions hiding in Slack.

This is why context engineering matters more than another prompt trick.

Factory has four useful layers of context.

AGENTS.md

AGENTS.md is the stable instruction file for the repository. Put information here that should apply to most sessions:

# Project instructions

## Commands

- Install: `pnpm install`
- Development: `pnpm dev`
- Unit tests: `pnpm test --run`
- Typecheck: `pnpm typecheck`
- Production build: `pnpm build`

## Architecture

- `apps/web` contains the Next.js application
- `packages/db` owns schema and migrations
- `packages/core` contains business logic
- Route handlers should call `packages/core`; do not put business logic in routes

## Rules

- Add a regression test before fixing a bug
- Use existing repository abstractions before adding dependencies
- Never edit a migration that has reached production
- Never commit secrets or `.env` files
- Run typecheck and focused tests before declaring a task complete

Keep this file sharp. A 2,000-line instruction dump consumes attention and creates contradictions. Include the commands and constraints the agent cannot reliably infer from code.

For a monorepo, add narrower AGENTS.md files inside packages that have different commands or conventions. The nearest relevant instructions can then travel with the code they describe.

Skills

Skills are reusable packages of instructions, references, and scripts. They are a better home for a workflow that only matters during a particular job.

For example, a deployment skill could contain the release checklist, rollback procedure, verification script, and links to the relevant runbooks. Droid loads it when the task requires a deployment instead of carrying all that material in every conversation.

That is the same basic pattern I cover in my guide to Claude Skills and my enterprise skills deployment guide. The product-specific folders differ, but the important idea travels well: package operational knowledge so an agent can discover it at the moment of use.

MCP and Integrations

Factory supports Model Context Protocol servers, so Droid can reach tools and data outside the local repository. You can manage servers from the terminal interface with /mcp or through the CLI.

droid mcp add linear https://mcp.linear.app/sse --type http

MCP is useful for live systems such as Linear, Sentry, or an internal service catalog. Keep the tool surface narrow. Giving an agent 150 vaguely described tools usually makes it worse at choosing the right one and expands the blast radius of a mistake.

Factory also offers managed integrations for the places engineering context tends to live, including source control, issue trackers, documentation, communication, and observability tools. These are most valuable when a task genuinely crosses those systems. A production incident may require the code, the alert, the runbook, and the ticket. A local refactor probably does not.

Session and Organization Context

Teams also need knowledge that survives one developer’s terminal. Shared instructions, approved workflows, security policies, and integrations reduce the amount of lore each person has to paste into a prompt.

Be deliberate about what becomes persistent. A stable repository convention belongs in shared context. A guess made during debugging does not. Bad memory is worse than no memory because it arrives with inherited authority.

Custom Droids: Specialists You Control

The old Factory story described a fixed lineup of Code, Knowledge, Reliability, and Product Droids. The current system is more useful because you can create the specialists yourself.

A custom droid is a Markdown definition with a focused system prompt, a model preference, and an allowed tool set. You can keep it personal or commit project droids to .factory/droids/ so the team shares them.

Good custom droids have a narrow job and a clear output. Examples:

A migration reviewer that can read code and run checks but cannot edit files
A frontend reviewer that checks accessibility, responsive behavior, and design-system usage
A security sweeper that searches for secrets, unsafe input handling, and authorization gaps
A test specialist that receives a changed diff and writes the smallest useful regression suite

The tool restrictions matter. A reviewer rarely needs permission to deploy, push, or rewrite half the repository. Give each specialist the tools required for its job and leave the rest unavailable.

Factory can also import existing Claude Code agent definitions. That is useful if your team already has a library of specialists and wants to evaluate Factory without recreating them all.

Custom droids are still subagents. They receive a task, work in their own context, and return a result. Use them to isolate noisy work such as repository-wide search or code review. Avoid turning every five-minute task into a committee meeting.

Missions: From One Agent to a Small Team

Missions are Factory’s answer to work that spans several features, packages, or milestones.

Enter Mission Mode with:

/missions

Droid plans the project, assigns work to specialist agents, tracks progress, and validates milestones. You can configure worker and validator models, and you can run a Mission headlessly with droid exec --mission.

The best Mission tasks have separable workstreams and a shared definition of done. A framework migration is a good example:

Migrate the monorepo from ESLint 8 to ESLint 10.

Inventory every package and its current configuration. Propose a migration plan
that keeps the main branch buildable. Update packages in independent worktrees
where possible. Validate each package with lint, typecheck, and tests. Finish
with a repository-wide build and a report of any rules we had to change.

That project contains discovery, configuration work, package-level changes, and final validation. Several agents can work independently once the plan establishes shared constraints.

A one-file bug is a terrible Mission. Coordination has a cost. More agents create more outputs to review, more chances for conflicting assumptions, and more opportunities to spend tokens rediscovering the same context.

The practical rule is simple: use a normal Droid session until the task has real parallelism. Use a custom droid when you need a specialist. Use a Mission when the work can be split into multiple owned milestones with an explicit integration step.

Parallel Work With Git Worktrees

Parallel agents need isolated files. Factory supports starting a session in a native Git worktree:

droid --worktree feature-auth

Each worktree gets its own checked-out branch and working directory. One Droid can update the API while another handles the UI without both editing the same local files.

Worktrees solve file collisions. They do not solve design collisions. Two agents can still invent incompatible API contracts in perfect isolation. Give them a shared spec, define the boundary between their work, and reserve an integration pass for the end.

I also recommend keeping one agent responsible for final review. Parallel workers optimize throughput. A single integrator restores coherence.

Droid Exec: Factory Outside the Chat

droid exec runs a task, prints the result, and exits. This makes Droid useful in scripts, CI pipelines, scheduled jobs, and repository automation.

droid exec "Review the current diff for correctness, security issues, and missing tests"

You can control autonomy for tasks that need to execute commands:

droid exec --auto high "Run the test suite and fix failures caused by the current branch"

High autonomy is powerful and deserves a controlled environment. Factory also exposes an unsafe flag that skips permission checks. Keep that inside a disposable container or another isolated environment. Do not aim an unrestricted agent at your laptop and hope its interpretation of “clean everything up” matches yours.

Useful automation jobs include:

Reviewing a pull request against repository-specific rules
Reproducing a failing test and drafting a proposed fix
Updating generated documentation after an API change
Running a readiness report before a release
Triage of a well-scoped issue with a report for a human reviewer

Start with read-only analysis. Once the output is reliable, allow edits on a branch. Add pushing or deployment only after the earlier stages have strong checks and a clear recovery path.

Models, Modes, and the Harness

Factory lets you switch models with /model and select model IDs from the CLI. You can also configure a separate model for specification work.

I would avoid choosing a model by reputation alone. Test the complete system on your work. A more capable model may use fewer turns because it understands the task sooner. A smaller model may finish a routine edit faster and at a lower cost. The harness changes the result too, especially when retrieval, tools, and validation dominate the task.

Build a small evaluation set from jobs your team actually performs:

A bug with a known root cause
A feature that crosses two packages
A refactor where behavior must remain unchanged
A code review containing several seeded issues
A task that depends on an internal convention from AGENTS.md

Run the same prompts with the same repository state. Compare the final diff, tests, time, intervention count, and total cost. That tells you far more than a coding leaderboard.

Where Factory Fits

Factory is a good fit when:

Your engineering work regularly crosses code, tickets, docs, and observability systems
Your team wants shared agent workflows instead of everyone maintaining private prompt folklore
You have large tasks that can be split across agents and checked at clear milestones
You want one system for interactive coding, specialist subagents, and headless automation
You need permission controls and reviewable plans before agents make broad changes

For a solo developer fixing small bugs, Factory can feel like another capable terminal agent. Amp, Claude Code, Codex, or Cursor may fit just as well depending on which workflow you enjoy.

Factory becomes more distinctive as the organization gets larger and the work gets messier. Its best features are coordination features: shared context, specialist agents, Missions, tool integrations, isolated worktrees, and automation.

There are catches. More structure creates more configuration. Missions can spend money quickly. Integrations increase the amount of sensitive context an agent can reach. Custom agents and skills become another internal system someone has to own.

The answer is not to avoid those features. Introduce them when the work earns the complexity. Start with Droid and a clean AGENTS.md. Add one skill for a repeated workflow. Create one specialist for a review you perform every week. Try a Mission on a project with obvious parallelism.

That progression gives you a droid army you can actually command instead of a terminal full of agents creating work for each other.