#13
Failure Routing Makes Agents Reliable
A reliable agent is not the one that never fails.
It is the one whose failures have recovery routes.
In production LangGraph systems, the risky question is not only:
Did this node succeed?
The more important question is:
If this node failed, where should the graph go next?
A node that calls an external tool or service can fail for many reasons:
- Timeout
- Invalid input
- Product not found
- Out-of-stock inventory
- Missing product reference
- Service unavailable
These failures should not all be handled the same way.
If a node throws an error without a recovery path, the graph may stop.
That is acceptable for unexpected technical failures.
But expected business failures should become state.
The node should store a typed failure reason.
Then a recovery router should decide the next node.
- timeout: retry with limits
- invalid_input: ask the user to correct it
- product_not_found: clarify the product
- out_of_stock: suggest alternatives
- repeated_failure: escalate or stop safely
Not every failure should be retried.
Retrying a timeout may be useful.
Retrying an out-of-stock product is useless.
The clean pattern is:
- Check success or failure.
- Store the failure reason in state.
- Include whether the failure is retryable.
- Store the current retry count and max retry limit.
- Route after risky nodes.
- Send each failure type to the correct recovery node.
- If the failure is retryable, increment retryCount and return to the original node.
- Produce the final answer only when the workflow has a safe user-facing result.
A production graph should not collapse when the smooth path breaks.
Reliability is not about avoiding failure.
Reliability is about making failure controlled.