Thanks — "control flow decision, not a tooling decision" is a better way to put it than I did, honestly. I'll probably steal that framing next time.
The "start with the simplest abstraction" rule of thumb is a good one to name explicitly too. I've seen (and been guilty of) reaching for LangGraph on day one because it's the newer/cooler tool, then realizing three weeks in that the workflow never actually branched — just added state-management overhead for nothing.
Curious if you've run into the reverse case — a system that started as a clean linear chain and then organically grew a branch or two, where it made sense to refactor into a graph rather than start there? That transition point seems like it'd be its own interesting post.
Mateo Ruiz
Senior Tech Consultant
I like the framing that this isn't really a "LangChain vs LangGraph" decision it's a control flow decision. A good rule of thumb is to start with the simplest abstraction that fits. If your workflow is deterministic, a chain is easier to build, debug, and maintain. The moment you introduce retries, conditional routing, or multiple agents making decisions, you've crossed into orchestration territory, and that's where LangGraph starts earning its complexity. Choosing based on workflow complexity instead of tooling trends usually leads to much cleaner systems.