You notice a bad road. You don't notice a good one. You notice you got there on time.
This is the test I keep returning to when I read another announcement in an endless string of announcements about institutional AI transformation. The thing being celebrated is the road, or it isn't.
Most current AI deployments are not infrastructure. They are chatbots, short workflows, or thin orchestration layers over someone else's APIs, tacked indiscriminately onto an institution's existing operations. They are shiny. They demo beautifully. They will not exist in twenty-four months.
A real piece of infrastructure has a few properties. It is operated by the institution that commissioned it. It is integrated into existing systems and workflows, not bolted onto them. It is durable across changes in technology, which means the architecture absorbs improvements rather than being broken by them. It is legible to the people inside the institution, who can describe what it does, when to trust it, and where its limits are. It is governed by standards the institution can audit. And it is inheritable. It survives the team that built it and the leadership that commissioned it.
It is also frictionless. It fits the institution's existing data pipelines, the workflows the teams are already running, the vocabulary the institution already uses to describe its work. It is woven into the operation, not stapled to the side of it.
By these tests, most current AI deployments fail.
The typical AI deployment is composed of other people's components. We call these systems wrappers, because they wrap a thin orchestration layer around a frontier model API, a vector database service, a third-party retrieval pipeline, a managed prompt platform, a vendor's auth and analytics. The buyer owns approximately none of the actual machinery. They own a configuration file and a user interface. The system depends entirely on the pricing schedules, deprecation calendars, and product decisions of companies they have no leverage over.
When a vendor raises prices, when a model is deprecated, when its capabilities shift overnight, the wrapper's behavior, economics, or architecture all change with them, because the wrapper was tuned to dependencies it does not control. Real infrastructure absorbs technological change. Wrappers are broken by it.
A wrapper also cannot be frictionless, no matter how good its demo. It is structurally external. It sits beside the institution's systems, peeks at them through APIs, requires its own login, demands its own workflows, asks the team to translate between the wrapper's vocabulary and their own. Friction is not a wrapper's failure mode. It is a wrapper's permanent state.
Real infrastructure treats the model as a component, not a foundation. The system we build is data integration, workflow logic, governance and audit, evaluation harnesses, documentation, and the operational layers that let an institution actually run the thing. Inside that system, an LLM is doing some specific work. We choose the best model available for that work today. When a better model arrives tomorrow, we swap it in. The surrounding system does not care which model is plugged into it, because the surrounding system is what the institution actually operates.
A wrapper has the inverse architecture. The model is the foundation. The thin software around it exists to translate prompts and parse responses. Swap the model and the wrapper has to be rebuilt, because the wrapper was the model integration. Build infrastructure around the model and the model becomes interchangeable.
I am not exempting our own work from parts of this critique. We use third-party APIs in our systems too, and where we do, we are also exposed to those vendors' pricing schedules and deprecation calendars. The honest position is that some AI workloads cannot currently be moved off frontier APIs without losing capability the institution actually depends on. There are systems we have built where the swap is not yet possible, and pretending otherwise would be dishonest.
The discipline is in being honest about which case you are in. On every engagement, we explore whether the system can be moved to an open-source model deployed and tuned on the client's own data and infrastructure. When the answer is yes, we execute the swap. When the answer is not yet, we say so plainly, and we design the architecture to absorb the eventual swap when capability allows. The client always knows where it stands.
The deeper failure of the wrapper era is not technical. It is institutional.
The buyers of these systems do not understand what they have bought. The descriptions were authored by vendors. The institution did not write the words. They cannot translate the words. They cannot defend the words to their own boards or regulators. And they cannot embody what was said. They have signed off on documentation they do not own, in language they did not author, about systems they cannot describe to their own people. This is the deepest failure mode of the current AI buying cycle: the rhetoric of the work has not been inherited along with the work itself, because the work itself was never built to be inherited in the first place.
This is the work Empiric does.
The institutions that take the faster path now will be replacing those systems with substantial urgency, somewhere between twelve and twenty-four months from now. The institutions that do the harder work now will be running durable systems they operate, can upgrade, can govern, can defend, and can inherit.
Two years from now, the announcements will be gone. The roads will still be there.