The Automation You Should Delete

Nobody writes this post because there is nothing to sell at the end of it. Every article about automation is about building one. The tool vendors write them, the consultants write them, and the arithmetic is always forward-looking: here is what this will save you.

The problem shows up in year two. By then you are not running one automation, you are running thirty. Some of them produce a report nobody opens. Some of them run against a system that was replaced eight months ago and are quietly writing to a table nothing reads. Two of them do the same job slightly differently, and nobody remembers which one is authoritative. One breaks every few weeks and someone fixes it every few weeks, and the fixing has become a job that exists only because the automation exists.

None of this appears on any dashboard, because a dashboard of automations shows you which ones are running, not which ones are useful. Those are completely different questions, and the second one is only ever answered by someone deliberately sitting down to ask it.

This is how to run that audit, and — the harder part — the criteria that let you actually delete things, including the ones you personally built.

Why the pile grows and never shrinks

Automations accumulate because building one is a visible win and deleting one is an invisible one, so the incentives only ever point in a single direction.

Every automation has a moment of creation where someone is pleased. There is a before and an after, a manual process replaced, a small ceremony. Nothing comparable exists for deletion. Removing a workflow produces no demo, no announcement, no metric that improves. It looks, from outside, like you did nothing all afternoon.

Three other forces hold the pile in place:

Running costs are hidden and diffuse. A workflow that costs a small monthly amount in API calls and twenty minutes of someone’s attention every fortnight has a real annual cost, but that cost is spread across a tool bill nobody itemises and a person who never logs the time. There is no line item to notice.

Deleting feels riskier than keeping. If you remove something and it turns out to matter, that is a visible mistake with your name on it. If you keep something useless, that is nobody’s mistake at all. Any environment where the two errors carry asymmetric consequences will systematically accumulate the second one.

Nobody knows what depends on what. After eighteen months, workflows read each other’s outputs in ways that were never documented. This is the real blocker, and it is why most people who intend to do this audit stop after the first hour.

The result is that the cost of automation compounds silently while the benefit is counted once, at build time. The build-side version of this arithmetic — counting the second year properly before you commit — is should you automate this: the arithmetic that decides. This post is the other half: what to do when you did not do that, and now there are thirty of them.

Step one: list what is actually running

Inventory everything before judging anything, because the audit fails on the things you forgot exist rather than the things you decided to keep.

The list is harder to assemble than it sounds, because automation is never in one place. Work through, at minimum:

• The automation platform itself — the scenarios, zaps, flows, whatever the tool calls them
• Scheduled jobs in your code repositories and CI
• Database triggers and scheduled queries
• Email rules and filters, which are automation and are always forgotten
• Spreadsheet scripts, which are the single most under-documented category in most businesses
• Anything running on somebody’s personal machine or personal account

That last one deserves emphasis. In most small businesses at least one important process runs on a laptop belonging to a specific person, under their personal login, and it will keep working right up until they leave. Finding those is worth the audit on its own, independent of anything you delete.

For each item, record five fields and nothing more, because a heavier template is how this audit dies:

The third column is the one that does the work. Insist on a name. “The ops team” is not an answer; it is the absence of one, and in practice it almost always means nobody.

Step two: find the ones producing output nobody consumes

The fastest deletions are the workflows whose output has no reader, and you can find them empirically rather than by asking.

Asking does not work. Ask anyone whether they need a report and they will say yes, because saying no feels like admitting the last two years were wasted, and because they might need it someday. You will get a hundred percent retention rate from any survey you run.

So test instead. Three methods, in increasing order of confidence:

Check the access logs. Most systems can tell you when a document, dashboard or table was last opened, and by whom. A weekly report last opened four months ago has answered the question.

Break it quietly. Stop the workflow — do not delete it, just pause it — and wait. Set yourself a reminder for a month out. If nobody has asked, that is real evidence, obtained at almost no risk. If someone asks on day three, you have learned something useful and you turn it back on in a minute. This is the single most effective technique in the whole audit and the one people are most reluctant to use.

Change the output subtly. For reports where someone insists they read it, an obvious placeholder in a header, or a deliberately wrong total, will settle the question within one cycle. Use this one carefully and only on internal reporting — the point is to learn whether the report is read, not to catch a colleague out, and it will be received badly if it looks like the latter.

The pause method should be your default. It converts an argument about whether something is needed into an experiment, and experiments end arguments.

Step three: cost the ones that survive

Cost each remaining workflow at its true annual figure — infrastructure plus maintenance plus attention — because the maintenance term is usually the largest and is never counted.

Three components:

