Three Factories. One Missing Layer.

Ask three people what an AI factory is and they may describe three different buildings.

A data-center architect sees racks, accelerators, networking, cooling, and power. A machine-learning lead sees data preparation, training, evaluation, registries, and deployment. A software leader sees requirements entering one end and tested code leaving the other, with agents doing more of the work between them.

All three descriptions are legitimate. They are also incompatible enough to derail an architecture review. They have different raw material, machines, bottlenecks, unit economics, and definitions of a finished good.

The useful question is therefore not, "Do we need an AI factory?" It is:

What does this factory consume, what does it produce, who controls the line, and what evidence leaves with the output?

This article answers that question, maps the emerging software-factory landscape, and explains the position OpenFactoryAI is choosing. Because this is OpenFactoryAI's own publication, we describe OpenFactoryAI first in the landscape below. That ordering is disclosure, not a market ranking. Product descriptions for Factory and 8090 come from their published documentation and are current as of July 2026.

The short answer: follow the finished good

The factory metaphor becomes precise when the output is precise.

Factory type	Raw material	Production system	Finished good	Governing unit
Compute factory	Power, chips, model workloads	Accelerated clusters, schedulers, networking, cooling	Available training or inference capacity	Useful accelerator-hours, tokens per second, cost per token
Model factory	Data, feedback, compute, research hypotheses	Training, post-training, evaluation, registry, deployment	A versioned capability that clears an evaluation bar	Quality at a declared cost, latency, and risk threshold
Software factory	Business intent, code, context, policies, feedback	Humans and agents planning, implementing, testing, reviewing, deploying	A running change that satisfies intent	Cost and lead time per verified outcome

These factories can be nested. A software factory rents model capability from a model factory. The model factory rents compute from a compute factory. A vertically integrated company may own all three. The layers still exist even when one balance sheet hides the contracts between them.

Confusion starts when a team borrows the metric from one factory and uses it to govern another. Tokens per second can tell an inference operator whether a GPU is busy. It cannot tell a product owner whether the correct feature shipped. Benchmark accuracy can tell a model team whether a version improved on a dataset. It cannot prove that an agent had permission to edit a production migration.

The unit must move with the finished good.

Type one: the compute factory manufactures capacity

At the physical end, an AI factory is a data center organized around accelerated computing. Electricity enters. Workloads are scheduled. Heat leaves. The saleable product is capacity with defined performance, availability, locality, and cost.

This factory's engineering questions are physical and operational:

• Can the power and cooling system support the rack density?
• Can the interconnect keep expensive accelerators fed?
• Can scheduling raise utilization without destroying tail latency?
• Can the serving engine fit more useful work into high-bandwidth memory?
• Can failures be isolated without restarting a large job?

Calling this system a factory is useful because idle inventory is visible. An accelerator drawing power while waiting for work is a machine standing still. A request rejected after queueing is partly manufactured waste. A cache hit is avoided production.

But the output is still capacity, not a business decision or a merged change. The compute factory can promise that a model ran. It cannot promise that the surrounding workflow selected the right model, assembled valid context, used tools safely, or produced an acceptable outcome.

Type two: the model factory manufactures a versioned capability

The next factory turns data, feedback, compute, and research decisions into model behavior. Its line includes dataset construction, pretraining or adaptation, post-training, safety work, evaluation, versioning, and deployment.

Its finished good is not "intelligence" in the abstract. It is a specific model or policy with a measured capability envelope. The honest production label would include:

• the tasks and populations on which it was evaluated;
• the quality and calibration observed there;
• the latency and serving cost at a named configuration;
• the safety and robustness tests it cleared;
• the conditions where the measurements should not be extrapolated.

This factory is also where a common category error begins. A higher model score is treated as a higher automation score. The two are related, but the wrapper matters enormously.

The NeurIPS 2024 SWE-agent paper is a clean demonstration. The researchers changed the agent-computer interface, including the commands, feedback, file viewer, search, editing, and context management available to the model. On their reported setup, those system choices materially changed issue-resolution performance without changing the underlying model weights.

That result does not prove autonomous production software engineering. It proves a narrower and strategically important point: model capability is only one machine on the line. Interface, state, tools, context, tests, and stopping rules change what the complete system can produce.

Type three: the software factory manufactures verified change

The software-factory idea did not arrive with language models. Michael Cusumano's 1989 historical study documented earlier attempts to industrialize software through standardized tools, process control, reuse, measurement, and quality systems. His later work described a shift from simple scale economies toward economies of scope, where reusable design and production systems support multiple kinds of output.

