The Foundation Trap

Imagine renovating a hundred-year-old house. You can do most of the cosmetic work yourself. The floor that needs leveling, the wall that needs paint, the window that sticks — all approachable. Then comes the load-bearing wall. The plumbing routing through the foundation. The electrical panel that doesn't meet current code. These you do not touch without someone who has done it before. The cost of getting load-bearing decisions wrong is not the cost of the wall — it is the cost of the whole house leaning.

AI architecture decisions in 2026 are load-bearing walls. Most operating businesses are choosing between them without knowing it.

Six layers, none of them stable

The agent infrastructure stack as it exists today has roughly six layers: model providers, orchestration frameworks, retrieval systems, memory + state, evaluation tooling, and the integration glue that hooks all of it into your existing operations. Every layer is maturing at a different speed. Every layer has at least three serious vendors competing. None has consolidated.

Product strategist Nate B. Jones has the most direct framing of what this means in practice:

The Lego framing is the lie that gets sold to operators. The reality is that the bricks don't fit cleanly together, the documentation is wrong as often as it is right, and the team that picks the wrong brick at layer two pays for it on every system they build at layer three through six.

What "lock-in" actually means now

Twenty years ago, lock-in meant you bought a vendor's licensed software and switching cost six months and a million dollars. The 2026 version is more subtle. You commit to a vendor's data shape. You build evaluation infrastructure around their output schema. You write integration code against their specific API quirks. You train your operators on their specific UI for human review. The vendor doesn't have to lock you in deliberately. The cost of moving off them just becomes higher than the cost of staying, even when staying is wrong.

For AI specifically, the lock-in vector that catches operators by surprise is the data shape. The first AI workflow you ship dictates how you structure your customer history, your product catalog, your operational state. Every subsequent workflow assumes that shape. When the underlying technology changes — and it will, several times, in the next eighteen months — the data shape that fit perfectly with the old vendor often doesn't translate to the new one. The cost of the migration is not the migration. It is the year you spend rebuilding the dependent workflows from scratch.

The wrong question

Most operators evaluating AI today ask: "Should we use Vendor A or Vendor B?" The vendor selection is the visible decision. It is not the load-bearing one. The load-bearing decisions are upstream of the vendor:

• Where does workflow context get stored, and in what schema
• What is the contract between the agent and the rest of your system
• How is evaluation data shaped — in a way that survives a vendor switch, or coupled to today's vendor
• Is the human review interface owned by you, or rented from the vendor
• Is the model boundary clean enough that swapping models is a config change, not a code rewrite

An operator picking between Vendor A and Vendor B without first deciding these five things has, by default, picked the vendor's defaults — which means the vendor has decided for them. That is the foundation trap. You don't see it as a choice you made because it never felt like a choice.

The contractor difference

The renovation analogy lands because everyone has the intuition for it. You hire a general contractor for a load-bearing change because they have done a hundred of them. They know which permits matter, which subcontractor cuts corners on rebar, which combination of materials fails in your specific climate. None of that knowledge transfers from a YouTube video. The reason you pay them is not their hands — you have hands. The reason you pay them is judgment they earned by being on site when other peoples' projects went wrong.

The same principle applies to AI architecture. The team that has shipped six deployments knows which "obvious" choice locks you in next year. They know which abstraction layer is worth building yourself versus buying. They know which vendor's documentation lies about what their API actually returns at scale. None of this transfers through documentation, because vendors don't write documentation about their own product's load-bearing flaws.

What good looks like

An operator who has avoided the foundation trap has, almost invariably, made the same five upstream decisions before picking any vendor. They own their context layer. Their evaluation harness operates against their data, not the vendor's eval format. The model is a swappable component behind a clean interface. The human review surface is theirs. And when the vendor inevitably ships something that breaks the integration, the cost of fixing it is days, not quarters.

This shape can be built. It just doesn't get built by accident, and it almost never gets built right by a team that has not done it before. The cost of importing that experience for the four to twelve weeks it takes to install is paid back the first time the underlying vendor landscape shifts — which, in 2026, will not take long.