LangChain earned a peculiar reputation. It was the first framework most people used for building on language models, it grew extremely fast, it accumulated abstractions faster than it accumulated explanations, and a large number of developers concluded it was easier to call the model API directly. Some of that criticism was fair, some of it was fashionable, and the documentation was genuinely part of the problem. The current documentation is considerably better and deserves to be judged on its own rather than on the memory of what it was.
The reorganisation around a small number of clear primitives is the main improvement. Instead of a sprawl of chains, agents, executors and wrappers each with their own conventions, the entry point is create_agent, which takes a model, some tools and instructions and gives you an agent. Around that sits middleware for the cross cutting concerns, guardrails, retries, routing, tool policies. That is a comprehensible architecture and you can hold it in your head, which was never true of the old one.
The three tier framing is helpful. Deep Agents for the batteries included path, LangChain for the configurable middle, LangGraph for when you need to define the control flow yourself as a graph. The documentation is reasonably clear about which situation calls for which, and telling people that the simplest option might be enough is not something every framework does. LangGraph is the strongest piece technically.
Once your application has real control flow, branches, loops, human approval steps, state that persists across turns, an explicit graph is a better representation than a chain of calls, and the documentation covers state, checkpointing, interrupts and persistence properly. If you are going to invest in learning any part of this stack, that is the part with the most durable value. Integration breadth remains the practical reason people use LangChain. Every model provider, a very large number of vector stores, document loaders for formats you had forgotten existed, tool integrations across most common services.
Whatever you need to connect to, there is probably a package, and it probably works. That is a real network effect and no competitor is close. LangSmith documentation is good and the product is useful. Tracing what an agent actually did, seeing each model call with its inputs and outputs, and being able to construct evaluation datasets from real traces addresses the largest practical problem in building these systems, which is that they fail in ways you cannot see.
Now the criticisms. The largest is not really the current documentation's fault and affects everyone reading it. Three years of tutorials, blog posts, videos and Stack Overflow answers describe APIs that no longer exist. Those pages rank well.
A beginner searching for how to do something in LangChain will land on 2023 material, follow it, hit import errors, and conclude the framework is broken. The current documentation cannot delete the internet, and it could be far more aggressive about version signposting, because this is the single biggest reason people bounce off. Product sprawl is the second issue. LangChain, LangGraph, LangSmith, Deep Agents, plus the platform and deployment offerings, each with documentation, some of it overlapping.
Working out which product you are reading about, and whether a concept belongs to the framework or to the orchestration layer, takes more effort than it should. The consolidation into one documentation site helps and does not fully solve it. The abstraction complaint has not gone away. The framework's value proposition is that it handles the plumbing, and the cost is that when behaviour surprises you, the plumbing is where the answer is.
What exactly went into the prompt, in what order, with what formatting, after which transformations. Tracing through LangSmith mitigates this considerably, and it is telling that the recommended way to understand what the framework did is a separate commercial product. Which leads to the commercial entanglement. LangSmith is a paid product for meaningful use and it appears throughout the open source framework's documentation as the assumed way to work.
That is a legitimate business model and it means the free framework's documentation quietly routes you towards the paid observability tool, and you should read it knowing that. The final point is the one no framework will make. A great many applications built on this stack are a model call, a prompt template, a retrieval step and some parsing. That is a hundred lines of ordinary code with no framework, no version churn, no abstraction between you and the API, and no dependency on someone else's architectural decisions.
The right question before adopting LangChain is whether you need what it does, and the honest answer for simple pipelines is often no. Where it does earn its place is complex agent control flow, or breadth of integrations you would otherwise write yourself, or a team that benefits from shared structure. My three point four is for documentation that has improved substantially, describes a much better designed framework than it used to, and is still fighting the accumulated confusion of its own history plus a product surface larger than most readers need. Read the current pages, ignore anything older than this year, learn LangGraph if you need real orchestration, and be honest with yourself about whether a framework is the answer.