Agents change the labor mix, not the underlying production problem.

The raw material is intent, but intent arrives incomplete. Requirements conflict. Architecture constraints live in people's heads. Repositories carry old decisions without their rationale. Tests cover what someone anticipated. Production sends back signals in a different vocabulary from the plan.

A modern software factory therefore needs more than a code generator. It needs a controlled flow across at least these functions:

1. Capture and refine intent.
2. Make architecture and policy constraints explicit.
3. Decompose work into bounded jobs.
4. Give agents the correct tools and context.
5. Execute changes in isolated environments.
6. Verify syntax, behavior, security, policy, and intent.
7. Record decisions, provenance, and approvals.
8. Deploy, observe, and route feedback back into the next cycle.

The finished good is not a patch. It is a change that a defined authority is willing to ship, carrying enough evidence for someone else to understand why.

This distinction matters because modern coding benchmarks deliberately choose executable tests as a tractable verifier. SWE-bench, for example, builds tasks from real GitHub issues and merged pull requests, then checks whether a generated patch applies and passes repository tests. That is much closer to software work than a small standalone coding puzzle.

It is still a bounded proxy. A test suite does not automatically verify business intent, licensing, privacy, operational readiness, or maintainability. The benchmark paper itself describes a dataset concentrated in Python repositories. A factory must know where its verifier ends.

The current software-factory landscape

Three positions are especially useful to compare because they expose different control points. The rows below describe published product intent, not independently audited capability.

System	Position in the line	Published center of gravity	Primary artifact or control point	Proof boundary
OpenFactoryAI	Outside and across the production line	A standard and certification ladder for agent-built software	Recorded judgment, credential, provenance, and eventually artifact-level proof	Intentionally independent from the factory that generated the work
Factory	Inside the execution and operations line	Model-independent agents, orchestration, quality gates, signals, operations, and governed deployment	Agent missions and automation spanning signal to production	Product documentation describes auditable actions, human-written rules, validation gates, and governance inside its platform
8090 Software Factory	Upstream and across collaborative SDLC orchestration	Shared context connecting requirements, architecture, implementation work, tests, and feedback	Requirements, blueprints, work orders, tests, feedback, and a knowledge graph	Product documentation emphasizes explicit decisions, synchronized context, and reviewable artifacts inside the workspace

OpenFactoryAI: make the bar external and checkable

OpenFactoryAI starts from a conflict of interest. The system that produced an artifact should not be the only system asserting that the artifact is trustworthy.

Today, the external authority is usually a person. A senior engineer reads a change, reconstructs enough context to judge it, and puts a name on the approval. That works at low volume. It becomes a queue as agent output grows, and much of the judgment disappears when the reviewer leaves.

Our proposed dependency ladder is:

1. Certify the engineer. Capture whether a person can direct, correct, and check agent work against a real standard.
2. Certify the agent. Evaluate an agent against a bar grounded in demonstrated human judgment.
3. Certify the code. Attach checkable evidence to an artifact so trust travels with the work.

Only the first rung should be described as live today. The later rungs are the direction of the system, not finished-product claims.

This makes OpenFactoryAI different from another coding agent or orchestration surface. Its intended output is proof about production, issued across a boundary from production. If that separation disappears, the product loses the information value it was meant to create.

Factory: connect agents, controls, and operations inside the line

Factory's Software Factory documentation describes a broad execution system: model independence, deployment from SaaS through air-gapped environments, single agents through multi-day missions, signal-to-action routing, quality gates, operational knowledge, and governance.

Its published destination is a flow from signal to production in which engineers set intent and manage portfolios while the system executes more of the cycle. Its governance language puts human-written rules, repository risk tiers, validation gates, command policies, least privilege, and audit trails inside the platform.

That is an inside-the-line control position. The platform coordinates machines and constrains their actions. OpenFactoryAI's proposed distinction is not that internal controls are unnecessary. They are essential. The distinction is that internal controls and external sign-off answer different questions:

• Internal control asks, "Did the line follow its configured process?"
• External proof asks, "Why should another party trust the process and this result?"

A mature system may need both.

8090: keep intent and implementation synchronized

8090's introduction frames its Software Factory as an AI-native SDLC orchestration platform for product managers, designers, engineers, and QA. Its modules move from requirements to blueprints and work orders, then use validation and feedback to close the cycle. A shared knowledge graph is presented as the mechanism that keeps artifacts synchronized when requirements or constraints change.

