In my previous post, I argued that it is a strategic trap for the enterprise to wait for the emergence of an AI Utility before building an AI Factory to deploy its intelligent agents at scale. The utility provides the raw power (tokens). However, the AI Factory is the process, the people, and the technology stack that utilize that power. The enterprise’s proprietary knowledge must be reflected throughout the AI Factory and is required for realizing impactful and enduring value.
While planning how AI can provide their enterprise with impactful and enduring value, its board and senior executive team often ask: “Why build an AI Factory or even a single AI application? We didn’t build a SaaS Application Factory or even the CRM application we use. We licensed Salesforce’s. Why couldn’t we apply our SaaS Playbook to address and scale our AI needs?”
These are key questions every enterprise, regardless of industry, should be asking. The answer lies in understanding that AI is not just the next generation of enterprise software. It represents a fundamental shift in how the enterprise approaches its business processes.
The SaaS Playbook vs. The AI Reality
For the last 20 years, the “Buy vs. Build” enterprise software debate has been settled. Enterprises licensed cloud-based applications and infrastructure software to address its needs. In doing so, it implicitly outsourced the business processes automated by the licensed applications. The customer record became a commodity. The parcel record became a commodity. The SKU record became a commodity.
The result of this transformation was a series of cloud-based standardized enterprise Systems of Record.
Now, software vendors are pitching the same logic for AI applications. “Don’t build your own AI application, or agent. Rent ours. It’s smarter, cheaper, etc.”
But here lies a dangerous trap. An agentic application isn’t just a System of Inference (predicting text) and Action (executing a script). It is a System of Agency. Moreover, whereas today many systems of record are standalone and siloed, enterprises must plan for a time when their agentic applications will start to collaborate to execute the complex workflows that are part of their business processes.
The Difference Between Action and Agency
A state-of-the-art enterprise application today, e.g., a CRM application, is a System of Inference and Action. It:
- Infers: Predicts a customer will churn.
- Acts: Executes a rule (or script) written by a human: “If churn risk > 80%, send a discount.”
A System of Agency is different. It accepts a Goal (e.g., “Maximize Customer Lifetime Value”), and autonomously reasons and decides on the Strategy it will use to satisfy the goal. For example, it might reason: “This customer always consumes new content on the first day it becomes available. The customer has never used any of the discount offers we previously offered. Therefore, this customer responds better to new content than discounts. I will send a trailer for a new show instead of a discount coupon.”
The reasoning is the result of the enterprise’s proprietary knowledge about the customer, including the customer’s response to past campaigns. It is part of the enterprise’s knowledge base about how to maximize customer lifetime value based on each customer’s characteristics and behaviors across a variety of scenarios and even businesses.
A generic “Churn-Prevention Agent” offered by a vendor will likely be less effective for the enterprise because it uses a general–purpose churn-prevention knowledge base. In other words, the agent optimizes for the ‘average’ customer, not the enterprise’s customer. Furthermore, this approach locks in the enterprise to the vendor’s knowledge model. This approach can erode margins, create unexpected liabilities, and lead to vendor lock-in.
Defining the AI Factory
An AI-first enterprise must be capable of moving from a prioritized list of candidate AI solutions to prototypes of those solutions, and from prototypes to applications deployed across the enterprise. Three capabilities make that possible, and they are distinct. Someone must decide which candidates are worth pursuing and fund them. Someone must build the solutions. And someone must supply the engineering talent and computing resources that building requires, at a scale no individual effort can justify on its own. This post concerns the third. The AI Factory is the enterprise’s internal supplier of AI engineering capability and AI infrastructure.
The AI Factory integrates people, processes, data, and the AI Stack. Its people are AI engineers, data engineers, and machine learning and platform specialists, i.e., the technical capability the enterprise must hold at scale because no single AI project can justify the capacity it intermittently requires, and because capability distributed across business units yields neither utilization nor leverage with the vendors supplying it.
The Factory does not decide which AI projects the enterprise undertakes, and it does not fund them. Those decisions belong to a separate body, which I have since come to call the AI Transformation Office, and which draws on business, technology, legal, and HR judgment to make them. The teams that build the solutions are separate again. The Factory supplies both.
The processes (detailed in the next section) codify the enterprise’s approach to how to identify and select the right use cases to focus on, how to experiment with data and models in the process of identifying the ones that will effectively address each selected use case, how to build and deploy the AI applications that will incorporate the data, models, and other forms of knowledge identified during the experiments, and how to orchestrate different AI applications to execute complex workflows.
The AI Stack includes the technologies the factory uses. The enterprise decides which of the stack’s layers it will own and which it will rent. The enterprise may decide to own the entire technology stack, including all its AI models, as Recursion Pharmaceuticals and Ginkgo Bioworks do. Alternatively, it may use a hybrid model, as AI-first companies Intuit, Walmart, and Visa do. They combine a third-party foundation model, in both cases OpenAI’s model, with their proprietary AI models.
The Factory’s Processes: Selection, Experimentation, Production, Orchestration
The AI Factory performs four critical processes that the enterprise must own. Selecting which use cases to pursue is not among them. In the rush to apply AI, many enterprises fail to apply rigorous criteria to that question, and the result is a set of disconnected efforts producing weak results. I have since called this condition the Pilot Purgatory. Selection is a governance decision requiring business, technology, legal, and financial judgment, and it belongs to the AI Transformation Office rather than to the AI Factory. The Factory owns everything that follows once the selection has been made:
- Provisioning: The Factory supplies engineering talent and computing and storage resources to the teams building AI solutions, and it charges them for what they use, much as a hyperscaler charges its customers. Pricing matters more than it appears. A Factory that prices below its cost makes every project’s economics look better than they are. One that prices above the market distorts every decision about whether to build a capability or rent it.
- Experimentation environment: Today, most enterprises decide on and implement AI application prototypes on an ad hoc and siloed basis. AI-first enterprises industrialize experimentation. The teams building solutions conduct the experiments, i.e., testing data connection and unification schemes, knowledge representation approaches, and AI models, and the AI Factory supplies the environment in which those experiments run, i.e., the data access, the evaluation infrastructure, and the compute. The AI Factory makes experimentation cheap and repeatable. It does not decide what to experiment on, or conclude what the experiments mean.
- Production: The result of the experimentation to both identify the value of the application and the components that will comprise it. Agentic applications may be commoditized (in which case they can be licensed) and strategic (which must be developed internally and owned). For example, like many other enterprises, airlines license agentic applications that automate software development. However, they develop the AI applications used for flight scheduling. The flight scheduling agent of United Airlines reasons differently from Delta’s. This decision occurs at two levels. The AI Factory decides which layers of the AI Stack the enterprise owns. The AI Transformation Office decides, for each funded project, whether that project accumulates a durable capability or rents one that will be commoditized within two years. Both answers can justify funding, but on different terms and with different expectations of permanence.
- Orchestration: The AI Factory acts as the anti-silo engine. It must ensure that the appropriate agentic applications are properly orchestrated and logically interconnected. When a manufacturer’s marketing agent launches a campaign, it must signal the production agent to ramp up inventory, and the distribution agent to secure freight capacity. Orchestration is the one AI Factory process no individual project can perform. Each project optimizes the workflow it owns. Only a shared layer can ensure that the marketing agent’s campaign reaches the production agent and the distribution agent, because no project’s Pod is accountable for the interfaces between its solution and everyone else’s.
The Pragmatist’s Guide: You Don’t Have to Build Everything
Creating the AI Factory may appear daunting. AI-first early adopter enterprises, like Intuit and Walmart, approached it as an existential imperative: build it and constantly refine it. Enterprises that belong to the late majority category may take a more measured approach. However, the important message is that today’s enterprise, starting with the Fortune 500, cannot avoid developing an AI Factory. The factory may incorporate rented technologies, e.g., AI compute, public foundation models, and even certain agentic applications. But the enterprise must own the applications it identifies as strategic that incorporate its proprietary knowledge.
Conclusion
The “SaaS Playbook” enabled the enterprise to quickly adopt best‑of‑breed cloud applications, standardize on vendors’ “good enough” business processes, and use lightweight integrations and governance to gain speed, lower upfront costs, and reduce IT friction. It fostered faster experimentation, easier scaling, and access to continuously improved capabilities. However, it produced fragmented data silos, weakened the idea of a single customer system of record, and pushed enterprises to conform to vendor workflows rather than preserving distinctive process advantages.
The AI Factory is about owning agency to retain and enhance value.
If the enterprise treats AI as a utility, it becomes a tenant. In a similar way to what happened with SaaS applications, it pays rent to hyperscalers and over time loses its memory and nervous system. The AI Factory enables the enterprise to become a landlord. It capitalizes on its proprietary knowledge and builds its nervous system, both of which define its competitive advantage.
A closing note on scope. This post concerns the technical capability an enterprise must hold to build and run AI applications at scale. It does not address who decides which applications to build, who funds them, or how that funding is governed. These are questions I address in the AI Transformation Office and the Enterprise Capital Gate. The AI Factory without the Office produces capability nobody has decided how to use. The Office without the AI Factory produces decisions nobody can execute.
3 thoughts on “Building the AI Factory: An Executive Playbook”