Why I'm Not Using LangGraph in Production (After Trying)

The short version: LangGraph is the framework everyone is supposed to be using for agent orchestration in 2026. I've built 3 production agent systems with it and 4 without. The non-LangGraph systems were faster to ship, easier to debug, and easier to hand off. The framework solves real problems for some teams. For solo founders shipping production AI products, the abstraction tax usually isn't earned.

What LangGraph actually does

LangGraph is a state-machine framework for agent orchestration, built by the LangChain team. You define:

• Nodes — discrete steps (call this LLM, call this tool, query the DB)
• Edges — transitions between nodes, often conditional on state
• State schema — typed structure passed between nodes
• Checkpointer — durable persistence so you can pause/resume

You wire them together and the framework executes the graph, manages state transitions, and handles checkpointing.

What LangGraph does well

Three things, genuinely:

1. Durable state across sessions. If you need an agent that pauses for 3 days waiting for human approval, then resumes exactly where it left off — LangGraph's checkpointer handles this elegantly. Building this from scratch is non-trivial.
2. Human-in-the-loop checkpoints. Pausing an agent for human review at specific nodes is built-in. For workflows like legal contract review or compliance approval, this is real value.
3. Visualization. The graph structure is naturally visualizable. For complex multi-agent systems with non-trivial branching, seeing the flow as a diagram helps a lot.

If your system needs any of those three out of the box, LangGraph earns its complexity. Most agent systems I build don't need any of them.

What bit me in production

From the 3 LangGraph projects I've shipped:

1. Debugging is a tax. When something breaks inside the graph, you're reading framework internals — checkpointer state, edge condition evaluation, node retry logic. With plain code, the stack trace points to your function. With LangGraph, it points to the framework, and you trace back to figure out which of your nodes triggered it.
2. Type system fights. The state schema is typed, but the typing is inconsistent across versions and across Python vs TypeScript. I spent meaningful time on type-error puzzles that didn't exist in plain code.
3. Version churn. LangGraph and LangChain release breaking changes regularly. Pinning versions works until you need a feature in a newer version. Upgrading is non-trivial because the framework is evolving fast.
4. Hidden coupling. The framework encourages you to put logic into edges and conditional functions. By month 3, the "graph" is so dependent on the graph structure itself that refactoring out is a rewrite.
5. Onboarding cost for collaborators. When someone new joins, they need to learn the framework before they can read the code. With plain Python or TypeScript, they read the code.

None of these are dealbreakers individually. Together, they consistently slowed me down.

The plain-code alternative

Here's the same agent in plain TypeScript with the Anthropic SDK:

import Anthropic from "@anthropic-ai/sdk";
const claude = new Anthropic();

type AgentState = {
  messages: Anthropic.MessageParam[];
  tools_used: string[];
  done: boolean;
};

async function runAgent(initialPrompt: string) {
  const state: AgentState = {
    messages: [{ role: "user", content: initialPrompt }],
    tools_used: [],
    done: false,
  };

  while (!state.done) {
    const response = await claude.messages.create({
      model: "claude-opus-4-7",
      max_tokens: 4096,
      tools: TOOLS,
      messages: state.messages,
    });

    state.messages.push({ role: "assistant", content: response.content });

    // Handle tool use
    for (const block of response.content) {
      if (block.type === "tool_use") {
        const result = await executeTool(block.name, block.input);
        state.tools_used.push(block.name);
        state.messages.push({
          role: "user",
          content: [{ type: "tool_result", tool_use_id: block.id, content: result }],
        });
      }
    }

    // Termination logic — explicit, not framework-managed
    if (response.stop_reason === "end_turn") state.done = true;
    if (state.messages.length > 50) state.done = true; // safety cap
  }

  return state;
}

That's the whole agent loop. ~30 lines. No framework. Every transition is explicit. Stack traces point to my code. State is whatever shape I want. Persistence is whatever DB I'm already using.

For 80% of agent systems I ship — including the agent behind Maya, the 11-agent AutoResearch system, and most client deliverables — this pattern is what I reach for.

When I would use LangGraph

Three specific cases where it's the right tool:

1. Multi-day, durable workflows. Agent runs for 5 days, pauses for approval at day 2, resumes at day 4. The checkpointer is genuinely the cleanest way to do this. Building it from scratch is a real project.
2. Heavy human-in-the-loop. Legal review, financial approval, compliance gating — workflows with explicit human checkpoints at known nodes. The framework's built-in pause/resume + UI hooks are valuable here.
3. Teams already standardized on it. If your team uses LangGraph across many projects, the consistency is worth more than the per-project cost. Don't fight your team's patterns just to be pure.

Outside those three: plain code wins on time-to-ship, debuggability, maintainability, and ops cost.

The general rule on agent frameworks

This applies beyond LangGraph — same logic for CrewAI, AutoGen, smol-agents, etc:

1. Build your first 2–3 agent systems in plain code. You learn the actual shape of the problem you're solving. You build vocabulary for the patterns. You feel the pain points concretely.
2. Then look at frameworks. Once you know the patterns, you can evaluate whether a framework's abstractions match your patterns or fight them. The decision becomes informed.
3. Don't adopt a framework because the README sells it well. READMEs are written by people who succeed with it. Talk to people who tried and stopped using it. Their reasons are usually instructive.

Related reading

For the actual code patterns we use in production AI: How I Built an AI Voice Agent (no framework). On the architecture decision of long-context vs RAG: Why I'm Still Building RAG in 2026. On the failure modes of production AI: Why RAG Fails in Production.

Frequently Asked Questions

Bottom line

LangGraph is a real tool that solves real problems for some teams. For most production agents I build — short-running, ephemeral state, no human-in-the-loop — plain code wins on every dimension that matters: time-to-ship, debuggability, maintainability, onboarding cost. Build by hand first. Reach for frameworks when the problem you have actually matches what they solve.

Disagree? I'm genuinely interested in counter-examples — email hello@quickcomet.com with what you've shipped on LangGraph that wouldn't have been better as plain code.