What is an AI factory?

An AI factory turns requests into working AI the same way every time. The term has two meanings. One is a data center built to produce model output at scale. The other is the process that turns a team’s request into an internal tool in production, and keeps every tool it shipped running. This article is mostly about the second.

What makes either one a factory rather than a lab is repetition. A lab builds a demo once. A factory builds the tenth tool the way it built the first, with the same checks.

NVIDIA’s glossary defines an AI factory as “a specialized computing infrastructure designed to create value from data by managing the entire AI life cycle, from data ingestion to training, fine-tuning, and high-volume AI inference.” It adds: “The primary product is intelligence, measured by token throughput.”

Charlie Boyle, who leads NVIDIA’s DGX systems, said the same in a conversation WEKA published in January 2026: “An AI factory is built to create intelligence in the form of tokens.”

The second meaning sits one level up. Coding agents now write much of a company’s internal software. A factory in this sense is the line that turns a team’s request into a tool people use. It runs on the first kind of factory, or on hosted models. Its product is software rather than tokens.

Both meanings share the idea that matters. In the words of WEKA’s article, AI “stops being a scarce resource rationed to a few high-profile initiatives and becomes a shared capability that teams can build on continuously.”

Writing software got cheap. A coding agent reads a code base, edits it, runs the tests and proposes the change for a person to review. In October 2026 a coding agent wrote 243 of the 275 commits to Curiosity Studio’s main branch. One of our engineers reviewed and merged each of them.

So bought tools look different. Barry McCardel, who runs Hex, wrote in October 2026 that “a lot of software categories will effectively die over the next couple of years.” Chris Gregori put the other half plainly in January 2026: “code has become cheap, but software remains incredibly expensive.”

A licensed tool comes with a data model, connectors to your other systems, access control, hosting and upgrades. Only its screens got cheap. A factory is what supplies the rest, once, for every tool it ships.

• Intake. A team says what it needs, in a sentence. The request is the specification.
• Ground. The tool reads the records it needs: part records, supplier notices, tickets. It reads them through the same permission check as search, as the person who will use it.
• Build. An agent writes the code in a sandbox, as files. Nothing is live yet.
• Check. The change compiles, and its tests run against real records.
• Approve. A person reads the diff. This is where an auditor’s question gets its answer: who decided, and what changed.
• Run. The tool goes to the team’s own instance, hosted, backed up and audited like every other tool on the line.

A demo generated from a prompt usually covers intake and build. The other four stations decide whether it ships.

A generated tool is as trustworthy as what it stands on. The data, the permissions and the controls have to exist before the first tool, and every tool after it inherits them.

That changes the cost curve. The first tool on a foundation pays for the connectors, the schema and the access groups. The second reuses them. By the tenth, a new tool is mostly an endpoint, a screen and an assistant over records that are already there. Security reviews the platform once, and each tool after that is a diff they can read.

Without a foundation the curve runs the other way: every tool brings its own copy of the data, its own login and its own access check. Our paper The app is the easy part collects documented incidents where that went wrong.

Count what reached production and is still in use, not what was prototyped. Four measures say more than a demo count:

• Tools in production that people still use a quarter after launch.
• The time from a request to an approved change.
• How much of each new tool reused what was already there: connectors, schema, access groups.
• How long a review takes, since review sets the pace once code is cheap to write.

A lab proves that something can be done. A factory does it again on Monday, for another team, with the same checks, and keeps last month’s tools running while it does.

That is also the line between generating an app and shipping one. Prompt-to-app is easy. Prompt-to-app that a regulator would accept is not. The hard part was never the interface: it is the data, the permissions and the proof.

Curiosity Studio is the foundation. Connectors bring records from more than 70 systems into one typed graph. Access is synced from the source systems and checked per record at query time, and search and AI run on the same graph, with the model you choose, on your own infrastructure.

Curiosity Orchestrator is the factory floor. It gives each team, project or customer its own Studio behind one address on your servers. It puts a Studio to sleep when nobody is using it.

Sudo, the admin assistant, and curio, the command line for developers and their coding agents, are how work comes through. Both open the same sandbox, stage each change as a diff, and wait for a person to approve it. Spark serves open-weight models on your own GPUs when you want the models in house too.