When a workflow fails, replacing it from scratch can erase working rules, hidden exceptions and operational knowledge. But endlessly patching a system with no owner or recovery model is not sustainable either.
First establish the last known good state
What changed: credentials, API behavior, fields, model output, volume, human process or deployment? Read the logs and external receipts before retrying anything. If an action may have reached a third party, its result is unknown until the destination is checked.
Do not replay a payment, message or application merely because the local process timed out. Check the external post-condition first, then decide whether a new attempt is permitted.
Repair when the boundary is local
A repair is often enough when the workflow has a known owner, stable inputs and outputs, recoverable state, and only one or two failing edges. Fix the broken contract, make exceptions visible, add a safe recovery path, and test the real route.
Rebuild when the structure cannot carry the work
Consider a bounded rebuild when nobody can explain the route end to end, failures cannot be reconciled, permissions are uncontrolled, or every new change breaks another lane. Preserve a written inventory of triggers, data contracts, decisions and negative lessons before replacing anything.
Where AI belongs
Use deterministic rules for known business constraints. Use a model for tasks that benefit from interpretation, such as classifying an ambiguous request or drafting a summary, and keep source evidence and human approval where external effects matter. The model should not become the only memory or the only gate.
This is a general decision framework, not a claim about a particular customer deployment or guaranteed savings.
Need to inspect a real route rather than debate the tools?
Describe your workflow