I've been evaluating LangGraph this week to see if it could replace a simple but clunky set of functions we use for routing customer support tickets. The marketing hype suggests it's the go-to for "complex" agent workflows, but my need is basic: read ticket text, pick a category (Billing, Technical, General), and maybe ask a follow-up question if it's unclear.
My initial take: for a simple classifier, the learning curve is a tax you probably don't need to pay. You're bringing in a framework designed for state machines and cycles to do a one-shot classification. It feels like using a sledgehammer to push in a thumbtack.
Here's the quick comparison. Our current system is essentially this:
```python
def classify_ticket(text: str) -> dict:
# Simple LLM call with a structured output
response = client.chat.completions.create(
model="gpt-4-turbo",
messages=[{"role": "user", "content": f"Classify: {text}"}],
response_format={ "type": "json_schema" ... }
)
return json.loads(response.choices[0].message.content)
```
To do the same in LangGraph, you're suddenly thinking about:
* Defining a `State` object
* Writing nodes (functions) and conditional edges
* Compiling a graph
The complexity isn't from the classification logic—it's from the framework's inherent structure. The value only appears if you *need* that cycle (e.g., "classification unclear -> ask human for clarification -> re-classify"). For a simple, one-pass classifier, you've added layers of abstraction for zero gain.
So my blunt assessment: if your classifier is truly simple and doesn't require multi-step, stateful back-and-forth, stick with direct LLM calls or a simpler orchestration layer. LangGraph's learning curve is justified when your problem matches its strengths: loops, human-in-the-loop, and complex state transitions. For a basic router, it's overkill.
I'm curious if others have tried to force-fit simple use cases into it and what their experience was. Did you find a hidden benefit I'm missing, or did you also end up with a more complex system than you started with?
-- bb
I run a small data team at a mid-size SaaS company (about 200 employees, B2B). We handle a couple thousand support tickets a day and have a mix of simple routing and multi-step escalation flows. I've used LangGraph for one production workflow (a multi-turn triage bot) and still keep a plain function for the straightforward classifier. Here's the breakdown from doing both.
**Fit / target audience**
LangGraph is built for teams that already live in the LangChain ecosystem and need to manage state across multiple LLM calls or tools. The "simple classifier" use case is the exact opposite of that audience. If you're a solo dev or a small team without a dedicated ML engineer, the overhead of State, nodes, and edges will feel like a second job.
**Real pricing / hidden cost**
The framework itself is free, but the hidden cost is time. The OP's current function is about 10 lines. LangGraph's equivalent for the same one-shot classification took me roughly 3-4 hours to get right (including debugging graph serialization for a simple conditional edge). At $150-200/hr for a senior dev, that's $450-800 just to replicate something that already works. Plus LangGraph ties you to LangChain, which has its own versioning and dependency churn - I've seen two minor releases break our graph config in a month.
**Deployment / integration effort**
The plain function deploys as a single endpoint in any app framework. LangGraph requires either running a LangGraph server (API) or embedding the graph into your app. I tried both; the server route added a whole new container and a REST layer for what was a single function call. The embedded route meant dragging in LangChain and all its dependencies (pydantic, lcel, etc.). Our build time went from 8 seconds to 45 seconds.
**Where it breaks / honest limitation**
LangGraph's conditional edges are great for loops, but for a simple three-way classification they add unnecessary complexity. If you want to add a verification step later (e.g., "ask a follow-up question"), the graph approach does make that easier. But if you never need cycles, you're paying for a feature you don't use. Also, debugging a broken graph is harder than a broken function because you have to trace through node states - I've spent more time on that than on the actual logic.
**Where it clearly wins**
If your support escalation involves multiple steps (e.g., classify, then look up account, then decide to escalate or auto-reply, then maybe loop back to the user for clarification), LangGraph shines. I used it for a scenario where the LLM had to decide after each step what to do next, and the graph made that almost trivial to adjust. For a single-shot classifier, it's a sledgehammer.
**My pick**
Stick with the plain function for now. It's faster to build, faster to deploy, and easier to maintain. If you later discover you need multi-step reasoning or tool use, then sketch out the graph and migrate. But only make that jump when you hit the actual pain point, not before.
Data doesn't lie, but dashboards sometimes do.
Totally agree on the hidden time cost. Your point about debugging graph serialization for a simple conditional edge is spot on, that's where the frustration really hits.
I'd add that the tie-in to LangChain is another often overlooked constraint. If you're not already using their abstractions for prompts and memory, you're suddenly adding a whole new layer of dependencies just for routing. It locks you into their versioning and patterns.
For a simple classifier, keeping it as a plain, testable function is usually the right call. You can always wrap it in something more complex later if your workflow actually evolves to need cycles and state.
Yeah, that comparison hits home. I'm also trying to wrap my head around when to adopt these frameworks.
> the learning curve is a tax you probably don't need to pay
Exactly. For a single classification step, that tax gets you... what, exactly? You end up writing more glue code than actual logic. I've seen teams spend more time debugging the graph's state flow than improving the classifier prompt itself.
I'm curious - have you found a clean way to handle that "maybe ask a follow-up question" part without going full state machine? That's where my own simple function starts to feel messy.
Just here to learn.
Totally feel you on the "maybe ask a follow-up question" part. That's where I used to get stuck too, and it's the tipping point.
My go-to pattern now is a simple wrapper function that makes a single LLM call asking for a "confidence" score and a "clarifying question" string. If the confidence is below a threshold I set, I pause the flow and return the question to the user. The state is just the original ticket text plus the new answer, stored in my normal database. It keeps everything in one logical function without managing a graph.
The key is resisting the urge to build for the "what if" future. If you actually need a multi-turn conversation later, *then* you can refactor into a state machine. Starting with LangGraph for that feels like building a highway for a bike path.