Andrew Ng didn't say a word this week, but LangChain's engineers taught a lesson for him
— an open-source framework relied on by hundreds of thousands of AI applications has admitted that what it built over the past two years needs to be rebuilt. When LangChain 1.0 shipped in October 2025, the entire legacy Memory API (the interface that gives AI chat products recall) was packed into a directory called @langchain/classic, with the official recommendation that users migrate to the new architecture. In plain English: stop using the old system.
This matters to every enterprise evaluating AI tooling, because it surfaces a truth the industry rarely says out loud — the AI tools you buy today will most likely be replaced within a year.
What this is
"Memory" is a core feature of AI chat products: when you tell an AI "my name is Xiaoming, I'm in Beijing," it should recall that in a new conversation instead of asking again. Implementing it requires managing chat history — where to store it, how much to keep, how to retrieve it.
LangChain is currently one of the most mainstream AI application development frameworks in the world — the scaffolding for AI apps. From October 2022 to October 2025, its memory design went through three phases and eight major designs:
- Phase 1 (2023): Eight BufferMemory variants (modules that cache conversation history), each representing a different strategy for storing history — raw text, compressed text, extracted knowledge, semantic search over history
- Phase 2 (2024): LCEL (LangChain Expression Language) launched, decoupling storage from memory strategy
- Phase 3 (October 2025 to present): 1.0 released, all legacy APIs archived, the official recommendation is now a two-layer "checkpointer + store" architecture
The problem: no generation is fully compatible with the previous one. Parameters developers spent half a year tuning may have to be rebuilt from scratch when a new version lands.
Industry view
Supportive voices are common. LangChain officially frames the redesign as "necessary evolution" — the legacy API was too fragmented, and the new architecture is cleaner. Plenty of developers in the community concede the new design is more reasonable; they just dread the migration cost.
But we've noticed the counterarguments, and enterprise decision-makers should hear them:
- Framework stability problem: Senior developers on Hacker News and Reddit point out that three architectures in three years means this field "hasn't found the right answer yet." Every redesign forces real human cost to rewrite code built on the previous version
- The risk of premature abstraction: Critics argue LangChain tried to wrap an unstable technical domain into an "easy-to-use framework," amplifying the pain of change. Calling underlying APIs directly (the raw interfaces from vendors like OpenAI and Anthropic) would mean far less disruption with each framework upgrade
- The signal in the name "classic": Shoving the legacy API into a classic archive is semantically "no longer maintained." For enterprise users, this means if your product depends on those old interfaces, future bugs won't get official fixes
Translated into management language: LangChain's story is not an outlier — it's a microcosm of the entire AI developer tooling layer. Frameworks are still iterating fast, and today's best practice may be tomorrow's technical debt.
Impact on regular people
For enterprise IT departments: When selecting an AI framework, build "will the vendor tear up its own architecture within three years" into your risk assessment. Prioritize solutions with stable interfaces and strong backward compatibility over the flashiest marketing.
For individual careers: AI-related skills depreciate far faster than traditional software skills. "Underlying APIs + framework principles" holds its value longer than "mastery of a specific framework" — the former changes slowly, the latter gets rewritten at any moment.
For the consumer market: The AI customer service and AI assistant products you use may, over the next year or two, suddenly change behavior or forget things they previously remembered. That's not the product team getting lazy — it's the underlying technology iterating fast. Give them some patience.