← Back to katiencarr.ai
Perspectives · June 2026

The Vendor Trap

There's a pattern I keep seeing in enterprise AI that I think is going to burn a lot of companies. They're spending significant money on managed AI service layers — middleware vendors who wrap a foundation model in a nice interface, add some guardrails, and charge a subscription. The problem is that the foundation model providers are building those same capabilities natively. The wrappers are going to get absorbed.

This isn't speculation. It's already happening. Features that were the entire value proposition of AI middleware companies two years ago — document processing, structured output formatting, context window management, retrieval from proprietary data — are now standard capabilities of the major models or their first-party platforms. Every model generation absorbs another layer of the middleware stack. If your vendor's value proposition is something the model will do natively next year, you don't have a vendor. You have a countdown.

I saw this pattern clearly while building the AI function at a global investment bank. Early on, there was pressure to buy managed solutions — fully packaged AI platforms that promised enterprise-grade everything. The pitch was always the same: "You don't need to build anything, we've done it for you." And in the short term, that pitch was true. The platforms worked. They delivered value. The problem was what happened twelve months later, when the foundation models leapfrogged the vendor's feature set and we were locked into contracts for capabilities we could now get directly.

If your vendor's value proposition is something the model will do natively in twelve months, you don't have a vendor. You have a countdown.

The vendor trap works like this: a company buys a managed AI layer. They build their workflows on that layer. Their people learn that layer's interface. Their data gets structured around that layer's schema. Then the foundation model provider releases the same capability — often better, because they have deeper access to the model's internals — and the company faces a choice: stay with the vendor and pay more for less, or migrate off and eat the switching costs they've accumulated. Neither option is good. Both were avoidable.

The alternative is to build your defensibility above the model layer. The model is the commodity. What you build on top of it — your workflows, your proprietary data integrations, your custom skills, your institutional knowledge encoded into structured processes — that's where the value lives, and that's what no vendor or model provider can replicate. It's yours.

When I built our skills library of 40+ structured AI workflows, each one was designed around our firm's specific work patterns. A vendor could sell us a generic "legal research" AI tool. What they couldn't sell us was a workflow that knew how our specific practice groups structure their analysis, which data sources our professionals trust, and how to present results in the format that our senior leaders actually read. That specificity — the domain knowledge baked into the workflow — is the defensible layer. It sits above the model, and it gets more valuable over time because it accumulates institutional knowledge.

The same logic applies to data architecture. Your proprietary data — client information, deal history, internal research, institutional precedent — is uniquely yours. The way you structure access to that data, the way you connect it to AI workflows, the integrations you build between your systems and the model layer — that architecture is defensible. A vendor's generic connector to your document management system is not defensible. Your custom MCP integration that understands your firm's specific data taxonomy, access controls, and workflow requirements — that's defensible because it encodes knowledge only you have.

The model is the commodity. Your workflows, your data layer, your institutional knowledge encoded into structured processes — that's the moat.

I want to be fair to AI vendors. Many of them provide genuine value today, especially for companies that don't have the capacity to build internally. The point isn't that all vendors are bad. The point is that you need to be clear-eyed about which part of the value they provide is durable and which part is a feature the model provider will absorb. If a vendor's primary value is making the model easier to use, that value has a shelf life. If their value is in domain-specific data, workflow intelligence, or regulatory compliance tooling that reflects deep industry expertise, that's more durable — at least until the model providers go vertical.

The test I use: if you removed the AI model from a vendor's product, what's left? If the answer is "not much" — if the value is essentially a user interface and some prompt engineering on top of a foundation model — that product is on borrowed time. If the answer is "significant proprietary data assets, deep domain logic, and workflow intelligence that would be hard to recreate" — that product has a longer runway. Most enterprise AI products I've evaluated fall into the first category.

For firms building AI programs right now, the strategic imperative is clear: invest your energy and resources into the layers you own. Build your custom workflows. Structure your proprietary data for AI access. Train your people to work directly with the model layer. Develop institutional knowledge about what works in your specific context. Use vendors where you need to, but don't let the vendor layer become your strategy. When the model provider eventually offers the same capability natively — and they will — you want your value to be in the architecture above it, not in the wrapper around it.

The companies that will have the strongest AI capabilities in three years aren't the ones buying the best wrappers today. They're the ones building the most defensible layers above the model. That's the work that compounds. Everything else is rented.

If you're evaluating your AI vendor stack — or wondering what to build versus buy — I've made these decisions under real constraints. Reach out or find me on LinkedIn.

← Back to katiencarr.ai