When Should You Delete an Automation You Built Last Year?

When Should You Delete an Automation?

When nobody can name its owner, nobody has looked at its output in a quarter, and nothing downstream would break if it stopped. If all three are true, the automation is not saving you time any more. It is a piece of unowned software with your credentials in it.

We think about this a lot because we build these systems. The uncomfortable truth of automation work is that the second year is harder than the first. Year one you are adding capability. Year two you are maintaining a pile nobody chose to assemble.

This is an opinion piece rather than a tutorial. Our position is that retiring automations deserves as much process as building them, and almost nobody gives it any.

Why Does Nobody Ever Turn an Automation Off?

Because turning one off feels risky and leaving it on feels free. If you delete a workflow and something breaks, that is your fault in a visible way. If you leave it running and it quietly costs money, nobody will ever trace the cost back to you.

The incentives are completely lopsided, and they are the same incentives that leave old marketing pages up forever. Nobody has been fired for leaving a Zap enabled. So the pile grows, and every new hire inherits a stack they did not build and cannot explain.

There is a second reason that is more sympathetic. Most automation tools make it easy to see what exists and hard to see what matters. You get a list of workflows and a run history. You do not get a column saying who needs this and what happens if it stops.

So the decision requires human context that the tool does not hold, and gathering that context takes an afternoon nobody has scheduled. The pile is not a discipline failure. It is a missing ritual.

What Does an Unused Automation Actually Cost You?

Three kinds of cost, and only one of them shows up on an invoice. Direct spend on runs and tokens. Attention spent reading alerts that do not matter. And risk, because an unowned integration holds live credentials to systems that do matter.

The security industry has a name for the third one. The OWASP API Security Top 10 for 2023 lists API9:2023 Improper Inventory Management as one of its ten risks, and its description is a good summary of the whole problem. It notes that "APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important," and that "a proper inventory of hosts and deployed API versions also are important to mitigate issues such as deprecated API versions and exposed debug endpoints."

That is a security document describing your automation folder. The same list also names API10:2023 Unsafe Consumption of APIs, which is what an old integration becomes when the service on the other end changes and nobody is watching.

The attention cost is the one we see hurt teams most. When a channel fills with alerts from workflows nobody owns, people stop reading the channel. Then the alert that mattered arrives and nobody sees it. An automation that trains your team to ignore notifications has negative value, not zero value.

How Do You Find the Automations Nobody Remembers?

Follow the credentials, not the workflow list. Every automation authenticates as something. Pull the list of API keys, service accounts, integration tokens, and webhook endpoints across your main systems, then work out which automation each one belongs to.

This works because credentials are harder to hide than workflows. A workflow can live in someone's personal account in a tool finance has never heard of. The key it uses still shows up in the target system's settings page.

Some vendors make this genuinely easy, and it is worth using what they give you. Anthropic's documentation, for example, describes an audit path for exactly this: go to the Usage page in the Console, click Export, and "review the downloaded CSV to see usage broken down by API key and model." A key with usage you cannot explain is the thread to pull.

Write the result down somewhere durable. A one line description per automation, its owner, its trigger, and what breaks if it stops. We covered how we keep that record in our piece on documenting AI automations, and the inventory is the part most teams skip.

Which Ones Should Go First?

The ones built for a situation that no longer exists. A campaign that ended. A report a departed manager asked for. A sync to a tool you stopped paying for. These are the easy wins because nothing is waiting on them and nobody will defend them.

Next go the automations that duplicate something a product now does natively. This category grows every year as tools ship features that used to need glue. We have removed plenty of our own work for this reason, and it is a good outcome rather than a waste.

Then the ones whose output nobody reads. A daily digest going to a channel with no replies in six months is not informing anyone. Turn it off and see if a single person notices. In our experience the silence is the answer, and it arrives fast.

What we do not touch first is anything holding a process together that people have quietly built habits around. Those need a conversation, not a delete key.

How Do You Retire One Without Breaking Something?

Disable it before you delete it, and leave it disabled long enough for a full cycle of whatever it did. A monthly report needs more than a week of silence to prove nobody wanted it. This is the whole technique, and it removes nearly all the risk.

We also announce it. A short note saying this workflow will be switched off on a given date, with a name attached, and one line about what to do if you depended on it. Half the time somebody replies and you learn something the inventory did not tell you.

Then delete rather than leave disabled forever, because a disabled workflow with live credentials is still a credential problem. Revoke the key, remove the webhook endpoint, and close the integration on the far side. Deleting the workflow and leaving the API key active is the most common half finished version of this.

Our order is announce, disable, wait a full cycle, revoke credentials, then delete. Skipping the revoke step is the one that comes back later.

What Should You Keep After You Delete It?

The prompt, the logic, and the reason it existed. Automations are cheap to rebuild and expensive to rediscover. What took the time was working out the rules, not wiring the steps together.

So we keep a short record for every retired automation. What it did, why we stopped, and the prompt or logic in full. When the same need comes back in eighteen months, and it often does, the rebuild takes an hour instead of a week.

Keep any output that has records value too. If an automation was writing to a log or a table someone might need for an audit, export it before you turn anything off. We wrote about that side of things in our piece on accountability for AI automations.

How Often Should You Do This?

Once a quarter, on a calendar invite, with one named person responsible. It takes an hour or two once the inventory exists, and it never happens at all without the invite. That is the entire recommendation.

We prefer quarterly over annual for a specific reason. The forcing functions arrive faster than that. Vendors deprecate things on their own schedule, and their notice periods are measured in weeks and months, not years.

Anthropic's deprecation policy is a good illustration of the timescale. Its documentation says it provides "at least 60 days' notice before model retirement for publicly released models," and its own history shows how tight that gets in practice: Claude Opus 4.1 was deprecated on 5 June 2026 and retired on 5 August 2026, exactly two months later.

The same page shows parameter level changes that break code quietly. It documents temperature, top_p, and top_k as deprecated from Claude Opus 4.7 onward, returning "a 400 error when set to a non-default value" on those models. An annual review finds that six months after it started failing. We went deeper on this in our piece on model deprecations and your automations.

Does This Get Worse With Agents?

Yes, and that is our main worry about the current direction. A traditional workflow does one known thing. An agent decides what to do at run time, so its blast radius is defined by its permissions rather than by its steps. An unowned agent is a much larger object than an unowned Zap.

The inventory problem also changes shape. You can read a five step workflow and know what it touches. You cannot read an agent and know what it will touch next Tuesday. So the record you keep has to be about granted access rather than about configured actions.

We want to be careful not to overclaim here. We have not seen published industry data measuring how often forgotten agents cause incidents, and we are not going to invent a figure. What we can say is that the review ritual matters more when the thing being reviewed has discretion.

What Would We Do in Your Next Quarter?

One meeting and one spreadsheet. List every automation you can find, add an owner column, and leave the rows you cannot fill in blank. Those blank rows are the whole finding, and they usually surprise the person who called the meeting.

Then turn off the three most obviously dead ones, with an announcement and a wait. Nothing will break, the team will see that turning things off is survivable, and the ritual will be easier to schedule next quarter.

If you would rather have someone from outside do the inventory, because it is faster when nobody is defending their own work, we are happy to help. You can find us at phoenix.studio.