Direct running cost. API calls, platform seats, compute, the per-task pricing that automation platforms charge. Usually small, usually the only number anyone has.

Maintenance. Every time it broke in the last year, times the time it took to fix, times a realistic hourly cost. Then add the cost of the fear it generates — the checking, the “did that run?” messages, the fact that someone glances at it every Monday. That checking is a genuine recurring cost of the automation existing and it belongs in the total.

Attention on failure. This is the one that separates cheap automations from expensive ones. A workflow that fails loudly and obviously is cheap: it breaks, you know, you fix it. A workflow that fails silently — still running, still green, producing wrong or stale output — is enormously expensive, because the cost is not the fix, it is every decision made on bad data between the failure and its discovery. That failure mode is common enough to have its own treatment in the automation failure nobody catches, and in a deletion audit it should be treated as a heavy negative on any workflow that cannot prove it would notice its own failure.

A useful sharpening: for each workflow, ask “if this produced subtly wrong output starting today, how long until someone noticed?” If the answer is more than one cycle, that workflow is carrying a large uncosted liability, and the bar for keeping it should be correspondingly higher.

Working out what depends on what, without a full map

Establish dependencies by observation rather than by reading configurations, because the configuration will not tell you and reading it is where this audit usually dies.

This is the blocker named earlier, and it deserves a real answer rather than “document everything,” which is advice nobody has ever successfully followed retrospectively. The practical approach is to stop trying to build a complete map and instead answer one narrow question per workflow: what reads this thing’s output?

Three techniques, cheapest first:

Follow the destination, not the workflow. Do not ask what the automation does. Ask what it writes to — a sheet, a table, a channel, an inbox — and then ask what reads that. Destinations are finite and enumerable; execution paths are not. Most of the dependency graph in a small business is a dozen shared destinations with many writers and few readers.

Grep for the identifiers. Search your repositories, scripts and spreadsheet formulas for the sheet ID, table name, webhook URL or channel the workflow touches. This finds the machine-side dependencies quickly and is far more reliable than memory. What it will not find is a human who opens something manually every Tuesday — which is what the pause test is for.

Pause and watch the errors. The most honest dependency map is the one that appears when you turn something off. Anything downstream that genuinely depended on it either errors, goes empty, or produces a visible gap. Pause during a period you are watching, not before a week off.

The mindset that makes this tractable: you do not need to know everything that depends on it, only whether anything does. That is a much cheaper question, and the pause test answers it directly for the whole pile without any mapping at all.

The automations that call a model

Audit AI-dependent workflows on a shorter cycle and against different criteria, because they degrade in ways scripted automations do not.

A workflow that transforms data deterministically either works or throws an error. One that sends a prompt to a language model and acts on the reply has a third state: it runs successfully and the output quality has moved. That distinction changes what the audit needs to check.

Four things to look at specifically:

Quality drift after a model change. The prompt that produced good output eighteen months ago is not guaranteed to produce good output on the current model version. Nothing announces this. Nothing errors. The output just becomes subtly worse, or differently shaped, and downstream steps that parse it start behaving oddly. Any AI workflow whose output nobody has read end-to-end in the last quarter should be treated as unverified.

Cost that scales with something you are not watching. Deterministic automations have predictable costs. Model calls cost per token, retries multiply that, and a change upstream that makes inputs longer can raise the bill substantially without changing anything visible. Check spend per run over time, not total spend.

Silent widening of scope. A workflow built to summarise five documents a week that now runs over five hundred is a different workflow with the same name. Ask what the volume was at build time.

Whether the output is still checked by anyone. Human review of AI output has a strong tendency to decay into rubber-stamping, especially where the output is usually fine. A review step that has never once rejected anything is not a control, and the workflow should be audited as though it has no review at all — because functionally it does not.

The deletion criteria below apply to these too, with one addition specific to them: delete any AI workflow whose output nobody could evaluate if it were wrong. If the task requires judgement that the reader does not have — a summary of documents they will never open, a classification they cannot check — then the output is being trusted rather than used, and trusted-but-unverifiable output is a liability whatever it costs to produce.

The deletion criteria

Delete on any one of these, without requiring the others.

1. The output has no named reader. Established by the pause test, not by asking. This is the largest category and the easiest.

2. It duplicates another workflow. Two automations producing overlapping outputs is worse than either alone, because now there are two numbers and a standing argument about which is right. Keep the one whose output is actually referenced downstream; delete the other rather than “keeping it for comparison.”

3. Maintenance exceeds the manual cost. If fixing it costs more per year than doing the task by hand would, it has stopped being automation and become a hobby. This calculation should use the current volume, not the volume you expected when you built it — many workflows were justified by growth that did not arrive.

