Factory Droids: What They Are and How Teams Use Them

Factory, at factory.ai, calls itself an agent-native software development platform, and Droid is the coding agent at the center of it. You give Droid a task; it reads your repository, proposes a plan and a diff, edits files, runs commands and tests, and keeps going until the work is done. The same agent runs in the droid terminal CLI, the Factory App on desktop, web and mobile, VS Code-family and JetBrains editors, and from Slack, Linear and Jira. It is not tied to one model vendor: Factory offers models from Anthropic, OpenAI, Google, xAI and several open-model labs, plus your own keys. It reads AGENTS.md, connects to MCP servers, and asks for approval according to an autonomy level you choose, from Off to High.

Factory, Droid and droids

The names overlap, so it helps to separate them. Factory is the company and the platform. Droid, capitalized, is the agent. droid is the CLI command. A custom droid is Factory’s word for a subagent: a Markdown file with its own system prompt, model and tool policy that Droid hands a focused job to in a fresh context window. Droid ships two built-in ones, worker and explorer. When people search for “Factory droids”, they usually mean the agent in general.

Around the agent, Factory sells automation for the rest of the delivery cycle under the name Software Factory: automated pull request review, security review, automated QA, an AutoWiki that writes documentation for a repository, incident response from alerts in Slack, and scheduled or event-driven automations. Missions coordinate larger, multi-feature work with an orchestrator and worker agents. Those are separate features built on the same agent.

Where Droid runs

• The CLI: install it, then run droid in a repository for a full-screen terminal session. Factory’s Droid CLI overview↗ (opens in a new tab) describes it as the same Factory runtime with project context, approvals, MCP tools, Missions and headless execution. droid exec runs one task and exits, for scripts and CI.
• The Factory App: a desktop app for Mac and Windows that shows sessions, diffs and previews of documents or live sites, with comments on individual diff lines. Cloud session sync and Droid Computers, Factory’s persistent remote machines, make sessions available in a browser at app.factory.ai and on mobile.
• Editors: in VS Code, Cursor and Windsurf you run droid in the integrated terminal and a Factory extension shares the active file, selection, open files and diagnostics. The IDE integrations page↗ (opens in a new tab) lists JetBrains IDEs through the Agent Client Protocol, as Factory Droid in JetBrains AI Chat, and a Zed extension. Any other editor works through its terminal.
• Slack, Linear and Jira: mention @Factory in Slack, assign a Linear issue to Factory, or pick Factory from the Agents menu on a Jira issue, and Droid works on a remote computer. Shared delegations run as a service account an administrator sets up; Slack direct messages run as the person who sent them. Remote Delegations is in Private Preview, while a default Slack integration is available outside it.

# macOS or Linux
curl -fsSL https://app.factory.ai/cli | sh
# or: brew install --cask droid
# or: npm install -g droid

cd your-project
droid                                   # interactive session
droid exec "summarize what this repo does"   # one-shot, read-only by default

Models

Droid is model-independent. Factory’s list of available models↗ (opens in a new tab) groups them by lab: Claude models from Anthropic, GPT models from OpenAI, Gemini from Google, Grok from xAI, and a set Factory calls Droid Core, open models such as GLM, Kimi, DeepSeek, Qwen and MiniMax. Each model lists the reasoning-effort values it accepts. You switch with /model mid-session, can use a different model for planning in Spec Mode, and can let Factory Router, shown in some places as Auto Model, pick a model per task. Bring-your-own-key custom models go in ~/.factory/settings.json and work in the CLI and desktop app; Factory says those keys stay on your machine. The list changes often, so check it rather than trusting any article’s version numbers, this one included.

AGENTS.md, and CLAUDE.md too

Droid takes its standing project instructions from AGENTS.md. The AGENTS.md guide↗ (opens in a new tab) says Droid searches from the working directory up to the git root, checks .factory/, .agents/ and .agent/ folders at each level, reads personal files from ~/.factory/, and discovers nested files such as apps/web/AGENTS.md when it reads files in that tree. It also reads CLAUDE.md as a compatible name, so a repository set up for Claude Code works without a second file. Factory asks you to create one file, not every variant, since duplicates only spend context. Examples of good files are in AGENTS.md examples.

