What Factory is, in its own words
Factory positions itself as “THE INDUSTRIAL REVOLUTION FOR SOFTWARE DEVELOPMENT” and “THE AUTONOMY STACK FOR ENTERPRISE TEAMS.” Its agents are Droids: “Give Droids a task in natural language and they plan, write, test, and ship code.” The product spans surfaces — “Terminal and IDE to collaborate. Browser, Slack, Jira to delegate. CLI to automate”, working “natively in VS Code, JetBrains, Vim, the browser, Slack, and the terminal” — and “Droids keep their knowledge across tools and platforms.” Control is explicit: a section headed “Adjustable autonomy” promises “From fully supervised to autonomous execution, you control the boundaries for edits, execution, and approvals”, and “Secure by default” with an “Explicit permission model” so you “Review every modification before it touches your codebase.” Models are not locked in — “Choose Claude, GPT, Gemini, or any model per task”, “No vendor lock-in.” Its enterprise page lists SOC 2, ISO 42001, GDPR and CCPA, SSO/SAML, dedicated compute, and native integrations with GitHub, GitLab, Jira, Linear, Notion, Sentry, PagerDuty, Slack and others. Custom Droids are reusable subagents defined as Markdown files under .factory/droids/, each with “its own system prompt, tool policy, model, and autonomy level.” (Sources: factory.ai
, factory.ai/product/droids
, factory.ai/enterprise
.)
Model choice, adjustable autonomy, subagents with their own tool policy and delegation from Slack and Jira are all there, so a feature checklist will not decide this one.
So this comparison comes down to two narrower things: who judges a handoff, and where the reasoning ends up.
The difference in one table
| Factory | Forge | |
|---|---|---|
| The agent unit | A Droid; custom Droids are reusable subagents with their own prompt, tools, model and autonomy level | A named role in a team — PM, architect, developer, tester, reviewer, researcher, writer |
| Who judges a step | The calling agent, plus you, through the permission model before a change lands | An independent management agent on every edge: pass, return with enrichment instructions, or escalate to a person |
| When review happens | Before a modification touches the codebase | Between roles, on the work product, before the next role builds on it — and again at the pull request |
| A rejected step | Re-prompt or deny the change | A new commit; the earlier attempt stays in history and git diff shows what changed |
| The record | Sessions and knowledge carried across Factory’s surfaces | A branch in your repository — spec, brief and every handoff as commits, Co-authored-by the persona |
| Models | “Claude, GPT, Gemini, or any model per task” | A routing gateway across a provider pool with priority weights and automatic failover, including self-hosted models |
| Where it runs | Factory’s platform, with dedicated compute for enterprises | Managed SaaS, or self-hosted runners on your own hardware; the toolchain is open source |
| Scope | Software development | Software delivery (most mature), plus research, content and operations |
Where Forge is different
An independent judge, not the caller’s opinion. Factory’s custom Droids are delegation targets: a lead agent invokes one, gets a result, and decides what to do with it. Forge inserts a separate management agent on the edge whose only job is to evaluate the handoff — it can pass it, return it with specific enrichment instructions, or escalate to a person. The difference shows up when the calling agent is the one that is wrong. See Multi-Agent Pipeline .
Permission and provenance are different controls. “Review every modification before it touches your codebase” answers “should this change land”. It does not answer “six months from now, why did we build it this way, and what did the reviewer object to”. Every Forge run leaves a branch holding the spec, the original brief and each role’s structured and freeform handoff as commits, authored by the persona — readable with git log by someone who was not there. See Git-Backed Audit
.
Your infrastructure, and an open-source toolchain. Self-hosted runners keep execution on your machines, and inference is routed across a provider pool you control, including self-hosted models and any OpenAI-compatible endpoint. See Bring Your Own Hardware and Multi-Provider Routing .
Not only software. The same engine, validation loop and audit trail run a research team that verifies its own sources, a content team, or an ops rotation — same mechanics, different roles. See the use cases .
The one number a single agent cannot report
Factory’s enterprise page advertises a multiple on delivery speed, a percentage cut in migration time and a percentage of on-call time saved, with no sample size, baseline or method beside them. We will not answer that with a percentage of our own. We will answer it with a count, and with where the count came from.
| Twelve weeks of Forge building Forge | |
|---|---|
| Runs dispatched | 322 |
| Handoffs judged by a management agent | 1216 |
| Sent back to their author for rework | 56 |
| Escalated to a human | 24 |
| Runs where the supervisor stopped at least one handoff | 51 |
| Runs that completed | 215 |
| Runs that failed, escalated or were cancelled | 103 |
| Median wall-clock, dispatch to finished run | 39 minutes |
| Median handoffs per completed run | 5 |
| Pull requests merged, across 7 repositories | 202 |
Where these came from. One workflow — Main Forge SDLC, the one that builds Forge — every run it made in twelve consecutive weeks, counted from the control plane’s own records. Not a sample, not a pilot, not a customer case study we cannot show you.
Forge stopped its own work 80 times. 56 handoffs went back to their author with specific rework instructions; 24 went to a person. One run in six was interrupted by its own supervisor before any human looked at it. That is precisely the review a single-agent tool leaves on your desk — here it is priced at one model call per edge, and counted.
It merged 202 pull requests across 7 repositories in the same period — roughly 17 a week, into the platform you are reading about, with a human performing every merge. Organisation-wide, agent-authored work merged at 773 of 875 opened. Forge is not a demo running beside the product; it is how the product gets built, and these are its commits.
A finished run takes about 39 minutes and 5 handoffs. Median dispatch-to-done — and inside those 39 minutes sit the reviews that stopped 80 pieces of work from reaching the next role in the state they were first written in.
Note what is missing: no productivity multiple, no saved-hours figure. Producing one would require inventing a baseline. A count of what the system did can be checked in principle; a percentage improvement over an unstated counterfactual cannot be checked at all — and a custom Droid, being judged by the agent that called it, has no edge on which a number like the 56 could even be recorded.
Ask us to walk you through the runs themselves — the branch, the handoff commits, the verdicts that sent work back, and the ones that went to a person. Every other number on this site belongs to a named run and says so: 18 sources gathered, 11 verified by direct retrieval, 4 corroborated and 2 shipped marked unverifiable, on the research use-case page .
Sources
- factory.ai — positioning, customer names.
- factory.ai/product/droids — what a Droid is, adjustable autonomy, permission model, model routing, surfaces.
- factory.ai/enterprise — integrations, compliance frameworks, support, and the ROI figures discussed above.
- Forge claims on this page link to the corresponding feature pages , which describe the mechanism in detail.