Stopping should be a normal outcome
If a project can only end in success, the ones that aren’t working continue anyway. Treating withdrawal as a legitimate result is what makes stopping criteria agreed in advance meaningful rather than decorative.
Say why, specifically
“It didn’t deliver” teaches nobody anything. “Review took longer than doing the task”, “the knowledge didn’t exist”, “volume was too low to repay maintenance” each point at a different fixable condition — and the last is a reason to not use AI at all that may change later.
A feature switched off with a written reason is research. One that quietly stops being mentioned is waste.
Tell the people who used it
Staff who built habits around it need warning and an alternative. Customers who saw it need to not encounter a dead interface — the same announce, disable, delete sequence as any feature removal.
Keep the corrections
The evaluation set, the corrected outputs, and the documented rules are the accumulated asset and they outlive the feature. Deleting them means starting from nothing if you revisit the idea in a year.
Decide what happens to the data
Conversation logs and retrieval indexes need retiring under whatever retention policy you set, not left running. That obligation does not switch off with the feature — personal data outlives the product.
Note the conditions for revisiting
Write down what would have to be true to try again: better documentation, higher volume, a cheaper model. That turns a failure into a dated hypothesis, which is a far better artefact than a bad memory.