This is a context and coordination control position. It attacks a failure that becomes more expensive when code generation accelerates: the code, requirement, and architecture can drift in different systems while each local artifact still looks plausible.

OpenFactoryAI shares the diagnosis that tacit intent is dangerous. Its distinct bet is that synchronized context still needs an independently checkable bar. A perfectly synchronized record can prove what happened. It does not by itself prove that the approved bar was sufficient or that the approver was qualified.

Why we chose this position after building below it

OpenFactoryAI did not begin as a diagram of a certification market. The position came from building lower layers and watching the unresolved questions move upward.

jusCode exposed the economics and routing problem: developers want capable inference without binding every task to one model or paying the frontier price for mechanical work. jusInfer pushed the workload question further: agentic jobs and interactive cowork have different latency, context, routing, and reliability needs. Those systems teach a hard lesson. Better inference can make more attempts affordable, but affordable attempts are not the same as trusted outcomes.

Product discovery interviews with solo founders, builders, and power users added the human side. We treat those conversations as discovery, not a representative survey. We do not publish a fabricated sample size or pretend they estimate the whole market. The repeated design pressure was nevertheless useful: power users want more autonomy, but the cost of checking, recovering, and accepting responsibility rises with it.

That is the gap above inference. Once the model can act, someone needs to define what acceptable action means. Once a swarm can produce changes, someone needs to resolve conflicting changes. Once tests pass, someone still owns the business consequence.

India already ran a human software-production system at enormous scale

India gives this argument unusual historical texture. Long before generative AI, Indian firms organized large flows of software and IT-enabled work across customers, time zones, contracts, quality systems, and delivery centers. It is reasonable to study that system as a human software-production network.

It is not reasonable to turn the metaphor into an unsupported ranking.

The Software Technology Parks of India Annual Report 2023-24 reports INR 943,312.66 crore in exports by STPI-registered IT/ITeS units for FY 2023-24, up 11.18 percent from INR 848,398 crore the previous year. Karnataka alone accounts for INR 409,095.04 crore in the state table, about 43.4 percent of that STPI-reported total.

Those are large, primary-source numbers. They still do not prove that India is "the world's largest outsourced human software factory." The report covers STPI-registered IT/ITeS exports, not a harmonized global measure of outsourced software-development labor. Countries classify software, business-process work, captive centers, product engineering, and cross-border delivery differently.

The defensible conclusion is narrower and more useful: India has operated one of the world's largest export-oriented software and IT-enabled production ecosystems, with enough duration and scale to study its coordination mechanisms and failure modes.

What can an agent factory learn from the human one?

Decomposition creates interfaces, and interfaces create loss

Large outsourced programs learned to divide work into statements of work, tickets, modules, review gates, and service levels. Decomposition makes parallel work possible. It also loses intent at every handoff.

Agents intensify the same tradeoff. A clean work order can isolate context and lower cost. An over-decomposed plan can produce locally correct patches that do not compose. The factory must measure integration failure, not only task completion.

Process memory must survive employee memory

Delivery organizations invested in documentation, configuration management, reusable components, training, and quality systems because turnover and scale make purely tacit coordination impossible.

An agent's context window is an even more fragile form of employee memory. It can disappear after a run, omit the reason behind a constraint, or be reconstructed differently on retry. Durable provenance and explicit state are production infrastructure.

Quality functions need authority independent from throughput

When the same manager is measured only on output volume, quality gates become negotiable. Agent factories face a sharper version because generation throughput can grow much faster than review capacity.

The verification function needs the authority to stop the line and evidence that cannot be rewritten by the line after the fact. That does not require an external vendor for every check. It requires architectural separation between producing a claim and accepting that claim.

Labor arbitrage eventually becomes system design

Cost advantage starts a production ecosystem. Enduring advantage comes from repeatability, specialization, tooling, domain knowledge, customer context, and the ability to recover from exceptions.

The same will be true for AI automation. Cheap tokens are labor arbitrage at the machine layer. They are available to every competitor. The durable advantage is the operating system around them: context, routing, state, verification, feedback, and a trustworthy relationship with the person who bears the outcome.

The boundary every factory must draw

Draw one horizontal line through the architecture. Below it are components allowed to produce the work. Above it is the authority allowed to accept the work.

