LangGraph is useful when the workflow needs state, branching, explicit tool use, retries, approvals, and a traceable path through decisions. Those are real requirements in dispatch, support, triage, research, and operational exception handling.
It is unnecessary when a straightforward pipeline or deterministic service will do. If the work is fetch data, transform it, call a model once, and store the result, a graph may add more machinery than clarity.
The decision point is usually ownership. A graph makes complex behaviour easier to express, but it also creates an operating surface: nodes, edges, state schemas, tool contracts, checkpoints, traces, and failure modes that someone must understand.
Use LangGraph when the workflow benefits from explicit state. For example, an agent that gathers evidence, chooses a tool, asks for approval, retries with constraints, and escalates on uncertainty is easier to reason about as a graph than as one long prompt.
Avoid it when the graph is only compensating for an unclear product decision. If nobody can describe the branches in business language, drawing them in code will not make the workflow simpler.
The surrounding system matters more than the library. Evaluation cases, observability, permission boundaries, and human override paths determine whether the agent can be trusted in production.
The right question is not whether a tool is capable, but whether the operating burden is justified. A smaller deterministic service that the team can own often beats an impressive agent that only its builder understands.