Every AI adoption framework tells you how to start. How to assess workflows, how to prioritise, how to build, how to deploy. Almost none of them tell you when to stop. What happens when an agent should no longer be running? When the tool it was built on gets deprecated? When the business need disappears? When the cost-benefit equation flips negative?
The default answer is: nothing happens. The agent keeps running. Performance quietly degrades. Somebody notices when something breaks in production. The team loses trust, not just in that agent, but in the organisation's entire AI effort. The absence of a decommission strategy is one of the most predictable and preventable trust failures in AI adoption.
The AGENTIC Framework treats decommissioning as a first-class governance event. Turning off an automation requires the same rigour as turning one on. Track identifies the triggers. The AI Governance Stream owns the sign-off. The AI Adoption Stream manages the transition. The workflow doesn't just get quietly turned off. It gets retired with the same structured process that brought it online.
The five decommission triggers
Track monitors deployed workflows for five categories of decommission trigger. Each one is a legitimate reason to retire an AI workflow, and each needs a different response.
Performance threshold breach. The agent's accuracy, completion rate, or error rate drops below the thresholds defined at Assess and proven at Engineer. If accuracy falls below the defined threshold for two consecutive cycles, that's a trigger. Nurture catches the drift. Track evaluates whether it's fixable or terminal.
Tool deprecation. The platform the agent was built on sunsets a capability. The accounting software drops its AI integration. The workflow automation tool changes its API. The agent can't run on the infrastructure it was designed for. This is often the trigger with the longest lead time, and the most damaging if ignored.
Governance invalidation. Regulations change. The compliance requirements that were embedded in the specification are no longer accurate. The risk classification shifts. The governance model that was valid six months ago is now inadequate. When governance breaks, the workflow must stop until it's fixed or retired.
Organisational restructure. The team that owned the workflow restructures. The Workflow Owner leaves. The Accountability Owner is no longer available. The workflow still runs, but nobody is responsible for it. This is more common than people expect, and it's invisible until something goes wrong.
Cost-benefit reversal. The workflow was cost-effective when the team was handling 500 transactions a month. Volume dropped to 50. The fixed cost of maintaining the automation now exceeds the cost of doing it manually. The ROI equation has flipped.
Every decommission trigger has a lead time. The organisations that handle retirement well are the ones that catch triggers early, before something breaks in production.
The governed decommission process
When Track identifies a decommission trigger, the retirement follows a structured process. This isn't bureaucracy. It's the minimum set of steps needed to retire a workflow without destroying the trust the AGENT Pipeline built.
Here's the sequence:
The trigger is documented with evidence: what changed, when it was detected, what the impact is. Governance reviews the evidence and signs off on the retirement. This sign-off carries the same weight as a Greenlight decision. It's not optional.
The AI Adoption Stream plans the transition for affected teams. What happens to the work the agent was handling? Who picks it up? Do they need retraining? Is there a temporary manual process? Is there a replacement solution being evaluated? Stakeholders are notified with clear, specific communication: what's happening, when, what they need to do, and what comes next.
A workflow doesn't just get quietly turned off. The governance model, the adoption transition, and the knowledge retention all matter as much coming out as going in.
The workflow moves to Retired status in the AGENT Prioritisation Matrix. All specifications, build files, performance data, and governance records are archived in the AGENTIC Vault. Nothing is lost. The knowledge compounds even when the workflow doesn't. A retired workflow's specification might contain patterns, modules, or lessons that accelerate future builds.
What a governed retirement looks like
At one of the organisations I've worked with, a purchasing approval agent faced a tool deprecation trigger. The accounting software it was built on announced it was sunsetting its AI capability in six months. Track identified this early, during a routine frontier monitoring cycle, well before anything broke.
Governance reviewed the situation and approved the retirement plan. The AI Adoption Stream prepared the purchasing team: they went back to a faster manual process temporarily while three replacement solutions were evaluated. One was a different tool's native AI capability. Another was a reimplemented agent using a different architecture. The third was a simpler workflow that didn't need AI at all. No surprises. No abandonment. The team knew what was happening, when it was happening, and what the options were.
Compare this to what happens without a decommission strategy: the tool's AI capability quietly degrades over six months. The agent starts producing errors. The purchasing team notices when approvals start failing. Trust collapses. Leadership questions whether the AI programme was worth it. One bad retirement poisons the well for every future deployment.
The difference between these two outcomes is not technology. It's process. The governed retirement takes a few hours of planning. The unmanaged degradation costs months of trust.
What I've learned about the exit path
Two things stand out.
First: decommissioning builds more organisational trust than deployment does. When a team sees that the framework has a governed process for retiring what's not working, they trust the framework more for what is working. It signals that the organisation isn't chasing automation for its own sake. It's managing a portfolio with the same rigour coming out as going in. That signal matters more than most people expect. It's the difference between "we automate everything we can" and "we automate what serves the organisation, and we stop when it doesn't."
When people see that the framework knows how to stop, they trust it more when it says go.
Second: decommission triggers are almost always detectable in advance. Tool deprecation comes with announcements. Performance degradation shows up in monitoring. Cost-benefit shifts surface in financial reviews. Organisational restructures are planned. The trigger is rarely a surprise. What's missing is the systematic practice of watching for it and acting on it before something breaks. That's what Track provides.
The decommission path is the part of the AGENTIC Framework that most other frameworks leave out entirely. It's also the part that gives organisations the confidence to deploy in the first place. If you know there's a governed exit, the barrier to entry drops. If you know the framework monitors for when to stop, you trust it more when it says what to build next. Decommissioning isn't the end of the pipeline. It's what makes the pipeline sustainable.