Enterprise AI compounds only when it is run as a platform: tenancy, a shared gateway, approved patterns, and a release gate. Run as a sequence of projects, every workflow pays the full cost of the first.
The fourth AI workflow is where you find out whether you have a program or a series of projects. The first one earned its own security review, its own identity shim, its own hand-rolled logging, and its own evaluation script, and that was reasonable, because there was nothing to reuse. If the fourth one is doing all of that again, the organization is paying the cost of the first workflow four times and is on course to pay it forty. The alternative is not a committee. It is a platform: one paved road that every workflow travels, so that scrutiny goes to what is new about each case and nothing else.
Project mode has a recognizable shape. The fourth workflow renegotiates security, because the review that cleared the first was attached to a project rather than a pattern. It rebuilds identity, because the first team wired a service account straight into the model API and called it done. It reinvents the evaluation harness, usually as a notebook, usually by someone who has never seen the previous three notebooks. And it often ships later than the first, even though the team is more experienced and the model is better, because it now has three precedents that contradict each other.
The tell is the calendar. In the programs I have watched run this way, the time from an approved use case to a production workflow does not fall as the program matures. It rises. The organization is getting better at AI and slower at shipping it, and every individual delay looks reasonable. Each project pays full price. Nobody is adding up the total.
By platform I do not mean a portal or a vendor contract. I mean a small set of shared pieces that every workflow inherits instead of building:
Identity and tenancy. The platform knows who is asking, which business unit they belong to, and what data they may touch, and it enforces that at retrieval time, not only at ingestion. A workflow team never writes an auth layer. It declares a tenant and receives one.
A model gateway that carries the five tags. Every model call passes through one place, and that place stamps each call with tenant, workflow, step, unit of work, and model and prompt version. Routing, retries, rate limits, and budget caps live here. So does the cost record that later attribution questions will be answered from.
A pattern library. In my experience three patterns cover most of what an enterprise wants to build: grounded retrieval over governed documents, structured extraction from semi-structured input, and an agent that proposes actions and waits for approval before it takes them. Each pattern arrives with its security review already done, its failure behavior already decided, and its telemetry already wired.
An evaluation harness as the release gate. One shared harness, with a suite per workflow inside it, runs before every change ships, and a regression blocks the release. The harness is the platform’s job. The ground-truth oracle inside it is the workflow team’s, because only they know what right looks like.
A pre-production cost review. Before a workflow goes live, someone produces the second number: runs per unit, consumption per run, a lopsided band around it, and the volume it will face. The gateway tags are what let that forecast become a measurement instead of an argument.
None of this is new. The cloud era produced the same list under different names: landing zones, golden images, a FinOps tagging policy, and a CI pipeline nobody was permitted to bypass.
The piece I would build first is tenancy, and not mainly for security reasons. The moment two teams share a platform, three things stop being optional. Isolation, because one team’s documents cannot appear in another team’s answers, and a shared cache or a shared index is where that leak tends to happen. Attribution, because one invoice now covers two budgets and someone has to split it. Ownership, because when the shared gateway degrades at two in the morning, the question of who gets paged has to have been answered already.
A single-tenant workflow can defer all three indefinitely, which is what makes it a poor foundation. The second tenant is what makes the platform honest. I prefer to bring it on before the first is polished, while the design flaws are cheap to fix.
The business case for the platform is the shape of the curve, not any single project. As illustration only, picture a first workflow that costs some amount X to take from approved use case to production, with most of X spent on the surrounding system rather than on the model work. In project mode the tenth workflow costs something close to X again, because the surrounding system is rebuilt each time. On a paved road the tenth workflow costs the delta: the part that is genuinely new about that case. The road is paid for once. Every later workflow is priced at its marginal novelty.
That is the mechanism by which approved paths eliminate relitigating. A security review attached to a pattern is reusable. A security review attached to a project is not. The road turns a sequence of full-price negotiations into one negotiation and a series of conformance checks, and the check is fast because it is boring.
The ratio is a prior, not a finding. I do not have a clean cross-organizational dataset that says the tenth workflow costs a fixed fraction of the first. What I can say from engagements I have led is that the direction is not in doubt.
A platform without an ownership model becomes shelfware with an API. The division of labor that works has three parts.
A platform team owns the road. Identity, gateway, patterns, harness, and the cost review are theirs. They are measured on how fast and how safely workflow teams ship, not on the features they add to the platform.
Workflow teams own outcomes. They own the use case, the ground truth, the contents of the evaluation suite, and the business result. They do not own auth, logging, or routing, and they are not permitted to rebuild them.
Every workflow has a named production owner. One person who can change it, roll it back, or turn it off, and who answers when it is wrong. The platform team is not that person. A shared service cannot own a business outcome.
The way this goes wrong is familiar from the cloud era: a platform team that ships infrastructure and no workflows. A year of gateway, identity, and governance work, a handsome internal portal, and zero business outcomes riding on any of it. Meanwhile the workflow teams, who could not wait, built around it.
The defense is to keep the platform pulled, never pushed. Every capability should exist because a named workflow needed it this quarter. The first version of the gateway should be whatever the first two workflows required and nothing more. A road nobody drives on is not infrastructure. It is a monument.
The number I watch to tell whether the platform is working is days from approved use case to production, tracked per workflow and reported quarter over quarter. In project mode it rises. On a paved road it should fall, then flatten at a floor set by the genuinely new work in each case. If the number is not falling, the platform is not a platform yet, whatever the architecture diagram says.
What I am still learning is where that floor sits and whether it differs by pattern. Extraction workflows seem to reach it faster than agents with approvals, because the approval surface is where the novelty concentrates. That is an observation from a small number of cases, not a rule.
In project mode, every workflow pays for the road. On a platform, the road pays for every workflow.
Related: Five tags on every model call and What enterprise grade actually means for AI applications.
