LangChain & LangGraph: The Framework That Won't Die
LangChain is the most installed LLM framework in the Python ecosystem. It has more PyPI downloads per month than any competitor [VERIFY], more GitHub stars than most of them combined, and more complaints per star than anything in the space. LangGraph is its graph-based agent framework — the part of the LangChain ecosystem that's actually interesting for building agents. Together, they represent both the biggest community in LLM tooling and the most divisive opinion in it. Both the fans and the critics are partially right, which is the most annoying kind of situation.
What It Actually Does
LangChain started as a simple abstraction for chaining LLM calls together. Prompt goes in, response comes out, response feeds into the next prompt. That was 2022. Since then, it has grown into a sprawling framework covering chains, agents, memory, document loaders, vector stores, retrievers, output parsers, callbacks, and roughly 800 third-party integrations [VERIFY]. The ambition is to be the React of LLM applications — the standard layer between your code and the model.
The criticism of LangChain — and it is loud, persistent, and partially earned — is that much of this abstraction is unnecessary. If you want to call the OpenAI API and parse the JSON response, you can do it in four lines of Python. LangChain wraps that in classes, base classes, abstract methods, and configuration objects that turn four lines into forty. For simple use cases, LangChain is overhead. That's not controversial. Harrison Chase himself has acknowledged that LangChain got over-abstracted in its early growth phase.
LangGraph is the response to that criticism — or at least, the part of the response that matters for agents. LangGraph models agent workflows as state machines. You define nodes (functions that do things), edges (connections between nodes), and state (data that flows through the graph). Conditional edges let you route execution based on the current state. This is a genuinely useful abstraction for complex agent workflows, and it's the reason LangGraph deserves a separate conversation from LangChain's kitchen-sink framework.
What LangGraph provides that raw code doesn't: persistent state that survives across turns and even across sessions via checkpointing. Human-in-the-loop interrupts where the graph pauses, waits for human input, and resumes. Complex branching logic where different conditions send execution down different paths. Streaming of intermediate results so you can see what the agent is doing before it finishes. And time travel — the ability to rewind to a previous checkpoint and re-execute from there. These features are genuinely hard to build from scratch, and LangGraph provides them out of the box.
The state machine model also forces a useful discipline. When you build an agent as a graph, you have to explicitly define every state transition. There's no hidden control flow. If the agent can go from "researching" to "writing" or "asking for clarification," both paths are visible edges in the graph. This makes the agent's behavior auditable in a way that's hard to achieve with a freeform agent loop. For production systems where you need to explain why the agent did what it did, this matters.
What The Demo Makes You Think
The LangGraph demos show elegant directed graphs routing between nodes — a research node that gathers information, a reasoning node that analyzes it, a writing node that produces output, with conditional edges handling error states and human approval. It looks like visual programming for AI agents, clean and controllable.
Here's the gap.
The complexity tax is real. LangGraph requires you to define state schemas, node functions, edge conditions, and graph compilation steps before your agent does anything. For a simple "call the LLM, use a tool, call the LLM again" loop, this is dramatically more setup than writing a while loop. The framework's power comes at the cost of boilerplate, and the boilerplate is front-loaded — you pay it before you know whether your agent design is right. Refactoring a LangGraph agent means refactoring graph topology, not just editing a prompt.
The debugging story is better than it used to be but still painful. When your graph doesn't produce the expected output, you're debugging through layers of abstraction — state transformations, node executions, edge conditions, checkpoint serialization. LangSmith (LangChain's observability tool) helps significantly here, showing you the trace of every node execution with inputs and outputs. But LangSmith is a separate product with its own pricing, and the free tier has limits that matter for anything beyond development. The debugging experience without LangSmith — just LangGraph in a notebook — is rough. Print statements through graph execution give you fragments, not the full picture.
The demo also doesn't show the documentation experience. LangChain's docs have improved materially over the past year, but the framework has accumulated so many concepts, classes, and configuration options that finding the right way to do something often means reading three different tutorials that each use a different abstraction. The "getting started" path is clear. The "I need to customize this specific behavior" path often leads to reading source code. LangGraph's docs are better than LangChain's — they're newer and more focused — but they still assume familiarity with LangChain concepts that might not be obvious to newcomers.
And the ecosystem lock-in is worth thinking about. If you build your agent on LangGraph, you're building on LangChain's abstractions for LLM calls, tool definitions, and output parsing. Migrating away means rewriting those layers. If LangChain's abstractions align with how you think about LLM applications, this is fine. If they don't — or if they change in a version update — you're doing yak-shaving instead of building features. The version churn in the LangChain ecosystem has been a consistent developer complaint, with breaking changes between minor versions and deprecation cycles that don't always come with clear migration paths.
What's Coming
LangGraph is the part of the LangChain ecosystem that's getting the most investment, and it shows. LangGraph Platform offers managed deployment — you push your graph, they handle the infrastructure, scaling, and persistence. LangGraph Studio provides a visual interface for building and debugging graphs, which addresses the "I can't see what my agent is doing" problem directly. LangSmith continues to improve as the observability layer, with better trace visualization and evaluation tools.
The framework itself is getting more accessible. The create_react_agent helper function builds a standard tool-calling agent in a few lines, hiding the graph complexity for common patterns. Pre-built components for common agent architectures (ReAct, plan-and-execute, multi-agent supervision) lower the barrier for standard use cases. The API is stabilizing — breaking changes are less frequent than they were a year ago [VERIFY].
The multi-agent story is where LangGraph is putting serious effort. Agent-to-agent handoffs, supervisor patterns where a top-level agent delegates to specialized sub-agents, and shared state across agent boundaries — these are the patterns LangGraph is building first-class support for. If you're building multi-agent systems and you want more control than CrewAI provides, LangGraph is where the infrastructure is growing.
What still needs work: the learning curve. LangGraph is powerful but it asks a lot of you upfront. The abstractions make sense once you understand them, but understanding them requires investing time that you might not have. The "just use the API" crowd has a point — for simple agents, the framework overhead isn't justified. LangGraph's sweet spot is complex agents with branching logic, persistent state, and human-in-the-loop requirements. If that's not your agent, LangGraph is probably not your framework.
The "Just Use The API" Argument
This deserves its own section because it's the most common critique of the entire LangChain ecosystem, and it's partially right.
The argument: you can build an agent with a while loop, the OpenAI or Anthropic API, and basic tool-calling support in about 50 lines of Python. No framework. No abstractions. No dependency on someone else's breaking changes. Full visibility into what's happening. Full control over every decision. Why would you add a framework?
The counter-argument: that 50-line agent doesn't have persistent state across sessions. It doesn't have human-in-the-loop checkpoints. It doesn't have conditional branching that's auditable. It doesn't have built-in streaming. It doesn't have observability. And building each of those features from scratch takes you from 50 lines to 500 to 5,000, at which point you've built your own framework — and your framework won't have the community, documentation, or battle-testing of an established one.
The honest answer is that both sides are right at different scales. For a simple agent that does one thing in a loop, raw API calls win. For a complex agent that needs state machines, human approval, branching logic, and production monitoring, LangGraph wins. The mistake is applying one answer to both cases. The second mistake — more common in practice — is reaching for LangGraph when you actually need a while loop.
LangSmith: The Actual Value Proposition
LangSmith deserves a specific mention because it might be the most genuinely useful product in the LangChain ecosystem, independent of whether you use LangChain or LangGraph for your agent logic. LangSmith is an observability platform for LLM applications. It traces every LLM call, tool execution, and chain/graph step with full input/output visibility. You can see exactly what prompt the model received, what it returned, how long it took, and what it cost.
For agent development, this is not optional — it's essential. Agents fail in ways that are hard to debug without trace visibility. The model hallucinated a tool call. The tool returned an error the model misinterpreted. The state mutation at step 4 caused a bad branch at step 7. Without trace data, you're guessing. LangSmith gives you the data.
The caveat: LangSmith has a free tier that's sufficient for development but not for production monitoring at scale. The paid tiers are priced for teams, not individuals [VERIFY]. And while LangSmith works with any LLM application (not just LangChain-based ones), the integration is smoothest within the LangChain ecosystem. Using LangSmith with a non-LangChain agent is possible but requires more setup.
The Verdict
LangGraph earns a slot if you're building agents with complex control flow — conditional branching, persistent state, human-in-the-loop, multi-agent orchestration. These are the problems it genuinely solves better than raw code, and the state machine model provides structure and auditability that matter in production.
LangChain (the broader framework, minus LangGraph) earns a more conditional recommendation. Its integration library is unmatched — if you need to connect your LLM application to a specific vector store, document loader, or API, LangChain probably has a connector. But the core chain abstractions are often unnecessary overhead, and the "just use the API" approach is frequently the right call for simpler applications.
The honest summary: LangGraph is good infrastructure solving a real problem. LangChain is a framework that grew faster than it could stay coherent, and it's still paying the complexity debt. Use LangGraph when your agent needs a state machine. Use LangChain's integrations when they save you time. Skip both when a while loop and an API call will do the job — which is more often than either the fans or the critics want to admit.
This is part of CustomClanker's AI Agents series — reality checks on every major agent framework.