Anyone using LangGraph for multi-turn dialog systems? Performance feedback

Let's cut through the marketing fluff. Everyone's hyping up LangGraph as the orchestration messiah for building "sophisticated" multi-turn agents, but I've yet to see a single post that talks about what it actually costs to run in production or where it falls apart when you scale beyond the tutorial's cute "research assistant" example.

I'm evaluating it for a customer support triage system that needs to maintain context across potentially dozens of turns, integrate with internal APIs, and occasionally not hallucinate its way into a liability. The stateful graph model is conceptually sound, but the moment you start adding conditional routing, human-in-the-loop nodes, and persistent checkpoints, the performance characteristics get... interesting. And by interesting, I mean "why is my Lambda timeout set to 15 minutes?" interesting.

My preliminary tests show the overhead of the `StateGraph` machinery itself is minimal, but the real bottlenecks are, unsurprisingly, the LLM calls you wrap inside it. The built-in persistence (using, say, Redis) for conversation threads adds a solid 80-120ms per state update, which is fine for low volume but makes you question if you're just building a very expensive queue. Have you actually measured the latency breakdown per "step" in a complex graph?

```python
# A simplified version of what actually worries me - the branching logic
def route_after_intent(state):
intent = state['intent']
if intent == "COMPLAINT":
# Triggers a subgraph with external API calls, doc search
return "handle_complaint"
elif intent == "SIMPLE_QUERY":
return "direct_llm_chain"
# This is where the tutorial ends. Reality adds:
elif intent == "ESCALATE":
# Now we need to pause, write to a ticket system, wait for human input
return "human_loop_node"
else:
# Fallback path that, without careful tuning, becomes a feedback loop of retries
return "clarify_intent"
```

So, for those running this in a live environment:
* What's your actual latency per full user turn, from request to final response, when your graph has 4-5 nodes?
* Are you using the native LangGraph persistence or rolling your own? If you rolled your own, was it because of cost, lock-in, or performance?
* Most importantly, have you compared the total cost and failure mode complexity against a simpler, more boring orchestration layer (like a finite state machine in your own code with directed LangChain calls)? I have a suspicion we're over-engineering with a framework that's still figuring out its production footprint.

I want to believe it's the right tool, but my AWS bill is already judging me.

-- cynical ops