---
title: Three Factories. One Missing Layer.
slug: three-kinds-ai-factory
canonical_url: https://blog.openfactoryai.com/three-kinds-ai-factory
published_at: 2026-07-14T20:40:00.289665+00:00
author: OpenFactoryAI
tags: ai factory, software factory, coding agents, verification, india software services
tldr: AI factory is three different architectures hiding under one phrase: infrastructure that produces compute, pipelines that produce models or intelligence, and software-delivery systems that turn intent into running code. Factory and 8090 build control and execution systems inside the software factory. OpenFactoryAI is taking a different position outside the production line: define the bar, certify who or what clears it, and attach checkable proof to the result.
key_takeaways:
  - An AI factory is not one market; always identify its input, output, control point, and proof boundary.
  - Factory and 8090 both organize AI-native software delivery, but their published product surfaces emphasize different control points.
  - OpenFactoryAI is not claiming to be another code-writing agent; its intended role is independent proof and sign-off outside the system that produced the code.
  - India's software-export history is useful evidence about industrialized human software production, but public data does not justify a clean global superlative.
  - Autonomy should be purchased in units of verified outcomes, not demos, tokens, or generated lines of code.
---

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.

::figure{template=layers caption="One phrase, three production systems" items="01 Software delivery factory :: intent in, tested and operated software out | 02 Model and intelligence factory :: data and feedback in, evaluated model capability out | 03 Compute factory :: power and workloads in, accelerated inference and training out"}

## 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](https://papers.neurips.cc/paper_files/paper/2024/file/5a7c947568c1b1328ccc5230172e1e7c-Paper-Conference.pdf) 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.

::figure{template=state-machine caption="The software factory closes only when evidence returns" items="Intent :: requirement and constraint | Plan :: bounded work order | Execute :: agent and tools | Verify :: tests, policy, review | Release :: controlled deployment | Observe :: outcome and exception | Learn :: update the line"}

