There are two LangChains on the internet. The official-docs version, where every tutorial assumes you’ve already chosen it. And the community-critique version, where “abstraction leakage” is treated as a personality trait. This guide’s core claim: LangChain is not a “use it or skip it” decision — it’s a conditional one, and the condition is three signals, not a vibe.
Both sides are wrong in the same way: they treat a framework choice as a loyalty test instead of an engineering decision with a cost function.
The honest position, stated plainly: most projects should start on the raw SDK, and some of them should adopt LangChain — or more precisely, LangGraph — when three signals appear. This guide lays out the signals, the migration path that keeps the framework decision reversible, and the counterarguments that both camps get wrong. It’s the framework-choice guide we wish existed before we made both mistakes — adopting early and adopting late.
Why “Use It or Skip It” Is the Wrong Question
Takeaway: the framework debate is really a complexity tax debate — and the tax is only worth paying past a threshold the marketing never mentions.
The 2026 evidence is unusually concrete. LangChain 1.0’s rewrite answered years of “it’s bloated” complaints with a cleaner core — and the complexity-tax verdict still applies to teams that adopt the framework for problems it doesn’t solve. Meanwhile, migration stories about when config beats framework code document the reverse direction: teams moving off the framework when their actual architecture turned out to be configuration plus a loop.
The pattern behind both directions: the framework pays its tax — learning curve, abstraction indirection, upgrade coupling — only when your system needs what it provides. A two-step tool-calling loop doesn’t need a graph runtime. A ten-step stateful workflow with retries, checkpoints, and human approval genuinely does. The mistake isn’t choosing either side; it’s deciding before you know which side your system is on.
What This Means: Three Signals That Justify a Framework
Takeaway: state, branching, and collaboration — any one of them warrants an evaluation, two of them warrant adoption, and none of them is “the demo looked cool.”
Signal 1 — State that must survive. Your workflow has state that needs persistence and recovery: an interrupted job resumes where it stopped, a multi-turn session survives a crash, a human approval interrupts and later resumes a run. This is the graph runtime’s core competency — LangGraph’s checkpointer model exists for exactly this — and it’s the signal that hand-rolled loops handle worst.
Signal 2 — Branching complexity. More than a handful of conditional paths, dynamic re-planning, loops that depend on intermediate results. When the control flow stops being readable as a linear script, a declarative graph is the difference between “the workflow is the code” and “the workflow is documented in the code.”
Signal 3 — Team collaboration. Multiple engineers maintaining the same agent, needing shared abstractions, versioned workflows, and observability hooks. The framework’s conventions become the team’s contract — which is a real benefit, and only real once the team exists.
The “not yet” list, stated just as plainly: a single tool loop, a prototype you’re still validating, and any system where the framework’s learning curve exceeds the remaining project budget. Those are raw-SDK territory — the agent architecture guide in this series shows how far a bare loop gets before any framework is needed.
Implications: A Framework-Neutral Migration Path
Takeaway: the reversible path is raw SDK first, signals second, framework third — and a unified model layer that keeps the whole thing swappable.
The production sequence that avoids both mistakes:
- Start on the raw SDK. The tool-calling loop is ~50 lines; the multi-model architecture pattern keeps it provider-neutral from day one. Most prototypes never outgrow this — and the ones that do now have a working baseline to migrate from, not a rewrite.
- Watch for the signals. State, branching, collaboration — any two of three, and the framework tax is now worth paying. This is the point where LangGraph’s ecosystem (checkpointing, tracing, deployment tooling) starts repaying the learning curve.
- Migrate the workflow, not the models. The framework wraps orchestration; the model layer stays behind your unified endpoint with custom routing and the model catalog — so the framework decision and the provider decision remain independent, and either can change without forcing the other. The LangChain SDK integration plugs into this directly.
- Keep the exit open. Every framework abstraction you adopt should be one you can replace: the workflow graph, not your data contracts, not your model routing. The teams that treat the framework as orchestration instead of identity are the ones that survive the next migration — ours or anyone’s.
The quickstart gets the neutral baseline running in minutes; the signals decide what comes after.
The ten-item pre-adoption checklist — run it before any framework commits:
- Does the workflow need state that survives a crash or restart?
- Are there more than five conditional paths in the control flow?
- Will more than one engineer maintain this agent?
- Can the framework’s abstraction express the workflow without workarounds?
- Is the team willing to pay the learning curve now, not during a deadline?
- Are checkpoints and tracing requirements documented?
- Can the workflow be tested independently of the framework?
- Is the model layer behind a swappable endpoint (not framework-bound keys)?
- Is there a documented exit path if the framework stops paying rent?
- Would the raw-SDK version still be maintainable at this complexity?
Five or more “yes” answers justify adoption; fewer means the framework tax is premature.
Where LangChain sits among the abstractions:
| Abstraction | Owns | Overlap with LangChain |
|---|---|---|
| Raw SDK (OpenAI/Anthropic clients) | the API call | the base layer everything wraps |
| LangChain / LangGraph | orchestration: state, graphs, tools | this guide’s subject |
| Vercel AI SDK | UI-to-model plumbing, streaming hooks | minimal — complementary |
| Pydantic AI | typed tool schemas and output models | partial — both do tooling |
| LlamaIndex | retrieval and document pipelines | partial — RAG-heavy overlap |
The rule that keeps them from colliding: each abstraction earns its place by owning one layer — and the moment two of them claim the same layer, one of them is redundant.
Counterarguments: What the Docs and the Critics Each Get Wrong
Takeaway: both camps argue past each other — the docs assume adoption, the critics assume the 2023 version, and the production truth is in the middle.
What the official-docs camp gets wrong. The docs answer “how,” never “whether.” Every LangChain tutorial is written for someone who has already decided, which is exactly why the framework keeps getting adopted for problems it doesn’t solve — the complexity-tax verdict is a documentation gap as much as a framework critique.
What the critics get wrong. Most of the “abstraction leakage” canon is written against the pre-1.0 stack. The 2026 framework is a different animal: the rewrite consolidated the core, LangGraph split the orchestration from the kitchen sink, and “LangChain is bloated” is now a 2023 take being recycled without the 2026 data. Critique the current version or don’t critique it at all.
The synthesis. The framework is a tool with a cost function — pay the tax when the signals say the system needs it, skip it when it doesn’t, and keep the decision reversible. That’s not a compromise; it’s the only position both the docs and the critics can’t argue with.
FAQ
Is LangChain dead in 2026?
No — the 1.0 rewrite reset the core, and LangGraph is one of the most active production agent runtimes in the ecosystem. What is dead is the “adopt it by default” era: the framework’s own momentum now lives behind the signals in this guide, not behind tutorials.
Is LangChain 1.0 worth migrating to?
Only if the signals are present — state, branching, or collaboration needs. Migrating a working raw-SDK system for “modernity” pays the migration cost and the complexity tax without the benefit. Evaluate against the signals, not the release notes.
When does a raw SDK stop being enough?
When state needs to survive, when branching stops being readable, or when the team grows past one engineer. Any two of the three signals and the framework tax is worth paying; before that, the raw loop is faster to build, debug, and understand.
Does using LangChain lock me in?
At the orchestration layer, yes — that’s what adoption means. At the model layer, no: keep models behind a unified endpoint with custom routing, and provider changes stay configuration. The lock-in you can avoid is the one that matters, and it’s the one this guide keeps open.
Summary
LangChain is a conditional decision, not a loyalty test: raw SDK first, watch for the three signals — state, branching, collaboration — and adopt the framework (LangGraph, specifically) when two of them appear. Keep the model layer behind a unified endpoint so the framework decision stays orchestration-only, and the exit stays open. The docs tell you how; the critics tell you not to; this guide tells you when — and that’s the only question that ever mattered.
Test the three signals before you commit to a framework. Get your TokSpan API key — $5 in free credits for the baseline — and build the raw-SDK loop that decides.