The software factory is not a new idea
The term dates to 1968, when computer pioneer Bob Bemer raised the software factory idea in his paper The Economics of Program Production. He is generally credited as its earliest proponent (Bob Bemer, Wikipedia). The context matters. 1968 was the year the industry started calling its situation a software crisis: projects were outgrowing the methods used to build them, and the answer Bemer proposed was industrial. Treat software as a repeatable, instrumented production process instead of the isolated craft of individuals.
A year later, Hitachi opened its Software Works, the first facility explicitly labelled and managed as a software factory. Michael Cusumano's research at MIT later documented how Hitachi, Toshiba, NEC, and Fujitsu ran these programs, built around standardization, reusable components, and controlled process (Software factory, Wikipedia).
So when the term returns in 2026, it is not a marketing invention. It is an old ambition finally meeting a technology that can supply the production capacity.
Why earlier factories stayed constrained
The first software factories worked by narrowing variation. They standardized tools, languages, and components so that output could be predicted and checked. That discipline was the source of their quality gains, and also their ceiling. The production capacity was still human, so the factory could only move as fast as trained people could implement within the standards.
Coding agents change that side of the equation. Addy Osmani describes the modern version as a stack of loops, harnesses, and factories: single agent tasks, the environment that runs them, and many harnessed loops operating at scale (Software Factories, Light and Dark). He distinguishes "dark" factories that ship without human review from "lit" factories that keep human judgment on design and architecture. Either way, implementation capacity stops being the scarce input.
Production capacity is not architectural control
This is where the historical comparison becomes useful rather than decorative. The factory idea was never only about output. It was about controlled production. The standards were the control. When the production capacity was human, the standards travelled through training, code review, and the people who had been in the room when a decision was made.
Agents do not inherit that channel. A fleet of agents can plan, implement, test, and open pull requests in parallel, and each one begins with whatever context it was handed. The rest of the modern factory stack does not fill the gap on its own:
| Layer | What it controls |
|---|---|
| Orchestration | Which agent does which task, in what order, with what retries and handoffs |
| Execution infrastructure | Where agents run and what they can touch |
| Testing and review | Whether the change behaves correctly and reads well |
| Architectural governance | Whether the change conforms to decisions the organization already made |
Orchestration controls the work. Architectural governance controls what the work is allowed to become. Orchestration being perfect does not stop an agent from violating an ADR, a point made in more detail in AI agent orchestration is not governance.
Why more production creates more drift
Five mechanisms compound as the factory scales:
- Every session starts incomplete. An agent sees the code and the prompt, not the reasoning behind the boundaries it is about to cross.
- Prose is interpreted, not obeyed. Two agents reading the same architecture document can reach different conclusions about what it requires.
- Parallel changes are locally reasonable. Each change can be defensible while the combination introduces duplicated abstractions and conflicting patterns.
- Passing tests hide structural violations. A direct database call behaves correctly. It is still the dependency the architecture ruled out.
- Review capacity grows slower than change volume. Human review does not scale linearly with generated output, as covered in why code review cannot scale with AI output.
None of this means every additional agent adds a fixed amount of drift. It means the mechanisms that used to catch drift were human, and they do not multiply with the fleet. Fred Brooks made a version of this argument about human teams in 1975, and it applies with new force to agents: see Brooks's Law after AI.
A concrete failure
An organization migrating off a legacy system has decided that migrated services reach customer data through an API, never by connecting to the legacy database directly. Several agents work on separate features. One of them adds a direct database query because it is the shortest path to a working feature. Tests pass. The feature works. The migration's target architecture has been quietly broken, and nothing in the orchestration, sandbox, or test layer was designed to notice.
A factory that catches this needs the decision itself to be operational: stored as an accepted decision, scoped to the code it governs, surfaced to the agent before it writes the change, and checked deterministically when the change is proposed, with a trace back to the decision that produced the verdict.
What the missing layer has to do
- Authority. Know which decisions are accepted and current, and which were proposed, rejected, or superseded.
- Applicability. Determine which decisions govern this path, component, or action.
- Context before generation. Put the applicable decisions in front of the agent before it writes code, not after review.
- Typed enforcement. Separate guidance from mechanically checkable rules, and check the rules without asking a model whether it complied.
- Traceability. Connect every verdict to the decision and rule behind it.
Not every architectural decision can become a mechanical rule. Some require human judgment every time. The point of the layer is to separate the two honestly, enforce what can be enforced, and route the rest to people.
Where Mneme fits
Mneme does not operate a software factory, and it does not replace orchestrators, execution platforms, coding agents, or review tools. It applies to one class of decision inside the factory: architectural decisions in a repository. Mneme is open source. It turns accepted architectural decisions into scoped rules and returns deterministic PASS, WARN, or FAIL verdicts (or an explicit INCOMPLETE) against proposed changes, as described in how enforcement works. Its local MCP server, shipped in 0.9.0, lets an agent retrieve the decisions that apply to a path and trace a decision's lineage, and lets agents propose new decisions that only a human can accept. See the MCP reference.
That is a narrower claim than "Mneme governs the factory." It is the part of factory governance that can be made deterministic today.
The same wall, at Netflix scale
Conductor 4.0, Netflix's workflow orchestration engine, changed one specific thing. Earlier versions loaded the complete workflow state into memory for every evaluation. Conductor 4.0 instead uses a lightweight workflow blueprint and loads only the task data the next decision needs. Netflix reports this raised the largest supported workflow from roughly 2,500 tasks to 30,000, and cut p99 evaluation latency by about 40 percent, across 200,000 workflow definitions in 150 applications executing roughly 420 million workflows a month (InfoQ).
Conductor is a workflow engine, not an architectural governance system, and this is not a claim that it solves the same problem as Mneme. The relevant part is narrower. Netflix hit a real scaling limit by treating "the state needed for the next decision" as the same thing as "the entire state," and the fix was separating the two.
A software factory running many coding agents hits the same wall with architectural context, usually before it hits it anywhere else. An agent does not need every accepted decision in the organization to make its next change. It needs the decisions applicable to the file, service, or boundary it is about to touch.
| Conductor 4.0 | Software factory governance |
|---|---|
| Lightweight workflow blueprint | Decisions retrievable by scope, not the full decision corpus |
| Loads only the task data needed next | Retrieves only the decisions applicable to the proposed change |
| Deterministic state precedence | Deterministic PASS, WARN, or FAIL verdicts, not a model's judgment |
| 150 applications, 420 million executions monthly | The scale a governance layer eventually has to survive |
Mneme's decision.applicable_to tool, shipped in 0.9.0, already works on this principle: an agent asks which decisions apply to a set of paths and gets scoped matches back, not the full decision corpus. Conductor's numbers matter less as a template to copy than as evidence that the failure mode is real. A system that has to hydrate everything to decide anything does not stay fast as the factory scales, whether what gets loaded is workflow state or architectural context.
Scaling the factory without losing the architecture
The organizations that get value from software factories will not be the ones that run the most agents. They will be the ones that can raise autonomous output without losing architectural coherence. Before scaling agent throughput, it is worth knowing which architectural decisions are already protected, which could become enforceable, and which still live only in documents and people's heads.