Cancelling an AI Agent Does Not Turn It Off

Imagine a portfolio review. Ninety minutes, eleven initiatives, three of them stopped. Among the three is an agent that was automating part of a back office process and had not produced the numbers anyone hoped for.

The slide is updated. The budget is released. The two engineers are reassigned by the end of the week.

At three the following morning, and every morning after, the agent runs. It still has its credentials. Its schedule still fires. Its integrations still resolve. Nothing in the meeting touched any of that, because nothing in the meeting was capable of touching any of that.

That scene is illustrative rather than reported, and it is structurally ordinary.

What Kind of System This Is About

The word "agent" is overloaded, so let me be specific with what I mean in this context:

This article concerns deployed systems with three properties:

• a persistent identity of their own, in the form of credentials or a service account
• autonomous triggers, meaning schedules or event subscriptions that fire without a person initiating them; and
• write-capable integrations, meaning the ability to change something in another system rather than only to read or to produce text for a human.

Systems with all three keep acting when nobody is watching. Systems missing any of them mostly do not, and the concern here largely does not apply to them. A chat assistant invoked by a user, with no schedule and no write access, is not the problem.

Gartner has forecast that more than forty percent of agentic AI projects may be cancelled by the end of 2027. That is a prediction about project cancellation rather than a measurement of how many cancelled projects leave live systems behind, and I am using it as context for the volume of cancellation events ahead rather than as evidence for the failure mode. The failure mode stands on its own logic.

Cancellation Is a Budget Event. Shutdown Is an Engineering Action.

These are different things, done by different people, at different times, and in most organisations only one of them has an owner.

Cancelling a project means stopping the funding, closing the workstream and releasing the people. It happens in a governance forum, is recorded in a portfolio system, and is complete the moment it is minuted.

Turning a system off means revoking credentials, disabling schedules, removing webhooks, deprovisioning infrastructure, notifying anyone who depends on the output, deciding what happens to the data it produced, and confirming that nothing broke. It happens in production, takes somebody a day or two, and is only complete when someone verifies it.

The gap between those two definitions of "done" is where this problem lives. The people in the room when a project is cancelled generally cannot perform the second action. The people who could have just been reassigned and were not asked.

What Stays Live

Worth being specific, because the abstraction hides how much surface area this is.

Credentials. Service accounts, API keys, OAuth grants, database roles. Often provisioned generously during development for perfectly good engineering reasons, and rarely scoped to a project's lifetime.

Triggers. Schedules, event subscriptions, queue consumers, webhook registrations. These live in different systems from the code, which is why they get missed.

Integrations. Connections into ticketing, CRM, finance, messaging. Each is a live path with permissions attached.

Downstream consumers. Somebody started using the output. A report, a dashboard, a spreadsheet, another automation. This is the one that causes real trouble.

The model or endpoint. Which continues to bill, and which is how a surprising number of these get discovered.

Here is what makes it different from an abandoned dashboard. A stale dashboard is ignored, and no harm accrues. A system with persistent identity, autonomous triggers and write access does not wait to be looked at. It acts, with the permissions it had on the day the project was cancelled, against systems that have changed underneath it since.

The Decommissioning Gap

The decommissioning gap is the missing ownership and controls for credentials, triggers, schedules, integrations, downstream consumers and data at end of life.

People sometimes reach for zombie agents as an image for the result. It is a useful picture, but the decommissioning gap is the serious term and the one worth putting in a policy document.

The point is that nothing in a typical deployment pipeline asks the question that would have prevented this. Deployment processes are built to answer whether it is safe to turn something on. Security review, access approval, change management, testing. That machinery exists and mostly works.

Almost nothing asks how it will be turned off, by whom, on what signal, and who will notice if it is not. That question has no natural owner. Engineering assumes governance tracks it. Governance assumes engineering does it. Security is looking at what was granted rather than what should have expired. And the project that would have coordinated it is the thing that just got cancelled.

This is an absence rather than a failure, and absences are harder to see than errors.

The Hard Part Is Downstream

If it were only credentials and schedules, this would be a hygiene problem with a technical fix.

The difficult part is that these systems produce output, and output acquires consumers. A finance analyst built a monthly view on a file the agent writes. An operations team's morning routine assumes a queue was triaged overnight. Another automation reads a table this one populates.

None of it is documented, because none of it was designed. It accreted.

Which means turning the system off is not a technical action with a predictable blast radius. It is a discovery exercise, and the standard way organisations perform it is to switch the thing off and see who complains. That works, in the sense that it produces the information. It works less well when the person who complains is a customer, or when nobody complains for eleven weeks and then a quarter-end process fails for reasons nobody connects to a portfolio review last spring.

The dependency was never documented, so the only way to find it is to break it.

The Minimum Decommissioning Record

Decide these at deployment, not at cancellation. The fix is cheap at the front end and expensive at the back, which is the usual shape of these things.

• Accountable role, plus the name of the person currently holding it. Roles survive reorganisation; names create follow-up. You need both.
• Credentials and their expiry. A date, or a project identifier that expires when the project closes. If credentials outlive projects by default, everything else here is decoration.
• Triggers and where they live. Which system holds the schedule, because it is usually not the one holding the code.
• Integrations and their write scope. What this can change, and where.
• Downstream consumers, as known today. An incomplete list beats none. It converts a discovery exercise into a notification.
• Data retention and disposition. What happens to what it produced and what it accumulated, including anything with a retention obligation attached.

Plus one thing recorded at the end rather than the beginning: evidence of shutdown. Who confirmed it, when, and what they checked.

On triggers for retirement, treat any rule as an example to be set per use case. A no-invocation threshold works for systems that should run often and means nothing for a process that legitimately runs quarterly or annually. Pick signals that match the workload: project cancelled, owner departed, contract ended, no invocation in a period appropriate to that system.

Then a periodic reconciliation nobody will enjoy. List every service account with write access, match against active projects, investigate the unmatched. The first run will find things. That is the exercise working.

What This Is Not

It is not an argument for heavier approval before deployment. These systems will proliferate and mostly should, and adding gates at the front to solve a problem at the back is how organisations accidentally choose slowness.

Retirement discipline is what makes fast deployment safe. An organisation confident it can cleanly remove things can afford to add them liberally. An organisation that cannot remove anything eventually stops adding, because the accumulated risk makes every new addition feel heavier than it is.

The Question

Name one AI system your company has deliberately switched off.

Then name who did it, how they knew it was safe, and how long it took to be sure nothing downstream broke.

If nothing comes to mind, that is not evidence nothing needed switching off. I would be interested to hear from anyone who has run the service account reconciliation, and what it turned up, because I suspect the first run is memorable.

Originally published on LinkedIn on August 25, 2026.