In technology, six months is a long time. A year is an eternity.
The tools that were state-of-the-art in early 2024 are, in many cases, already obsolete or significantly outperformed. The AI landscape is moving faster than any single implementation can keep pace with. Which raises a question that most founders are not asking when they approve an AI project: how long is this going to be relevant?
The obsolescence problem nobody talks about
When a company implements AI, they typically make three simultaneous bets.
They bet on the vendor. They bet on the specific model or product. And they bet on the architecture — the way the implementation is built and connected to the rest of the system.
The vendor might still be around in two years. The specific model or product they bought is almost certainly going to be superseded by something significantly better, probably within twelve months. And if the architecture was built in a way that assumes the current tool is permanent, the cost of switching is going to be enormous.
This is vendor lock-in, and it is the most expensive mistake in AI implementation. Not because the tool is bad — often it works well — but because the world moves on, and the cost to follow it is prohibitive.
What a modular architecture actually means
The solution is to build AI implementations the way you would build a supply chain: assuming that any specific supplier can and will be replaced, and designing accordingly.
In practice, this means separating three things that often get tangled together.
The interface layer — how your team interacts with the AI capability — should be independent of the specific tool underneath. If your customer support team uses a workflow that routes certain queries to an AI for a first draft, that workflow should not care whether the AI underneath is GPT-4, Claude, or something that does not exist yet.
The integration layer — how the AI connects to your data, your other systems, your business logic — should be built to a standard that any reasonable AI tool could satisfy. Proprietary connectors that only work with one vendor are debt. Clean APIs that treat the AI as a replaceable component are infrastructure.
The data layer — the records, feedback loops, and training data that make the implementation useful — should be owned by you, not the vendor. If your AI gets better over time because of the data your team generates, that improvement should travel with you when you switch tools. If it stays behind with the vendor, you are renting intelligence rather than building it.
Which parts of an AI implementation actually survive
Not everything is disposable. Some investments in AI implementation create durable value regardless of which specific tool you use.
Process design is durable. The work of figuring out exactly which decision points benefit from AI assistance, mapping the workflow, defining the quality criteria, and building the feedback loops — that work stays relevant even when the underlying technology changes. The process is the asset. The tool is the executor.
Data strategy is durable. Understanding which data is valuable, how to collect it consistently, and how to use it to evaluate AI outputs — that expertise accumulates and compounds. The specific format might change, but the discipline of treating data as a strategic asset does not.
Team capability is durable. People who understand how to work with AI outputs — how to evaluate them, correct them, use them as a starting point rather than a final answer — carry that skill regardless of which tool they are using. Building that capability in your team is a better investment than optimizing for any specific product.
The question to ask before every AI implementation
Before approving any AI project, one question should be on the table: if we needed to replace this specific tool in twelve months, how hard would that be?
If the answer is "very hard," the implementation is probably too tightly coupled to the vendor. The project is still worth doing — the business value might justify the lock-in risk — but the risk should be explicit and accepted deliberately, not ignored.
If the answer is "manageable," you have a modular implementation. The business benefits from the AI capability today, and the organization retains the flexibility to upgrade or switch when something better arrives.
The goal is not to avoid AI investment. The goal is to invest in AI in a way that builds capability and flexibility rather than dependency.
We help teams design AI implementations built to last — and built to adapt.