To my surprise, software factories are an old story. The term has been around for more than twenty years. But with AI - and with AI factories as a much newer idea - the software factory got a V2. Both terms and practice play well together: take work that used to be craft, give it a repeatable line, and measure what comes off the end of that line. Once for AI and once with AI for software.
But we are missing one layer. Look, software factories and AI factories consume infrastructure, and they consume it in a way that "provisioning" no longer serves. The compute, network, storage, and identity underneath an agentic platform have to come off a line of their own. I think it is time to call that line what it is: an infrastructure factory.
The software factory: an older idea than it sounds
Microsoft put "software factories" on a book cover in 2004. The idea was to stop hand-crafting every application and assemble them from domain-specific languages, patterns, and tooling. It never took over the industry, but the ambition stuck.
The term came back through the US Department of Defense. Kessel Run and Platform One turned "software factory" into something concrete: a hardened CI/CD pipeline, a curated container registry, and an authorization process that moves at the pipeline's speed rather than the paperwork's. Platform engineering carried the same shape into the private sector under different names: golden paths, internal developer platforms, paved roads.
What a software factory produces is deployable software with known provenance. Its unit of output is a release: built, tested, scanned, signed, and shipped with known provenance. Its metrics are the DORA five: deployment frequency, lead time for changes, failed deployment recovery time, change failure rate, and deployment rework rate. Its customers are developers, and its promise is "you write the code, the line does the rest".
Today, agents are becoming customers too.
The AI factory: tokens as the product
NVIDIA made the term mainstream. Jensen Huang's framing is simple: raw data goes in, intelligence comes out, and the factory's output is counted in tokens, per second and per watt. Hyperscalers, sovereign cloud programs and custom service providers have adopted the vocabulary since.
For most organizations, the AI factory is not a hall full of GPUs. It is the stack that turns proprietary enterprise data and information into models and services that are then served back to the end users.
Its unit of output is not a release. It is a completed task: a stream of tokens that got a job done at an acceptable quality and an acceptable cost. The metrics are different too: cost per task, eval pass rate, tool-call success rate, latency per round trip. The customer is not just the developer or knowledge worker anymore. It is the agent, and behind the agent, the business process it serves.
A software factory optimizes for change safety. An AI factory optimizes for model quality and inference efficiency.
The infrastructure factory: the layer we keep calling "provisioning"
Both factories have to sit on something. Today that something is usually a cloud account, a Kubernetes cluster, and commonly a ticket queue. We call it provisioning, infrastructure as code, or landing zones. None of those names fully describe what the software and AI factories need.
An AI factory needs GPU capacity in units it can reason about: a model-serving slice with known memory, interconnect, and isolation, delivered in minutes, in a specific jurisdiction, with a price cap etc. A software factory needs runtime environments the same way: an ephemeral cluster per pull request, a production tenant with a defined blast radius, an identity boundary that maps to a team. Neither can be hand-built for every request as agents increasingly make those requests. And to be honest, companies with solid platform engineering practices already automate much of this. But it’s not enough.
An infrastructure factory manufactures those units. Its inputs are physical or cloud resources (racks, regions, reserved GPU pools, network fabric) and policy (sovereignty, cost ceilings, isolation classes). Its output is a catalog of infrastructure products with SLOs: "GPU slice, class B, EU-only, four hours, with a defined internal cost". Its line is Cluster API, Crossplane, Terraform, or whichever composition engine you trust, run as a product with a backlog rather than as a script somebody owns.
And then there are metrics: time to usable capacity, utilization, cost per unit delivered, and the share of requests fulfilled without a human touching them. Its customers are the software and AI factories, which need reliable, flexible, and scalable capacity. Organizations also need secure, isolated, and auditable environments for agents and the software they produce.
How the three play together
Each factory's product is the next one's raw material. The infrastructure factory delivers capacity units. The software factory turns them into environments and ships trusted releases onto them, including the MCP servers and agent runtimes. The AI factory produces models and tokens, consumes those releases through the gateway and uses capacity and tools to complete tasks.
Clear contracts between the factories matter. What do they look like?
Between the AI factory and the software factory, MCP can serve as an interface. MCP tools expose invocation schemas, while deployment, identity, versioning, and policy enforcement depend on the surrounding systems. Between the software factory and the infrastructure factory, the contract is the capacity catalog. An environment or a GPU slice is a product with an SLO, a price, and a jurisdiction, requested through an API rather than a ticket.
Identity, policy, cost telemetry, and observability run through all three, and that is where most of today's pain sits. In this model, an agent's identity can be established in the AI layer, checked at the software gateway, and linked to infrastructure usage records. In many organizations, these systems coexist without being fully integrated.
Between Infrastructure and AI Factory, the contract becomes a question of responsibility. Responsibility for this shared floor can sit with either factory or be shared between them. Does the value of the AI factory lie in the software that optimizes the token flow? Or is it in the GPU scheduling? But this might be better handled by the Infrastructure Factory.
Why three, not one
The obvious objection: isn't this all just "the platform"? Honestly, I think it could be. The case for three names is that the three lines run at different speeds, with different dependencies, on different economics, and fail in different ways.
Cadence. A software factory ships many times a day. Look at Anthropic: as its volume of merged code changes grew, it built its own source control system, Scion, to replace Git for its monorepo. An AI factory changes behavior every time a model, prompt, or tool changes, which can be hourly, but its evals and cost model need consistent baselines to be meaningful. An infrastructure factory moves in procurement and reservation cycles: GPU pools are reserved for months, regions are chosen for years.
Economics. Software factory costs include engineering time and tokens used by agents, and scale roughly with the work being delivered. AI factory costs include token spend and GPU hours, with usage a major driver. Infrastructure factory costs include capital and capacity commitments, with unit costs influenced by utilization.
Failure modes. A bad software release breaks a service and gets rolled back. A bad AI factory change degrades quality quietly and shows up as eval drift, or as a customer complaint a week later. An infrastructure factory failure is a cliff sliding into the ocean: usually if your infrastructure lets you down it can disrupt multiple dependent services, affecting business operations, revenue, and customer satisfaction.
What the job looks like
Factories change the shape of work before they change the headcount. The pattern is familiar: more execution shifts to agents, while people move toward designing the process. The person who used to run the pipeline now designs the pipeline. The person who used to deploy now defines what "deployable" means.
In a three-factory world, the roles look roughly like this:
- Infrastructure factory: a capacity product manager who owns the catalog, the SLOs, and the internal cost model; a fleet engineer who keeps the composition engine and the hardware pools honest; and a platform engineer with teeth who implements automations and boundaries. Fewer people than today's infrastructure teams, each with a wider blast radius.
- Software factory: the platform engineer as we know it, with a new emphasis on supply-chain integrity, because a growing share of the code arriving at the pipeline was written by agents. "Who authored this" becomes "which agent, with which context, under whose review".
- AI factory: an AI platform engineer for serving, routing, and the gateway; an evaluation engineer who owns the eval sets and the quality bar; a context engineer who decides what the agent sees and why; and agent operators who run fleets of agents the way SREs run fleets of services.
What is similar to all three layered roles is that every role spends more time on contracts and less on execution: schemas, SLOs, policies, catalogs. And the worker on the line is increasingly an agent. Humans design the line, set the tolerances, and step in when the line drifts. That is the foreman's job, not the assembly worker's, and it needs an engineer who can read a trace, a cost report, and a policy document in the same hour.
For individuals, the practical advice is unglamorous. Learn the seams: MCP, the gateway, the capacity catalog. Learn to write an SLO and an eval. Get comfortable being accountable for output you did not personally produce.
So, is it a factory's world?
Partly. Factories win wherever the work is repeatable and the demand is high, and agents are turning both software delivery and inference into exactly that. The infrastructure underneath has no choice but to follow.
But a factory is only as good as the people who design it. The three layers concentrate engineering judgment in fewer places with higher stakes. The organizations that will do well are the ones that name all three lines, give each an owner and a metric, and get the seams right.
Call the third one an infrastructure factory.
Share
Author
