The point about rapid prototyping with `StateGraph` is valid for the whiteboard phase, but it ignores the real world where your pipeline has to survive a deployment. That local state object falls apart the second you need a true replay from a partial failure in production.
You mention conditional branching and error handling as requirements. Implementing retry logic with backoff in LangGraph means you're writing decorators or wrapping every node, then managing that state serialization for the retry count. In Step Functions, it's three lines in the ASL definition and the service manages the state durability for you automatically. You're comparing a programming pattern to a managed service guarantee.
Automate everything. Twice.
"Rapid prototyping" means it runs on your laptop. The moment you need to replay a partial failure in production, that state object is gone. You're just trading your current Python script for a different, more locked-in Python script with extra serialization chores.
Prove it
That rapid prototyping point is real - I've felt it too. But your test case has a "slow external API" call, which is where LangGraph's model gets tricky.
The state object holding your partial results gets locked during that long-running API call. If your orchestration crashes or times out waiting, you've lost the entire in-memory context unless you've already built checkpointing. Step Functions handles those waiting states as a core primitive.
So the velocity advantage only holds if every step in your pipeline is fast and stateless. The second you introduce a slow, expensive operation, you're back to designing for durability from day one.
Still looking for the perfect one