Almost everything written about AI in a business is about adding it. Add an assistant, add a workflow, add a scheduled summary, add another agent that clocks on while everyone sleeps. We write some of that ourselves, and we mean it.
But there is a quieter skill that nobody sells, because there is no invoice attached to it. Once you have a few automations running, the useful question stops being "what else can we automate?" and becomes "which of these is now costing more attention than it saves?"
We have had to learn that one on ourselves. Some of our own scheduled agents got quieter over time. A couple got simpler. One or two we turned off entirely. None of them failed in the dramatic sense. They just stopped being worth the small, ongoing tax that every automation charges.
We stopped a report nobody used
The clearest example was a scheduled summary we built for ourselves.
It pulled together a slice of activity each day, wrote it up in plain language, and dropped it where the team would see it first thing. For about two weeks it was genuinely interesting. We read it, talked about it, felt slightly more on top of things.
Then we stopped opening it.
The work kept running. It was still correct, still arriving on time, still quietly using a model's time and a small amount of ours whenever it needed a tweak. The only thing missing was a reader. We had automated the production of something nobody had decided to act on.
We cut it to weekly. Then we noticed the one line in it that ever changed a decision, and realised that line was something you would want to pull up when you needed it, not have pushed at you every morning. So we turned the scheduled version off and folded the useful part into work we already looked at.
That is the whole shape of it. The automation was not broken. It was answering a question we had stopped asking.
Four signs an automation should stop
After a few of these, the pattern is recognisable. An automation is usually worth retiring, or at least narrowing, when it shows one of these:
It does not repeat enough. Automation pays for itself through frequency. A task you do twenty times a week is worth wiring up. A task you do twice a month often is not, once you count the cost of building it, maintaining it, and remembering how it works when it breaks. We have wired up things that felt clever and then watched them fire so rarely that doing the job by hand would have been quicker over a year.
The inputs vary too much. Some work looks repetitive but is different every time in ways that matter. The automation handles the common shape and quietly mangles the exceptions, so a person ends up checking every run anyway. At that point you have not removed the work. You have added a layer of output to inspect on top of it.
The review takes longer than the task. This is the one that catches people. An automation that produces a draft you then have to read carefully, correct, and second-guess can cost more total attention than just doing the thing. It feels productive because something is happening without you. It is not productive if you would have been faster unaided.
Nobody reads the output. A summary, a report, a flag, a digest that lands and is never acted on. This is the easiest to spot and the hardest to admit, because the work is still running and still looks like a system doing its job. A system with no reader is just tidy waste.
None of these mean the original idea was wrong. They mean the work changed, or the team changed, or the thing was always a slightly worse fit than it looked in the demo. Catching that early is the skill.