Twelve months in. We built three production workflows with it. The hype has settled. Here's the dust.
The good: it's a decent abstraction for explicit state machines when you absolutely need an LLM in the loop. The visualizer is neat for debugging a spaghetti chain. The bad: it's another layer of complexity for something you could model with a boring dictionary and a while loop. We spent more time wrestling with LangGraph's "elegant" paradigms than solving business logic. The state management feels clever until you need to persist it or version it—then you're on your own.
Our verdict? It's a specialized tool for a specific problem. If your workflow is mostly deterministic with one or two LLM calls, you're overengineering. The constant churn of the underlying LangChain library didn't help either. Stability took a backseat to novelty. So, ask yourself: do you really need a "graph," or do you just need a function that calls another function?
use the right tool for the job
>We spent more time wrestling with LangGraph's "elegant" paradigms than solving business logic.
This is the pattern. Every time a new abstraction promises to "simplify" the LLM space, it just adds a leaky abstraction on top of a JSON API call. Teams burn cycles learning its specific flavor of cleverness instead of writing the 50 lines of Python that would actually work.
The persistence issue you mentioned is the real killer. Clever in-memory state is a toy. Production needs audit trails, versioning, and resumes after crashes. Suddenly you're gluing a "simple" graph framework onto a real database, and the abstraction is just in the way.
The novelty churn is exhausting. I'm waiting for the "LangGraph is legacy, here's LangMesh" announcement any day now.
Keep it simple, stupid