Is this just "always pick the platform option"?

No, and that would be wrong as often as it is right. Platform options have their own risks: lock-in, slow iteration on edge cases, pricing changes, and limited multi-provider flexibility. The framework is about understanding which kind of risk you are taking, not about always choosing one side. A good tech bet may be "use the platform option now and migrate when the bottleneck appears" — that is a valid answer.

How do I evaluate something I do not have personal experience with?

Ask the same questions a careful security review would. What primitive does this depend on? How exposed is that primitive to the platforms? What is the migration path if this category gets absorbed? Vendor documentation often tells you more by what it does not address (their roadmap, their differentiation against native options) than by what it does.

What about open-source tools?

Open-source helps with vendor risk (you can fork, you can self-host) but does not protect against absorption — the project can still wither when its value proposition is eaten. The heuristics in this article apply equally. The difference is that an open-source tool whose category gets absorbed leaves you with code you can keep running, not a billing relationship that ends.

Picking AI Tools That Age Well

Joel Spolsky's Fire and Motion (2002) described the experience of trying to build on top of a platform vendor that keeps shipping new APIs, new patterns, new "must use" features. The vendor's motion is suppressive: you spend so much time reacting to what they shipped that you cannot make your own progress.

Twenty-four years later, the same pattern is the dominant fact of building on top of LLM providers. Anthropic ships extended thinking, computer use, MCP. OpenAI ships Realtime API, Responses API, file search. Google ships grounding, Live API, native long context. Each release shifts what is best practice and what is now built-in. Teams that built on top of last year's API surface either refactor or fall behind.

This article is the framework for making tech bets that survive that motion.

The core question

For every AI tool, framework, or service you consider adopting, the durability question is:

Is the value here a feature on top of someone else's durable layer, or is it a durable layer itself?

A "feature on top of someone else's durable layer" is highly absorbable. The platform that owns the underlying layer has the economic incentive and the information advantage to ship the feature themselves. If your value proposition is "we make using OpenAI easier," your runway is the time it takes OpenAI to ship the same feature natively.

A "durable layer" is something with its own technical depth, its own primitives, or its own audience that the platform cannot easily replicate. Vector databases at production scale, observability across providers, domain-specialized AI products, regulated-industry compliance tooling — these stay durable.

The five heuristics below help answer the question for specific tools.

Heuristic 1: Easy 80% vs hard 20%

For each tool category, ask: does this tool's value come from solving the easy 80% case or the hard 20% case?

Easy 80% tools get absorbed. They solve the case that is broad, low-friction, and broadly useful. The platforms ship a native version that handles the easy case well enough for most users; the third-party loses the bulk of its addressable market.
Hard 20% tools survive. They handle the scale, the multi-tenant cases, the regulated industries, the unusual workloads. The platforms either cannot or will not invest in the long tail.

Example: "Chat with my docs" file search is the easy 80% of RAG. OpenAI File Search and Anthropic Contextual Retrieval cover it. Pinecone-at-scale-with-hybrid-retrieval-and-governance is the hard 20%. The standalone "easy RAG" wrappers are under pressure; the vector-DB-at-scale category is durable.

Heuristic 2: Differentiation on a rapidly-improving primitive

If the tool differentiates on something the foundation models are rapidly improving at, the differentiation evaporates with the next model generation.

"Better chain-of-thought" was a real differentiator in 2023; reasoning models absorbed it.
"Better function calling" was a real differentiator in early 2023; OpenAI native function calling absorbed it.
"Better long-context handling" was a differentiator in 2024; long-context-trained models absorbed it.

If the tool's pitch is "our prompts/scaffolding/orchestration makes X work better with current models," that pitch is on a clock. The foundation models keep getting better at X. The tool's added value shrinks proportionally.

The inverse is more durable: tools that differentiate on something the models are not improving fast — infrastructure, governance, multi-tenant operation, integration breadth.

Heuristic 3: Multi-provider by design

A tool that genuinely makes it easier to use multiple providers is hard for any one provider to absorb — none of them will commoditize the others.

Aider works with Claude, GPT, Gemini, DeepSeek, local models. That portability is its differentiation; no single provider has the incentive to replicate it.
LangChain's most defensible value is multi-provider orchestration; the parts that wrap a single provider have been eroded.
OpenRouter routes across providers; its value is in the route, not the LLM.

If the tool is single-provider by design (only works with OpenAI, only works with Anthropic), it shares the absorption risk of being a feature on top of one platform.

Heuristic 4: Non-LLM depth

Tools that combine LLMs with something the foundation models are not getting better at tend to be durable.

Domain models (medical imaging, legal analysis, scientific simulation) paired with LLMs.
Real-world data infrastructure (search engines, databases, CRM systems, knowledge graphs).
Specialized hardware integration (robotics, edge devices, IoT).
Human-in-the-loop workflows with serious UX investment.

The general pattern: if the LLM is one ingredient and the value depends on the other ingredients too, absorption is harder. The platforms can ship the LLM; they typically do not ship the other ingredients.

Heuristic 5: Frontier-model-update simulation

A specific exercise: imagine the next two frontier-model releases land in the next 6–12 months. They are 30% cheaper, handle 10× more context, and have native support for a major capability that is currently rare (e.g., long video, persistent memory, deeper agentic behavior).

For each tool you depend on, ask: does this update help or hurt the tool's value?

Tools whose value compounds with better models (eval frameworks, observability, multi-provider orchestration) get more useful when models improve.
Tools that wrap current-model deficiencies (better prompting scaffolds, manual chain-of-thought patterns, workaround abstractions) get less useful when models improve.

This simulation is the closest thing to a clean test for durability. If a tool's value goes up when models get better, it is on the right side of the trend. If it goes down, it is in the absorption queue.

Applying the framework

Pick a tool currently in your stack and walk through the five heuristics:

Easy 80% or hard 20%?
Differentiates on a rapidly-improving primitive?
Multi-provider by design?
Non-LLM depth?
Better when models improve, worse, or neutral?

The output is not a yes/no answer. It is a profile of where the tool is exposed and where it is durable. A tool that is "easy 80% + single provider + LLM-only + worse when models improve" is under serious pressure. A tool that is "hard 20% + multi-provider + non-LLM depth + better when models improve" is roughly as durable as any AI tooling gets.

The practical version of this: do the exercise for each dependency, weight them by how central they are to your architecture, and invest engineering attention on the high-exposure ones first. Migration paths exist for most tools; the question is whether you start the migration before the absorption hits or after.

What this framework is not

A short list of things this article is not claiming:

It is not claiming that every absorbable tool dies. Most categories under pressure narrow rather than disappear.
It is not claiming that platform-native is always better. Platforms have their own risks (lock-in, slow iteration, pricing power) and sometimes the third party is just better.
It is not claiming that any specific company in any specific category will be the casualty. Predicting individual outcomes is not the goal; recognizing the structural pattern is.

The framework gives you the question to ask. The answer is always specific to the tool, the stack, and the team.

What stays useful even in the absorbed cases

A coda. Even tools that get absorbed often leave behind something valuable: the patterns they popularized, the abstractions they made standard, the ergonomic improvements they pushed the platforms to ship. LangChain was instrumental in making tool-calling and agent loops normal even though much of its surface has been absorbed. Pinecone is one of the reasons "vector search" became a default consideration even though pgvector covers many of the cases now.

The right mindset is not "avoid anything that might be absorbed" — that excludes most of the useful tools in 2026 — but "build on top of these knowing they might be absorbed, and design the architecture so absorption is a refactor rather than a crisis." That is the durability mindset, applied to a field that updates faster than any one tool can survive unchanged.