LangGraph vs LangChain vs raw OpenAI SDK in 2026 — what we actually pick

Every other week a founder asks us the same question: "should we build this on LangChain, LangGraph, or just call the OpenAI SDK directly?" It's a fair question — and a slightly wrong one. The real choice isn't between three libraries. It's about how much orchestration your agent actually needs, and how much of that orchestration you want to own.

Between the founders we've spent real time with all three (and several combinations of them) on prior projects. This post isn't a TechKis case study — we're a new studio still booking our first founding clients. It's our opinion: where each library earns its keep, where it bites, and what we'd default to if you asked us to scope an agent feature tomorrow.

The frame: orchestration on a spectrum

On one end of the spectrum, you have the raw provider SDK — openai, @anthropic-ai/sdk, google-genai. You hand-roll the loop, the tool-call dispatch, the retries, the memory. Maximum control, minimum abstraction.

On the other end, you have LangGraph — an explicit, persistent state machine where nodes do work, edges decide what's next, and the whole thing is checkpointable. Maximum orchestration, with a real mental model to learn.

LangChain sits awkwardly in the middle: a grab-bag of abstractions that solves the small problems (prompt templating, output parsing, retrievers) while sometimes inheriting the design baggage from its 2023-era roots.

Most production agents need some orchestration. The question is whether you want to write it yourself, lean on LangChain's helpers, or commit to LangGraph's graph model.

Raw SDK: faster than you think for narrow problems

We'd reach for the raw SDK far more often than the popular framework discourse implies. If your agent is "one prompt with three tools and a retry loop," 80 lines of TypeScript will outperform any framework in build time, debuggability and bundle size. You can read the entire codepath in one sitting. When it breaks at 2am, you don't have to read someone else's source to figure out which hook ate the exception.

The raw SDK is the right choice when:

• The tool set is small (1–5 tools) and stable.
• The control flow is essentially "loop until the model stops calling tools."
• You don't need persistence across requests — every interaction is self-contained.
• You're going to deploy on the edge or in a serverless function and bundle size matters.

The raw SDK becomes painful when:

• You start writing your own conditional routing between steps.
• You need to pause for a human approval and resume hours later.
• You want to fan out to parallel branches and join the results.
• You're going to swap providers and you don't want to rewrite the loop.

When you hit those, you've outgrown the raw SDK — and you should reach for LangGraph, not LangChain.

LangChain: useful pieces, dangerous default

LangChain in 2026 is genuinely better than it was in 2023. The criticism it earned then — too many layers, too many abstractions, too much magic — has been partly fixed by langchain-core becoming a leaner runtime and langgraph taking over the orchestration concern.

But we still don't reach for the full LangChain runtime as a default. Here's why:

• The good bits are the small bits. Retrievers, output parsers, document loaders, prompt templates — these are unambiguously useful, and we use them all the time, alongside everything else.
• The dangerous bit is the agent runtime. The moment you ask LangChain to own the loop ("AgentExecutor"-style), you've handed over the most important code path in your system to a layer you didn't write. Debugging a stuck agent then means reading framework internals, not your own code.
• Versioning churn is still real. Less brutal than 2023, but breaking changes between minor versions are still a fact of life. Pin hard, upgrade deliberately.

Our rule: use LangChain as a toolbox, not a runtime. Pull in the retriever, the splitter, the parser — leave the agent loop to LangGraph or raw code.

LangGraph: the right answer when you have a real graph

LangGraph clicks the moment you stop describing agents as "loops" and start drawing them as state machines on a whiteboard. If your agent has named steps, conditional routing between them, human-in-the-loop pauses, or parallel branches that fan out and join — you have a graph. Writing it as a graph beats writing it as a tangle of if-statements.

What LangGraph buys you:

• Explicit state. You declare the state schema once; every node reads and writes to it. Debugging an agent then becomes "show me the state at step 4," not "show me 200 lines of console logs."
• Checkpointing. Persist the graph state to Postgres, Redis or memory. An agent can pause for a human approval on Monday and resume on Wednesday — the runtime just picks up where it left off.
• Streaming primitives that match modern UIs. Token streams, intermediate-step events, tool-call events — all first-class.
• Time-travel debugging. Replay any prior run from any node. This alone justifies the abstraction the first time prod misbehaves.

The cost: there's a real learning curve. The graph model is unfamiliar to engineers who've spent five years writing imperative request handlers. Plan for a week of ramp-up on a non-trivial agent. And keep your graph small — LangGraph rewards composition, not 40-node monoliths.

What we'd pick by use case

What we wish someone had told us

A few hard-earned notes:

• Don't pick the framework before the graph. Draw the agent on paper first. If it's a straight line with one loop, you don't need LangGraph. If it has branches and pauses, you do.
• Evals are not optional. Whatever framework you pick, the regression suite is what keeps the agent shippable across model upgrades. We write the evals before the agent — and we'd rather ship a smaller agent with evals than a bigger one without.
• Don't put the framework in your domain. Wrap it. Your business logic shouldn't import langchain or langgraph directly. A thin adapter at the edge lets you swap when the next thing inevitably shows up.

TL;DR

If you have a real graph — branches, pauses, persistent state — use LangGraph. If you have a narrow loop with a stable tool set, use the raw SDK and skip the abstraction tax. Either way, lean on LangChain for the small useful pieces (retrievers, parsers) without letting it own your agent loop.

The pattern that holds, across every agent project we've seen up close: the codebases that aged best picked the smallest tool that fit the shape — not the most fashionable one.

If you're scoping an agentic feature and want a second pair of eyes on the architecture before you commit, let's talk.