This distinction matters because modern coding benchmarks deliberately choose executable tests as a tractable verifier. [SWE-bench](https://arxiv.org/abs/2310.06770), 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 |

::figure{template=layers caption="Three control points in the software-delivery line" items="OpenFactoryAI :: outside proof, certification, and sign-off | Factory :: governed agent execution from signal toward production | 8090 :: collaborative intent, context, blueprints, and work orchestration | Models and compute :: rented capability below every software workflow"}

### 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](https://factory.ai/product/software-factory) 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](https://www.8090.ai/docs/general/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.

::figure{template=branch caption="Capability rises from the bottom; accountability remains at the top" items="Cheaper capable inference :: jusCode and jusInfer reduce model friction | More agent attempts :: loops act across tools and repositories | More generated artifacts :: tests and reviews become queues | More production exposure :: exceptions carry business cost | External proof :: a portable bar and named accountability"}

## 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](https://stpi.in/sites/default/files/annual-reports-documents/stpi_annual_report_2023_2024_en.pdf) 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.

::figure{template=bar caption="Exports by STPI-registered IT and ITeS units, INR crore" items="FY 2011-12 :: 226712 | FY 2017-18 :: 375988 | FY 2020-21 :: 508820 | FY 2021-22 :: 628330 | FY 2022-23 :: 848398 | FY 2023-24 :: 943313"}

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)](https://dblp.org/rec/journals/software/Cusumano89). 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)](https://doi.org/10.1016/0048-7333(92)90005-O). Connects reusable production systems to economies of scope.
3. [John Yang et al., *SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering* (NeurIPS 2024)](https://papers.neurips.cc/paper_files/paper/2024/file/5a7c947568c1b1328ccc5230172e1e7c-Paper-Conference.pdf). 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)](https://arxiv.org/abs/2310.06770). Defines an execution-based repository benchmark and its important scope limitations.
5. [Microsoft Research, *AutoDev: Automated AI-Driven Development* (2024 preprint)](https://arxiv.org/abs/2403.08299). An early architecture for autonomous planning and execution in a controlled software-development environment.
6. [Factory, *Build Your Software Factory*](https://factory.ai/product/software-factory). First-party description of Factory's product surfaces and governance model, checked July 2026.
7. [8090, *Welcome to Software Factory*](https://www.8090.ai/docs/general/introduction). 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*](https://stpi.in/sites/default/files/annual-reports-documents/stpi_annual_report_2023_2024_en.pdf). Primary government source for the export figures used above.
9. [Reserve Bank of India, *Annual Survey on Computer Software and ITES Exports FAQ*](https://www.rbi.org.in/commonman/Upload/English/FAQs/PDFs/FAQsITES03062024.pdf). Defines the scope and statistical purpose of RBI's software-services export survey.


## FAQ

### What is an AI factory?

An AI factory is a production system whose raw materials, machines, and finished good are centered on AI. The term commonly refers to one of three systems: accelerated compute infrastructure, a pipeline that trains and deploys models, or a software-delivery system where humans and agents turn intent into running software. Always identify the finished good before comparing architectures.

### How is a software factory different from an AI coding agent?

A coding agent executes part of the line. A software factory also captures intent, manages context and state, constrains tools, coordinates work, verifies results, records decisions, deploys changes, observes outcomes, and routes feedback into the next cycle. One or many agents may work inside it.

### How does OpenFactoryAI differ from Factory and 8090?

Based on their published materials, Factory emphasizes governed agent execution across the delivery lifecycle, while 8090 emphasizes shared context and collaborative orchestration from requirements through work orders and feedback. OpenFactoryAI's intended control point is outside the production line: define and certify the acceptance bar and attach checkable proof to artifacts. This is a category comparison, not a performance ranking.

### Why can the software factory not certify its own output?

The factory must run internal tests and controls, but a claim has more information value when the claimant is separated from the system that benefits from acceptance. External proof establishes who set the bar, which evidence cleared it, and who had authority to accept the risk. The degree of separation should rise with consequence.

### Is India the world's largest outsourced software factory?

India clearly operates an enormous export-oriented software and IT-enabled services ecosystem. STPI reported INR 943,312.66 crore of exports by registered IT and ITeS units in FY 2023-24. That dataset does not supply a globally harmonized ranking of outsourced software-development labor, so this article does not assert the superlative.

### What metric should an AI software factory optimize?

Use cost per verified outcome, constrained by latency, reliability, safety, and recovery targets. Tokens, generated lines, benchmark scores, and agent runs are input or activity measures. They become business value only when a declared acceptance rule confirms the intended outcome.


## Test yourself

### 1. What is the fastest way to disambiguate the phrase AI factory?

- [ ] Ask which model it uses
- [x] Identify its raw material, finished good, control point, and proof boundary
- [ ] Count how many agents it contains
- [ ] Measure only tokens per second

**Explanation:** The factory type follows what it consumes and produces. Models and agent counts do not establish the system boundary or output.

### 2. Why is a passing repository test suite not complete proof of a software outcome?

- [ ] Tests always reduce model quality
- [ ] Tests cannot execute generated code
- [x] Tests cover a defined behavior surface but may not prove business intent, permission, security, or maintainability
- [ ] Only human review can ever verify software

**Explanation:** Execution-based tests are valuable evidence, but their scope is bounded by what they encode and observe.

### 3. Which description best matches OpenFactoryAI's intended control point?

- [ ] A GPU scheduler below the model
- [ ] A model-training data pipeline
- [ ] A code-writing agent inside the line
- [x] An external acceptance standard and proof layer

**Explanation:** OpenFactoryAI's thesis is that the bar and sign-off should remain checkable across a boundary from the producing system.

### 4. What does the STPI export figure prove?

- [ ] India is definitively number one under every definition of outsourced software
- [x] STPI-registered Indian IT and ITeS exports operate at very large scale
- [ ] All reported exports are software-development labor
- [ ] Karnataka represents all Indian software production

**Explanation:** The report is strong primary evidence for scale within its stated coverage, not a globally harmonized labor ranking.

### 5. Which unit connects inference economics to automation value?

- [x] Cost per verified outcome
- [ ] Parameters per model
- [ ] Lines of code generated
- [ ] Agent messages per hour

**Explanation:** The verified-outcome denominator includes whether the work succeeded, not merely how much activity the system generated.