Inside the software factory, and what it takes to build one

A software factory is a managed model for producing software with repeatable inputs, standardized tooling, and measurable output. The idea is older than most people expect. Robert Bemer, working at General Electric, was writing about a "software factory" in the late 1960s (the IEEE Computer Society keeps his record), and in 1969 Hitachi opened the first facility actually run and managed as one, the Hitachi Software Works. Michael Cusumano later documented how Japanese firms industrialized software this way in his 1991 book Japan's Software Factories. The through-line across those decades holds. Scoped work enters the system, validated changes leave it, and every step in between is observable and reproducible.

The model is now increasingly agent-native. Software development agents (called Droids in Factory's case) participate in the work itself, taking standardized inputs and producing validated changes across coding, review, testing, and deployment. Engineers define intent and review the resulting trace. The factory stays the same. Only the set of actors operating inside it changes.

"Software factory" is the concept. "Factory" is the company and product that implements an agent-native version of it. This guide explains how Factory defines a software factory, how the agent-native variant differs from earlier implementations, and how enterprises such as Chainguard, Groq, Empower, and Nav operate their software factory using the Factory platform.

How Factory defines a software factory

Factory's own definition is a continuous feedback loop, not a static pipeline. In Factory 2.0, Matan Grinberg and Eno Reyes describe a system that starts with signals from the outside world (bug reports, internal conversations, customer feedback, business requirements), triages them into planned changes, then builds, tests, reviews, secures, ships, and monitors those changes. Monitoring the deployed software produces new signals, and the loop runs again.

Factory names three requirements for a robust software factory. Model independence lets an organization pick the model that fits each task by cost, performance, and speed, or let a Router choose. Sovereign intelligence means you own the system and the capability it accumulates, so every agent session, code review, and resolved incident feeds back into your loop and stays inside your walls. Continual learning means every stage of the SDLC runs instrumented on one platform, so a security finding can inform a review and an incident can be traced to the change that caused it.

How to tell a software factory is working

The loop is the definition. Four observable properties tell you whether a given implementation actually delivers on it. The first is standardized inputs, where every unit of work enters with the same shape, carrying its scope, acceptance criteria, owner, and target environment. The second is standardized tooling, where a human-authored change and an agent-authored change pass through the same gateway, evaluations, and release controls.

The third is measurable output, where cycle time, defect rate, regression coverage, and cost per change are reported per pipeline rather than estimated after the fact, which is what Factory Analytics exists to do. The fourth is replayability, where any shipped change can be reconstructed from its inputs, prompts, model versions, and policies, which is what Factory's audit and monitoring model and OpenTelemetry export guarantee.

None of this is prescriptive. A team can satisfy all four with custom tooling, with an off-the-shelf platform, or with some mix of the two.

How the agent-native variant differs

Earlier software factory implementations standardized the pipeline but left execution to humans. CI/CD, code review templates, and platform engineering tooling reduced variance at the boundaries of the work without changing who did the work.

The agent-native variant changes the actor inside the pipeline. A software development agent accepts the standardized input, executes the multi-step task, and emits the standardized output (typically a pull request, an updated artifact, or a passing CI run). The pipeline itself stays the same, which is what allows enterprises to adopt the model incrementally rather than replatforming. Factory's missions reference describes one implementation of this for multi-day, multi-feature work.

The implication for throughput is direct. The factory's capacity is no longer bounded by the number of engineers available to do the work. It is bounded by the rate at which the team can define intent, review traces, and approve releases.

Production examples

Factory reports that software factories are already in production across large organizations including NVIDIA, EY, Adobe, Palo Alto Networks, Adyen, Blackstone, Wipro, and Comarch, per the Factory 2.0 announcement. Four of those deployments have published detailed outcomes. Chainguard ran a single two-week Droid session across six repositories and built 80 packages. Groq uses Factory's model-agnostic agents for day-0 model launches, and reports 3x faster medium-complexity feature development alongside 5x faster quick-turn tasks. Empower cut incident response time by 40%, PR-to-approval time by 50%, and product-to-engineering Q&A delay by 50%. Nav doubled feature development velocity and reduced context-switching by 60% while preserving the compliance requirements its fintech customers depend on.

The full library is at Factory case studies.

Surfaces and integrations

An agent-native software factory has to run inside an enterprise's existing surfaces rather than replace them, and Factory exposes the same Droid across all of them. The Droid CLI handles terminal and CI/CD work, including headless execution and ready-to-use GitHub Actions. The same Droid runs in the IDE integrations such as JetBrains and Zed, and in the Slack and Linear workflows teams already use.

Model choice stays open through Bring Your Own Key, which supports OpenAI, Anthropic, Google Gemini, Groq, Fireworks, Baseten, and others.

Inside the product, the surfaces engineers touch most are Code Review and Analytics, with Autowiki and the Desktop app alongside them.

Building a software factory in house, or outsourcing delivery

Most engineering organizations face one practical decision: build and own a software factory in house, or outsource delivery to agencies and contractors. Factory's published position is that the factory is something you own. Sovereignty there means owning a system that learns from itself, where every agent session, code review, and resolved incident feeds back into the loop and the accumulated capability stays inside your walls. Outsourced delivery still produces software, but the context and the compounding improvement leave with the vendor. This is also where the model departs from DevOps and platform engineering, which standardize the pipeline and the developer experience but leave the work itself to whoever you hired to do it.

Owning the factory changes the engineer's job. Engineers stop being the sole authors of the software and take responsibility for the system that builds it, including its governance, safety, and business outcomes. The payoff is that the factory gets more capable the more you run it, and that capability is yours to keep.

Building in house carries real cost at every stage of the SDLC, and each stage has its own failure mode. It begins with signal intake, where bug reports, customer feedback, and internal requests arrive in inconsistent shapes, and the hard part is turning noisy signals into well-scoped work without creating a human bottleneck at the front door. Planning comes next, and decomposing a request into changes an agent can execute depends on accurate, current context about the codebase, so stale context is the most common cause of bad plans. During the build, long-horizon tasks drift, and holding an agent on scope across many steps takes guardrails, memory, and explicit acceptance criteria. Test and review have to apply the same standard to agent-authored changes that they apply to human ones, now at higher volume. Security widens with every additional change, so analysis has to run inside the loop rather than as a final gate. Shipping and monitoring close the loop, because deployments and the incidents that follow become the signals that start it again, and the real work is instrumenting that feedback so the factory learns instead of repeating mistakes.

Factory's case is that these stages should share one platform, so a security finding can inform review, a deployment can trigger a documentation update, and an incident can be traced to the change that caused it. Deployment reference architectures are in the network and deployment guide.

Compliance and governance. Enterprises operating a software factory typically have requirements that constrain how agents can act. Factory's enterprise documentation covers the full set of controls, from identity and access management, SSO and SCIM provisioning, and service accounts for CI/CD, through to LLM safety and agent controls, privacy and data-flow rules, and EU deployment options.

Factory holds SOC 2 and ISO 42001 certifications and complies with GDPR. The full posture is summarized on the security page.

A typical adoption sequence

Most teams adopt the agent-native software factory model in three stages, each of which is independently useful.

1. Scoped delegation in the IDE. Start by delegating well-defined tasks from the Droid CLI quickstart or an IDE integration. This produces measurable cycle-time improvements without changing release processes.
2. Automated review on pull requests. Add Factory Code Review or set up Droid GitHub Actions to score and review changes. This applies the standardized-tooling property to review.
3. Multi-day missions in CI/CD. Move to Factory Missions for multi-feature work that previously required a project plan and multiple engineers. This is where the throughput characteristics of the model become visible.

Each stage compounds on the previous one because the artifacts produced (traces, evaluations, review history) feed back into the inputs for the next.

Further reading

• The architecture of a software factory
• The software factory platforms worth comparing
• How enterprises actually automate software development
• Factory enterprise overview

The software factory model is several decades old. The agent-native variant is recent and still evolving, but the properties that define a software factory remain the same: standardized inputs, standardized tooling, measurable output, and replayability.