MCP and connectors

Droid connects to MCP servers over stdio, Streamable HTTP, and the legacy SSE transport. Type /mcp for an interactive manager with a built-in registry, or script it with droid mcp add. Per Factory’s MCP documentation↗ (opens in a new tab), configuration lives in mcp.json at the user level (~/.factory/mcp.json) or the project level (.factory/mcp.json, committed with the repository), disabledTools hides individual tools from the model, and ${NAME} references keep secrets out of the file. For common apps, Connectors offer guided sign-in instead of server setup, for Linear, Jira, Notion, Slack, Sentry, Google Workspace and more.

droid mcp add linear https://mcp.linear.app/mcp --type http
droid mcp list          # connected, needs authentication, or failed
# then run /mcp inside droid to finish an OAuth sign-in

Autonomy levels and Spec Mode

Droid separates the shape of a session from how much it may do alone. Normal Mode works directly, Spec Mode is read-only planning that ends by asking you to approve a plan, and Mission Mode runs an orchestrator. Autonomy is a second setting, cycled with Ctrl+L; Factory’s Autonomy Level page↗ (opens in a new tab) defines four levels:

• Off: built-in read tools and commands your policy allows. Everything else asks first.
• Low: file edits plus low-risk commands and MCP tools.
• Medium: adds reversible workspace changes such as package installs, builds and local commits.
• High: high-risk actions such as pushes, migrations and custom scripts, unless a safety check or policy still requires approval.

Permission rules can allow, ask or block specific commands before the autonomy level is consulted, and a block has no approval path. droid exec is read-only unless you pass --auto low, --auto medium or --auto high. Organizations can cap the maximum level. Hooks, OS-level sandboxing and Droid Shield, which scans commits and pushes for secrets, sit on top.

Droid vs Claude Code, briefly

• Models: Claude Code is built for Anthropic’s Claude models, and Anthropic does not support routing it to others (Claude Code with Ollama covers the workaround). Droid offers several labs’ models, open models and your own keys, with a router that can choose per task.
• Instructions: Claude Code reads CLAUDE.md, and AGENTS.md when there is no CLAUDE.md, as explained in does Claude Code read AGENTS.md. Droid reads AGENTS.md first and accepts CLAUDE.md.
• Approvals: Claude Code uses permission modes such as default, acceptEdits, plan and bypassPermissions, covered in Claude Code auto-approve. Droid uses a mode plus a four-step autonomy level tied to each command’s risk.
• Extensions: both have skills, subagents, hooks, plugins, custom slash commands, output styles, MCP and a headless mode (claude -p and droid exec). The file names differ, so a .claude/ folder does not carry over as it is.
• Around the agent: Factory bundles review, QA, documentation and incident automations and team delegation from Linear and Jira. Claude Code concentrates on the agent itself, in the terminal, editors, the desktop app and cloud sessions.

Neither is a strict upgrade on the other. Teams that want one agent across several model vendors, or delegation from Jira and Linear, tend to look at Factory; teams standardized on Claude often stay with Claude Code. The wider field is mapped in Claude Code alternatives and Codex alternatives.

Keeping the work visible across agents

Once a team runs Droid next to Claude Code or Codex, the plan and the status of each job should not live inside any one agent’s session. fenbs is a task board that any MCP client can join: Droid would add https://fenbs.ai/api/mcp as an HTTP server like the Linear example above and sign in with OAuth, or use a token you issue under Settings with a name, scopes and an optional expiry. fenbs has no Factory-specific setup page, so treat that as the generic route. Each task carries a note, a plan and a test status in lanes To Do, Next Up, In Progress and Completed, History records which person or assistant changed what, and the Decisions and rules page holds the rules every connected assistant reads first. fenbs has no sprints, due dates or epics, and it does not replace Factory’s review or QA automations; it is where the list of work lives.