For a low-risk internal script, the acceptance authority might be an automated test suite plus a repository owner. For a payment change, it might require policy checks, staged deployment, reconciliation, and a named approver. For safety-critical software, an independent verification organization and regulatory evidence may be required.

The line moves with risk. It should never be invisible.

Every artifact crossing it should answer five questions:

1. Provenance: What model, tools, context, codebase state, and policy produced this?
2. Intent: Which requirement and constraint was it meant to satisfy?
3. Evidence: Which tests, evaluations, security checks, and reviews actually ran?
4. Authority: Who or what was permitted to accept this class of risk?
5. Recovery: If the evidence was wrong, can we identify impact, reverse the action, and learn?

These questions are independent of whether Factory, 8090, an open-source agent, or an internal platform runs the line. That portability is the point of an external standard.

A decision guide for architects

Before buying or building an AI factory, fill in this table with nouns and numbers from your own system.

Decision	Weak answer	Production answer
Finished good	"AI-generated code"	A deployed, observed change tied to a requirement and acceptance record
Unit of cost	Tokens or seats	Total cost per verified outcome, including retries, tools, review, and failures
Control point	One agent prompt	Explicit state, tool permissions, routing, stop rules, and recovery semantics
Quality	The model is strong	Named checks with coverage, thresholds, and known blind spots
Authority	A green check appeared	A policy says who may accept this risk, and the decision is recorded
Feedback	Users will report bugs	Production signals map back to the requirement, trace, and responsible owner

Then choose the factory you actually need:

• If accelerator scarcity, utilization, or sovereign capacity is the constraint, start with the compute factory.
• If your domain lacks a capable or economical model, start with the model factory.
• If capable models exist but work stalls between intent and production, start with the software factory.
• If the software factory can produce faster than the organization can trust, start with the proof boundary.

Most organizations will eventually operate all four concerns. They do not need to buy all of them from one company.

The metric that keeps the metaphor honest

A factory is not mature because it contains many agents. It is mature when it can increase throughput while holding quality, traceability, recovery, and unit economics inside declared limits.

The metric we will use through the rest of this series is cost per verified outcome.

That denominator forces the layers to meet. Compute cost matters. Model quality matters. The agent loop matters. Human review matters. Failure loss matters. An outcome counts only when the acceptance rule says it counts.

The next article follows one request through those layers, from user intent to inference, tools, verification, and committed result. That is where the three factories stop being metaphors and become one trace.

Builder playbook

1. Name the output. Replace "AI transformation" with one observable finished good such as a reconciled invoice, resolved ticket, or deployed change.
2. Draw the production boundary. Mark every component allowed to generate or modify work.
3. Draw the acceptance boundary. Identify who sets the bar, who runs the checks, and who can stop the line.
4. Price the whole outcome. Include model calls, tools, retries, waiting, review, exceptions, and recovery.
5. Run an exception drill. Inject one stale requirement, one unauthorized tool request, one timeout after a side effect, and one passing test that violates intent.
6. Keep the receipt. Store the trace, inputs, versions, checks, decisions, and final authority with the artifact.

If a proposed factory cannot support those six moves, it is still a demo line.

References

1. Michael A. Cusumano, The Software Factory: A Historical Interpretation (IEEE Software, 1989). A historical account of software-factory concepts before generative AI.
2. Michael A. Cusumano, Shifting Economies: From Craft Production to Flexible Systems and Software Factories (Research Policy, 1992). Connects reusable production systems to economies of scope.
3. John Yang et al., SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering (NeurIPS 2024). Shows why the interface and runtime around a model materially affect agent performance.
4. Carlos E. Jimenez et al., SWE-bench: Can Language Models Resolve Real-World GitHub Issues? (ICLR 2024). Defines an execution-based repository benchmark and its important scope limitations.
5. Microsoft Research, AutoDev: Automated AI-Driven Development (2024 preprint). An early architecture for autonomous planning and execution in a controlled software-development environment.
6. Factory, Build Your Software Factory. First-party description of Factory's product surfaces and governance model, checked July 2026.
7. 8090, Welcome to Software Factory. First-party description of 8090's requirements, blueprint, work-order, validation, and knowledge-graph approach, checked July 2026.
8. Software Technology Parks of India, Annual Report 2023-24. Primary government source for the export figures used above.
9. Reserve Bank of India, Annual Survey on Computer Software and ITES Exports FAQ. Defines the scope and statistical purpose of RBI's software-services export survey.