What do you like best about Langchain?
I have been building LLM applications with LangChain since the early 0.x days, through the awkward middle period, and now on 1.0, and the 1.0 release is the first time the framework has felt finished rather than perpetually in motion. Most of what follows is about that current state, because that is what anyone evaluating it today will actually get.
The create_agent loop is where I spend most of my time now. The 1.0 rewrite collapsed the old Agent and AgentExecutor mess into a single, coherent agent abstraction with a standard tool calling architecture, and the difference in day-to-day work is real. I define the tools, hand over a model, and the loop handles the call-tool-observe-repeat cycle without me wiring it by hand. The older prebuilt path through LangGraph for a single agent is gone, and I do not miss it. What used to take a page of orchestration code is now a function call plus configuration.
Provider agnosticism is the reason we picked it in the first place and it has held up. We run OpenAI models in one product, Anthropic in another, and a self-hosted open model for a client with strict data residency requirements, and the application code is the same in all three. Swapping a model is a config change, not a rewrite. That mattered concretely last year when a pricing change on one provider made a switch worth doing on a mid-sized workload, and the migration was an afternoon instead of a sprint.
Middleware is the 1.0 feature I did not expect to care about and now use constantly. It gives you hooks into each step of the agent loop, so context engineering stops being a pile of ad hoc string manipulation and becomes something with a defined place in the architecture. I use it to trim conversation history before it hits the context window, to inject retrieval results at the right step, and to run a validation pass on tool inputs before they execute. Before middleware existed I was doing all of this with wrapper functions around the agent call, which worked but was fragile and invisible to anyone else reading the code.
Structured output through response_format has been quietly excellent. I pass a Pydantic model and the agent returns output conforming to that schema inside the normal agent loop, no separate parsing step, no retry scaffolding I have to maintain myself. For anything that feeds a downstream system, an API response, a database write, a form fill, this is the difference between an agent that is a demo and an agent that is a component.
LangGraph deserves its own paragraph because it is the piece that made production viable for us. When a workflow is genuinely non-linear, branching, cycling, waiting on a human, I drop down from LangChain to LangGraph and model it as an explicit graph. The properties that matter in practice:
- Durable state, so an agent survives a server restart mid-conversation and resumes where it stopped instead of losing the session
- Built-in persistence, which let us build a multi-day approval workflow without writing any custom database logic for checkpointing
- First-class human-in-the-loop support, so pausing for review or approval is an API pattern rather than a hack
- Every node traces cleanly into LangSmith, so a failed run is inspectable step by step
The durable state point is not theoretical. We had a deployment restart during a long-running document processing job in production, and the workflow picked back up without anyone noticing. Under our old hand-rolled setup that would have been a support ticket and a manual re-run.
LangSmith closes the loop on debugging and evaluation. Every LLM call, tool call, and node execution gets recorded with inputs, outputs, latency, and token usage, so when an agent does something strange I can open the trace and see exactly which step went sideways and what the model actually received. The dataset side is just as useful: I capture a representative set of runs, freeze the inputs, and replay them after every prompt or model change. Regression testing for agent behavior went from something we talked about doing to something that runs on every meaningful change.
The integration surface is the ecosystem advantage nobody has matched. Vector stores, document loaders, retrievers, tool wrappers, there is a maintained integration for essentially everything I have needed, and when a new model or database shows up, the integration tends to exist within weeks. I have stopped budgeting time for glue code around new components.
Two more things earn a flat, unglamorous mention. The redesigned docs site that shipped with 1.0 fixed years of fragmentation, with Python and JavaScript resources consolidated and searchable API references that actually match the current code. And the stated commitment to no breaking changes until 2.0 is worth more to me than any single feature, given the project's history. Six months in, they have kept to it.
The core framework is open source under a permissive license, so the framework itself costs nothing. My spend is model tokens and infrastructure, which would exist regardless of what orchestration layer sat on top. Review collected by and hosted on G2.com.
What do you dislike about Langchain?
The abstraction depth is the honest cost of everything above, and it has not gone away in 1.0. When something misbehaves deep in a chain, the stack trace runs through several layers of framework indirection before it reaches code I wrote, and figuring out what the framework actually sent to the model can take real effort. LangSmith mitigates this substantially, since the trace shows the actual payloads, but that is also part of my complaint: the framework's own opacity is what makes its observability product feel less optional than it should be. My standing workaround is to keep chains shallow, prefer explicit LangGraph nodes over clever composition, and log raw model inputs at the boundary during development. It works, but it is discipline the framework forces on you rather than design that makes the problem not exist.
Dependency weight is the second persistent issue. A LangChain project pulls in a large install surface even when you only use a fraction of it, and the partner package split helped but did not fully solve it. On a constrained deployment target this shows up as slower builds and a bigger attack surface to audit. I now start every project from the minimal core plus only the specific partner packages I need, and I audit the dependency tree before the first deploy, which is a habit I did not need with lighter tooling.
The learning curve for new team members remains steep, and the internet makes it worse. Years of 0.x tutorials, blog posts, and Stack Overflow answers are still out there describing patterns that are now deprecated, so a developer who googles their way through onboarding will absorb three generations of conflicting idioms. The new official docs are good, and my fix has been blunt: new hires are told to use the official 1.0 docs only for the first month and ignore anything with a 2023 or 2024 date. That instruction should not be necessary, but it saves days of unlearning.
The 0.x history still colors how I plan around the project. Before 1.0, rapid releases broke existing code often enough that we pinned versions and treated every upgrade as a small project, and some of that scar tissue remains in our process. The 1.0 stability commitment has held so far and the migration itself was smoother than I feared, mostly deprecations rather than removals, with langgraph.prebuilt moving into langchain.agents being the main adjustment. I am cautiously unwinding the defensive habits, but I would not blame anyone burned in 2024 for waiting another release cycle before trusting the new posture.
Last, the gravitational pull toward the paid ecosystem is noticeable. The open source framework is genuinely usable standalone, but the paths for observability, evaluation, and deployment all point at LangSmith and the hosted platform, and the third-party alternatives get less attention in the docs. It is a reasonable business model and I use LangSmith by choice, but teams committed to a different observability stack should expect to do more of their own wiring. Review collected by and hosted on G2.com.