4. It automates a process that should not exist. The most valuable deletions. A workflow that reformats a report so it can be pasted into a second system is not a solution to anything; it is a symptom of two systems that should be connected or one that should be retired. Automating a bad process makes it permanent, because it removes the friction that would otherwise have forced someone to fix it.

5. It runs against a system nobody uses any more. Surprisingly common, entirely painless to remove, and easy to find: check the last successful write, not the last successful run.

6. Nobody can explain what it does. If no one in the business can state its purpose in a sentence and the person who built it has gone, the risk of keeping it exceeds the risk of pausing it. Pause, wait a full cycle, then delete.

7. It was built for a client, a campaign or a season that has ended. These have a natural expiry that nobody ever actions.

The sunk-cost argument, and how to answer it

The objection you will hear is that removing it wastes the work that went into building it — and the answer is that the work is already spent either way.

The clean version: the build cost is gone regardless of what you decide today. Keeping the automation does not recover it. The only live question is whether its future value exceeds its future cost, and the past does not enter that calculation. That is the argument in one sentence and it is correct, but on its own it rarely persuades, because the objection is not really economic.

The real objection is that someone built it and deleting it feels like a verdict on them. So handle it as such:

• Separate the decision from the person. “This was the right build at the time and the conditions changed” is usually true and costs nothing to say.
• Count the deletions as output. If the audit’s results are reported as “twelve workflows removed, annual cost reduced, maintenance load down,” deleting becomes a visible contribution rather than an admission. This one change in framing does more than any criteria list.
• Archive rather than destroy. Export the configuration, put it somewhere findable, note the date and reason. It costs almost nothing and removes the entire emotional weight of the decision, because nothing is actually being lost.

Watch for the two arguments that sound like reasons and are not. “It costs almost nothing to leave it running” ignores every cost except the invoice, and the invoice is the smallest one. “We might need it again” is true of everything and therefore decides nothing — the archive answers it directly.

What to do instead of deleting, when deletion is wrong

Not everything that fails the audit should be removed; three other outcomes are often better.

Reduce the frequency. A daily report that gets read weekly should run weekly. This is the most common right answer and it is almost never considered, because frequency is set at build time and never revisited.

Convert push to pull. Rather than generating and sending a report on a schedule, make the same view available on demand. Removes the run cost, removes the noise, and — usefully — tells you exactly who wants it, because now they have to ask.

Replace it with an alert. Many reports exist so that someone can check whether a number is within range. If that is the actual purpose, the report is the wrong shape. A workflow that stays silent and speaks only when the number leaves the range does the same job with a fraction of the attention cost, and it is far more likely to be noticed when it matters.

That last conversion is worth looking for aggressively. A large share of recurring reporting is a human being performing a threshold check that a machine should be performing.

Running it so it happens more than once

Attach the audit to something that already recurs, because a standalone annual review is the thing that gets postponed indefinitely.

What works:

• Tie it to a renewal. Whenever the automation platform’s annual bill arrives, audit before renewing. The bill provides both the trigger and the motivation, and it is the one date that will not slip.
• Give every new automation a review date at creation. One field, set six or twelve months out. It is not a commitment to delete; it is a commitment to look. Deciding when to check while you are building is far easier than deciding to check eighteen months later.
• Write the purpose down at build time, in one sentence, with a named owner. Nearly every difficulty in this audit traces back to that sentence not existing. The same discipline that makes an automated system auditable after the fact — knowing what it was for, who owns it, and what it touched — is the argument in what to log when an AI agent acts on your behalf, and it pays back here.
• Do the pause test continuously, not annually. When something breaks, do not fix it immediately. Wait a few days and see who notices. Outages are free audits and most people waste them by restoring service before learning anything.

That last one is genuinely useful. Every unplanned failure answers, for free, the exact question the audit is trying to answer — and the reflex to fix things quickly destroys the evidence before anyone reads it.

The honest summary

The reason to do this is not the money, though the money is real. It is that a business running thirty automations nobody has reviewed does not actually know how it works.

Each undeleted workflow is a small piece of unowned machinery making decisions, moving data, and occasionally being wrong in ways nobody is positioned to catch. The cost of that is not on any invoice. It shows up as a number in a meeting that is subtly wrong, or a process that everybody works around without knowing why, or a system that only one person understands and that person is on leave.

Automation is supposed to reduce the amount of your business that you have to hold in your head. Past a certain point, unaudited, it does the opposite — and the tell is not that things break. It is that when something does break, it takes a week to work out what it was for.